Anatomy of an Execution Plan

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here's an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  Online Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system's business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the 'rollback point,' which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to 'check' completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a 'lessons learned' section to be completed later, and ke copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

Excellence over Heroics

I value Excellence over Heroics.

'Excellence' can be defined as "the crisp execution of established procedures."  Think about that for a minute.

Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires?

The thrill of delivering when the whole company's reputation is at stake can be addictive.  I remember once staying up 37 hours in-a-row to deliver an EDI package for a bankers convention.  I was successful, delivering the application just before it was to be demo'd.  I went home and slept for 24 hours straight afterwards.

The problem with 'Heriocs' is that the hero is compensating for the effects of a broken process.  Think about that for a minute.

If heroes are needed to make a software development project successful, then really something upstream is broken.

Most problems requiring heroics at the end of a project stem from improper effort estimations, inability to control scope, inadequate project tracking transparency, mismanaged Q/A scheduling, unnecessary gold-plating, or inadequate communication between the development team and the project users/stakeholders.

A well-organized development group humms along like a well-oiled machine.  Proper project scoping, analysis, design deconstruction, estimating, tracking, and healthy communication between development and the users/stakeholders will bring that excellence that trumps heroics.

Hey, I hear that Microsoft is looking for some Heroes.

Mike erry
www.RedRockResearch.com

The Three P's of a Quality Management System

A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.

Companies that don't have a quality system are commonly reacting to production and support issues due to omissive events.

A simple rule of thumb is to ask yourself how many fires your development team has put out this month.  If any come to mind, then chances are you don't have a proper quality management system in place, and should read on...

I remember early in my career I struggled to get my employees to follow our procedures.  Whenever we'd encounter a production problem with our software, it would inevitably be a result of someone not having completely followed an established procedure.

We would have a big discussion about what should have happened, and about how "we can't forget to do that next time," yet we'd experience the same omission later.

I would get frustrated because I could never seem to find a way to get my team accountable for following our established procedures--until I discovered the "Quality Management System."

A Quality Management System has the following three elements (the Three P's!):


  1. Process (documented--most of us have processes or procedures we are supposed to follow.)

  2. Proof (a separate checklist, or "receipt" that the process was followed for each software release.)

  3. Process-Improvement (a discussion, and then an addition or adjustment to the documented process.)


Most companies have an established--and hopefully documented--software development process.  (If you don't you can download one from my website for Waterfall, or Agile here.)  This is the first 'P' and should be in place at every established development shop.

A great question to ask the team is "How do you know the process was followed for each release?"  This is where you may get the deer in the headlights response.  This is the second 'P' and is the piece missing from most software development shops.

Think of this 'Proof' document as a checklist accompanying each software release.  The checklist would include every major step in the documented process, names of team members performing specific functions, and locations of final source code, test scripts, install files, etc.  The checklist would also require a series of quality checks.  Ie: Were requirements signed off by the customer, stakeholder, tester, and developer?  Was the help file updated with the new release number and appropriate functionality?  Was the source code checked in?  Where is it located?

As problems occur, the checklist would be added to so that the product would be protected against a similar failure in the future.

The governing driver considered here is that one particular problem might broadside the development team once, but after the process is improved, that problem should never occur again.

For example, you might have a stored procedure that goes into production without a "Go" statement at the end.  After the error is discovered, and fixed in production, your team should have a discussion and conclude that a checkbox needs to be added to the quality document stating "All Stored Procedures Confirmed to have 'Go' at the end."

From that point on, whenever a stored procedure is moved into production, the developer presenting it must check for 'Go' statements at the end and then sign their name at the bottom of the checklist.

This is the difference between process improvement, and hope.  Many companies view process improvement as a discussion and some verbal affirmations.  What they are really doing is "hoping."

Actually, the "act" of process improvement is physically altering a written process or procedure.  This is the real definition of process improvement--the third 'P.'

The final endpoint of a quality management system is to achieve excellence.  I've heard excellence defined once as "Crisp execution of established procedures."

You can't have excellence without procedures, proof, and process-improvement.

Mike J. Berry www.RedRockResearch.com