seat58F

do not touch

admin — Fri, 03 Jul 2009 00:44:09 +0000

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

admin — Thu, 02 Jul 2009 00:09:16 +0000

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

admin — Tue, 23 Jun 2009 18:17:25 +0000

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)

admin — Mon, 22 Jun 2009 18:03:57 +0000

- 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

admin — Sun, 21 Jun 2009 17:59:01 +0000

- 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

admin — Sat, 20 Jun 2009 16:34:38 +0000

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

admin — Fri, 19 Jun 2009 17:50:22 +0000

- 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

admin — Thu, 18 Jun 2009 16:12:59 +0000

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

admin — Wed, 17 Jun 2009 16:03:09 +0000

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

admin — Tue, 16 Jun 2009 15:19:52 +0000

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