The Project Management Corner

A checklist is an extremely useful tool for project management. In every stage of the project from start to finish, checklists are needed to ensure all required activities are performed. The project schedule itself is a checklist of sorts with a breakdown of tasks that have to be completed to deliver the final product. In Atul Gawande's book 'The Checklist Manifesto', the checklist is presented as a tool for overcoming failure, something that makes up for human errors when expertise alone is not enough in complex environments.

The Good Checklist

A good checklist should be precise, efficient and to the point, easy to use even in the most difficult situations and above all, practical. They should not try to spell out everything but provide reminders of only the most critical and important steps. They should turn the user's brain on, rather than off.

A bad checklist on the other hand is vague and imprecise, too long, hard to use and impractical. They treat people using the tools as dumb and try to spell out every single step.

Key Decisions

The book points out a number of key decisions to make when creating a checklist from scratch. Define a clear point at which the checklist is supposed to be used. Decide whether you want a DO-CONFIRM checklist or a READ-DO checklist.

With a DO-CONFIRM checklist the team members perform their tasks from memory and experience. Then they pause to run the checklist and confirm that everything was done. With a READ-DO checklist team members carry out the tasks as they check them off. When creating a checklist, you have to pick the type that makes the most sense for the situation. DO-CONFIRM checklists provide greater flexibility to the team while stopping them at certain points to confirm that critical steps have not been overlooked.

As stated earlier, a good checklist must not be too long. A rule of thumb is to keep it to between 5 and 9 items, which is the limit of working memory. However, it depends on the context. You should keep the list short by focusing on the killer items, i.e. the steps that are most dangerous to skip and sometimes overlooked. Keep in mind that the checklist must not become a distraction, prompting the team to start short-cutting.

The wording of the checklist is equally important. It should be simple, exact and use familiar language. Ideally it should fit one page, be free of clutter and unnecessary colors.

Test and Refine

Once the checklist is drafted it has to be tested. First drafts can fail. You need to study the failure, make changes and keep testing until the checklist works consistently. Even the simplest will require re-visiting and refining. The purpose of the checklist is to aid. If it does not achieve the purpose it needs rework.

The Advantages

The book cites many advantages of using checklists. They act as a defense against failure arising from flaws in memory, attention and thoroughness. By clearly setting out the minimum necessary steps in a process they help in memory recall, establish discipline and a higher standard of performance. Even the most experienced among us can benefit from a checklist. They can help experts remember how to manage a complex process or configure a complex system.

Checklists make priorities clearer and help the team to function better. Most importantly, checklists get the mundane stuff out of the way. By removing the routines that your brain shouldn't have to occupy itself with, the checklist allows you to focus on the hard stuff.

Checklists can be useful both in your professional as well as personal life. Even a simple mental checklist will help you to be better prepared. For example, making sure you have everything you need before you step out of the house every morning.

Are you an advocate of checklists? In what situations do you use them? Share your feedback in the comments.

Recently I was involved in setting up a production support team during the transition phase of a project. Once the implementation was completed and the application went live, the production support team needed to be ready to take over the support activities. The usual practice is to ramp down the team during this phase and have a smaller team in place for support. While setting up the team we realized that it would be helpful to have a checklist in order to ensure that all prerequisites are covered and the team was ready to take over.

This checklist was created specifically for a production support engagement. However, it can be customized for any type of project setup. We didn’t have a proper checklist in place for this part of the transition. I believe the reason for this is that production support is an area where we don’t put in a lot of emphasis. The whole team is focused on the deployment and go-live activities that the post production support gets little attention. However, it is part of the service that we provide to the client and deserves equal consideration. Clients start using the product after the implementation and deployment are over, so we can’t afford to breathe a sigh of relief and walk away. We must have the same amount of focus in continuing to serve the client to make sure that they gain the business value of the application.

This checklist will help project managers to complete the tasks that are required to setup the post production support team successfully. This transition should also be part of the overall project plan and the tasks have to be included in the schedule.

• The signed contract is in place for the production support phase. This could be part of the application development contract or a new work order.
• The scope of work, roles and responsibilities are clearly identified for L1, L2 and L3 support as applicable. This is spelled out in the contract.
• Production support resources are identified from the existing team.
• The team understands the scope of work given in the contract. If the scope involves after hours or weekend support ensure that the team knows this and are comfortable with the working hours.
• Compensation / allowance policies are in place if after hours and / or weekend support is part of the scope. There should be an organizational policy for this.
• Knowledge transfer plans are created to transfer knowledge of the full application to the production support team. It is likely that they have been engaged in working on a subset of the application modules during implementation.
• Training plans are created to provide training of the support ticket system and the process / workflow.
• Knowledge transfer and training sessions are planned to be completed before the go-live date.
• Identify metrics to be tracked. Metrics should be defined in the contract. If not, use organization or industry metrics for similar scope of work.
• Templates / systems are in place to track metrics from day one.
• The project level process suitable for production support is defined.
• The governance structure and the escalation process are defined.
• Required templates for weekly / monthly status reporting are created.
• Client and team kick-off presentations are created.
• Kick-off meetings are planned before the go-live date.
• E-mail distributions lists are created.
• All team members have appropriate access to environments and applications which are to be used.
• Hardware requirements (telephones, data cards, laptops, etc.) are identified and hardware is allocated to the team.
• The shift schedule is created (minimum 3 months), if applicable, and published to the client. Include contact details, leave plans and holiday in the shift schedule.
• The project is setup in the internal systems. This includes all project management systems, billing systems etc. if this is a new work order.

In addition to the above, if the team is expected to support the production migration of the application, the training plan must include a walk-through and review of the deployment plan. The production support team should understand their responsibilities during the deployment process.

I believe this checklist covers all the actions / prerequisites that have to be completed before kicking-off the post-production support. Is there anything else that should be included? Please share your thoughts in the comments.