seat58F
outsourcing relationships: international, inter-economic, interpersonal
July 29, 2010 ~ 12:35:45 PM * -07:00ST
do not touch
Post # 581 by
admin on July 2nd, 2009 ~ 05:44:09 PM
Posted as app services, prod-control |
No Comments »
the old-school view of production control and scheduling is based on mainframe architecture - the application was hosted essentially on a single platform. if the application had to be up to match data entry shifts or jobs needed to execute to deliver reports by a certain time, then “do not touch” windows could be defined to minimize disruption.
newer architectures are harder to protect because the dependencies are difficult to discern. we can’t easily define where in the network user groups will relocate, and we don’t always recognize the relevant infrastructure components. That is unless we spend some money investing in, wait for it,,, configuration management.
watch the users carefully
Post # 578 by
admin on July 1st, 2009 ~ 05:09:16 PM
Posted as prod-support |
No Comments »
production support and maintenance is the stuff you do to manage software defects so that operations continue per the specifications. sounds good, but you would think that, with proper funding and assuming that software was functional in the first place, that the majority of defects would be resolved in short order and those charged with “production support” would soon have nothing to do.
User behavior is the main cause of and overloaded production support crew. Applications are never stable, new user requirements, misset expectations, and poor change resourcing keeps production support on their toes. A shifting architectural foundation of patches, upgrades, license constraints, and network reconfiguration keeps tickets flowing in to the service desk.
And don’t forget about the ever threatened maintenance windows and do-not-touch timeframes. These are constantly crimped by changes in use geography and business calendars. There’s little hope of profiling these effects in the original application requirements.
be reflective
Post # 575 by
admin on June 23rd, 2009 ~ 11:17:25 AM
Posted as app services, retrospective |
No Comments »
once the project metrics are recorded and client satisfaction details are collected, evaluate project success based on the service provider business objectives
go live (and cleanup)
Post # 572 by
admin on June 22nd, 2009 ~ 11:03:57 AM
Posted as app services, code release |
No Comments »
- Release Note published
- source code repository updated
- KT per the project plan
- production gate checklist completed per the project plan
- deployment quality control checklist
- client acknowledgement
get the user involved
Post # 569 by
admin on June 21st, 2009 ~ 10:59:01 AM
Posted as app services, testing |
No Comments »
- user acceptance test and scenarios are pre-defined
- scenarios are reviewed (and obtained from a library) and approved by the client
- test findings are logged and tracked to closure
- system testing executed per the project plan
- test findings are evaluated by stakeholders
pound the code
Post # 563 by
admin on June 20th, 2009 ~ 09:34:38 AM
Posted as app services, construction |
No Comments »
Use one, and only one, code repository. Code should not be spread across multiple workstations.
- coding standards are in use
- Unit test cases are available (hopfully re-used, not re-invented)
- test case findings are logged and tracked to closure
- unit testing is occuring as planned
- unit test defects are tracked to closure
backing out of the garage and into the street
Post # 566 by
admin on June 19th, 2009 ~ 10:50:22 AM
Posted as app services, testing |
No Comments »
- system test plan and scenarios are pre-defined
- scenarios are reviewed (and obtained from a library) and approved by the client
- test findings are logged and tracked to closure
- system testing executed per the project plan
- test findings are evaluated by stakeholders
solution design
Post # 560 by
admin on June 18th, 2009 ~ 09:12:59 AM
Posted as app services, design |
No Comments »
The System Requirement Specification for an app maintenance activity is the link to the architectural realities of the infrastructure. Verify that it has been reviewed and approved. Review findings should be resolved prior to approval.
pliable, not frozen
Post # 555 by
admin on June 17th, 2009 ~ 09:03:09 AM
Posted as app services, project monitoring |
No Comments »
the project plan needs to be continuously updated and reviewed on a weekly basis. look for:
- re-planning triggers
- client sign-off on revised estimates.
- tracking sheet (Issues Log) maintenance and communication
- Defect Logging is occurring (”major” and “fatal” defects are addressed before moving to the next phase)
- Risk Analysis and Log is updated
kickoff
Post # 549 by
admin on June 16th, 2009 ~ 08:19:52 AM
Posted as app services, project planning |
No Comments »
stuff that should be on the table:
- complexity evaluation
- ballpark effort estimate approved
- High Level Solution (architecture) and schedule
- client business unit and IT sign-offs obtained
- project workspace provisioned
- SOW updates as required
- Security Plan updates
- Operations training and SOP updates
- SLO updates
