I'm probably stating the obvious here, but I'm sure you'll all agree that there's usually a heap of documents accompanying any substantial IT project. And no shocker here, the larger and more complex the project is, the more documentation there will be and the more things you'll need to track, like milestones, deliveries, meetings, development activities, testing cycles, etc.
Take an example from my past. I helped a client undertake a substantial, $20-million business intelligence data warehouse rebuild. Behind it all was a 500-page RFP, a 150-page vendor proposal with two 50-page supplements, a 100-page service agreement, and a 50-page project plan (when printed at font size 8). And that's not even considering the design documents. That means that we had lots of mission-critical tasks, to-dos, and deliverables nested in the equivalent of nearly two reams of paper.
The problem is how to distill the essential items needed to simply track and manage large-scale projects through delivery so that we aren't bogged down by hundreds of pages of documentation on a daily basis.
What IT leaders can learn from the aviation industry
When an airline pilot sits in the flight deck of a commercial airliner, it's a no-brainer that his pre-flight preparation is serious business. The tasks the pilot performs are inarguably numerous, complex, and essential to the success of the flight.
Hopefully, for everyone's sake, when a pilot preps his plane for takeoff, he's not thumbing through a 1,000-page flight manual or consulting an operator's guidebook on running diagnostic sequences or properly positioning the flaps. There's a time when it's necessary for the pilot to consult detailed schematics, procedures, and instructions, but it's not when he's getting ready for takeoff. It's not something he should be doing every few minutes of the flight, either.
Instead, the pilot relies on a simplified protocol, otherwise known as a "pre-flight checklist," to make sure he doesn't overlook anything.
The checklist reminds the pilot of the important things that need to be done without having to search through pages of extremely detailed materials. It's a SIMPLE, FAST and nearly FOOLPROOF method for the pilot to determine at a glance what tasks he's completed and what tasks he still needs to take care of. You can bet your life that by the time the plane is backing away from the gate, the pilot has everything under control. In fact, that's exactly what we do.
Simply put, the checklist is a high-level, well-organized, and above-all straightforward inventory of what needs to get done for the project, i.e. deliverables, tasks, etc. And it's put together in such a way that lets you track whether something is complete or outstanding.
What's the problem with the project plan?
I know what you're thinking: Isn't that what the project plan is for? In a word, no.
The problem with the project plan is that it's too detailed to be a daily-use, multipurpose tracking tool. There's way too much information, and it takes much too long to make any sense of it. Plus, because there's so much detail in the project plan, it's easy for some things to get lost. A checklist, on the other hand, lets you see at a glance and report on what's done and what still needs to be done.
Creating a checklist -- putting the essentials in one place
Once the project is under way, the first thing you should do is scan through the essential documents, pull out the items that need to get done, and add them to a spreadsheet. Include the items that need to get done, a box to check when they're done, and a column for notes. You might also want to include a column to store a document reference for each item, but that's it. Save the due dates and dependencies for the project plan. It will be sitting there when you need it. The checklist is meant to simplify, so keep it simple.
Organize the checklist items into relevant groupings, but don't go category crazy. Three to five categories should be enough. These groups could include:
- "Fundamentals" for items related to project setup, contracting, team assembly, due diligence, technical platform setup, etc.
- "Recurring Events" to track completion of project meetings, delivery of project updates and performance reports, etc.
- "Development" for items related to design, build tasks, UAT, roll-out, acceptance, and sign-off. How you categorize these tasks depends on preference and the complexity of the project, but keep the goal in mind -- simpler is better.
How to use a checklist
One test of a good checklist is how easy it is to staple with one hand. Because your checklist should be one of those "take-everywhere documents," you'll be glad it's so condensed. And that touches on one of its primary uses -- a no-nonsense list of what's been done and, just as important if not more so, what hasn't.
Your checklist should become an essential part of project meetings and reviews with other members of the IT group, the business, and vendors. The checklist is also a valuable tool to share in governance meetings.
Assign one person to be the keeper of the checklist. He or she will responsible for all updates, addition of new items, and going down the line with the checkmarks.
Update it regularly and perform monthly checks of the items against the project plan to determine which items are behind, ahead, or on schedule. As much as it may have sounded like I was "nay saying" the project plan, I wasn't. It will, of course, be needed, but its value will really be appreciated when it's used as a reference document and not the end-all of project management.
If a simplified checklist can work for a flight crew of two, flying a $250-million dollar piece of equipment weighing over 700,000 pounds and loaded with almost 500 passengers, you can certainly make one that suits your project management needs.