Checklists play important roles in society, ensuring that the tasks that need to be done get done. They can provide helpful reminders – to do things like pick up the dry cleaning or schedule a dog grooming appointment. Or they can lay out the vital steps airline pilots need to take to safely operate a plane.
In his book The Checklist Manifesto, surgeon, writer and public health leader Atul Gawande digs deep into the concept of checklists, and how indispensable they are in medicine – guiding surgeons through increasingly complex life-and-death situations every day. The book also describes how checklists can, and should, be applied to organize tasks in other fields – ensuring that proper procedures are followed no matter who carries them out or what variables emerge.
Gawande’s book translates well to cloud, DevOps and infrastructure as code (IaC) implementations. Tech failures do not tend to carry the same life-and-death consequences as those in healthcare or air travel. But cloud projects are complicated by nature, requiring an overwhelming number of technological and organizational changes that can be derailed quickly if proper task lists are not followed. Anybody who has tried to fix a failed cloud project knows that the fallout can be far reaching – from lost jobs, to falling revenue, to reputational damage, to loss of confidence in the organization.
At CTP we are developing the checklist approach and putting it into practice with our own projects. We believe checklists have enabled us to grow significantly each year in personnel, while increasing efficiency. They have also helped us decrease human error, to execute consistent cloud adoption projects.
Checklists need to be flexible yet well-defined
So, is there one single checklist that covers all the processes involved in implementing a successful cloud project? Somebody may come up with one, but from our experience, it is best to consider each project separately. You can then tailor the checklist based on a series of factors, including the organization’s experience in the cloud, resources, goals, skill sets and position in the market.
Checklists should be flexible enough to adapt to new situations and new criteria that are added over time. But they cannot be too flexible. They need to follow a series of guidelines.
- Checklists should be made up of straightforward, direct tasks – e.g., read, do, confirm. A checklist should be more like a series of exam questions than a loose set of guidelines.
- A checklist should not include language that can be misinterpreted. There should be no open-ended questions. Each item should get straight to the point. It is this or that, with no maybes.
- There should be no grey areas – everything is either black or white.
Understand that checklists are not meant to tell you how to do your job, but rather what to do when you approach a project. The downside of operating without a checklist is that team members will not approach the project in an aligned manner. Every worker has different capabilities. Having a checklist to follow puts people on the right track yet leverages everyone’s expertise.
Failure to follow a checklist can lead to misperceptions and miscommunications. This creates doubts within the project team. The statement of work (SOW), for example, might call for a fully automated cloud deployment. If a contractor misinterprets the SOW, thinking they are there just for staff augmentation, they will misallocate their resources and create confusion. In the initial meeting, all parties need to agree upon a common set of expectations and define the criteria for success. These must be part of the overall checklist.
In any project, people will be thrown into situations where they are working with others who possess different skills, temperaments and work styles. Take, for instance, developers and technology architects. These are the men and women on the front line delivering the solutions. But they may not be considering the broader context needed to understand what it will take for the project to be considered a success. Having a checklist to follow gives everybody a work template that gets them all thinking as one – aligned with one set of tasks to check off. As project requirements change and technology evolves, others can step into existing roles and carry out tasks – if they have a checklist to follow.
Contractors working on cloud projects should help clients develop different checklists for different roles. Sometimes a master checklist can spin off several sub-checklists that drill down into each set of tasks. Here are some subject areas contractors should consider for project management organizations (PMOs), technical leaders and executives.
Checklists for PMOs
Subject areas could include the SOW, budget, project backlog, roles and responsibilities, travel schedule and communications within the group. The project manager is the leader who understands how the project should flow, and the do’s and don’ts of the deliverables. The project manager must ensure that the group is applying the right resources, the right people and the right list of tasks that align with the SOW. The SOW checklist itself needs to verify that all the tracks, epics, stories and tasks that define the SOW are accounted for, and that resources are assigned to each task.
Checklists for Technical Leaders
Subject areas could include project deliverables, the skills matrix, architectural artifacts, the automation framework, the design guide, the configuration framework and applications onboarding. For the automation framework, there needs to be automation tooling, a naming convention for variables and a code repository. A checklist is crucial here because it gives all developers a level playing field to start writing the code. It also makes sure all the skills are in place for the tools that will be used, and it will identify any knowledge gaps. Without a checklist, you could end up with developers with the wrong set of skills by the time the project starts, and it may be too late to correct the issue.
Checklists for executives
Subject areas could include client-project communications, management oversight and staffing oversight. For management oversight, there should be someone aligned with the business side that can get feedback on the project’s status at a high level. Client-project communications should be driven up and down the organization, updating executives on project timing, potential blockers, potential budget constraints, issues dealing with vendor lock-ins and problems with contracts or procurements. Without a detailed checklist, an executive may be blindsided by issues that could have been solved.
The only way to end up with organized projects is to have a standard and consistent delivery method every time you start one. Whether it is for a cloud implementation or a family trip to the grocery store, a checklist ensures that everybody has a process to follow. If a person is replaced, the process is already there for someone else to take over. You can continue the flow without spending time, money and resources to onboard the new person. Checklists set the standard for a project from the beginning, putting teams on the same page, aligned with clear, common, predefined goals.