Cost overruns, missing features, missed deadlines, non-functional systems…. All of those add up to a failed project. However, just a bit of time spent upfront can go a long way to addressing all those issues – and toward making sure that your project is a complete success, instead of an embarrassment to disavow like MI6 does to James Bond when he (invariably) gets caught by the villain again.
This is especially important when you are planning an IT project, as there are so many small, moving parts. When one missed deadline can result in frustrated end users or even a lost client, isn’t it worth spending a bit of time to make sure everything goes smoothly?
Poor planning is one of the top causes of project failure.
Yeah, I know, right? That’s not going to happen to you. You’ve planned it out, you have a summarized, high-level Statement of Work (SOW) and you’ve gotten the key stakeholders to sign it. You’re good to go.
….Actually, you’re not.
Poorly written SOWs are actually one of the top reasons that projects fail. And, you need far more than just a Statement of Work before calling planning complete! Consider the following key issues that plague otherwise smoothly-running projects:
1.) Lack of direction: Having a SOW is all well and good, but does it outline the exact end result? And I don’t mean “install software X,” I mean “implement software X, which will allow better tracking and metrics and lower processing time of customer orders”. It’s very common for vague proposals to be pitched and agreed to without defining expectations, milestones, and exact desired outcomes.
It’s one thing to say “We’re destroying the Death Star!” and another to say “We’ll maneuver our starfighters through the meridian trench in the northern hemisphere of the Death Star and fire a proton torpedo into a small thermal exhaust port approximately 2 meters wide. A direct hit will cause a chain reaction that will reach the central power core of the Death Star, destroying it before it can fire on Yavin.”
2.) No Project Plan: So you have your SOW, and it has a clear expected outcome described. Next, you’ll need to create a detailed project plan specifying exact timelines, milestones, exact steps to take to meet that expected outcome, action owners for each step, and deadlines for each one. And guess what – you don’t need a fancy tool to do this plan. While Microsoft Project and other sophisticated tools are on the market, a project plan can be easily plotted out in Excel or even a pad of paper.
“But this is overkill,” you say. “The engineers know what’s expected of them.” That may be true, but having a project plan outlined, reviewed, and approved will ensure that everyone is on the exact same page, and no one is assuming that ‘someone else’ will complete a task.
And for that matter – make sure you work closely with your engineers or techs that will be completing the work, both when you’re creating the project plan and when writing the Statement of Work! There’s nothing worse than estimating 3 hours to complete a subtask, only to find that the engineer needs 8 because of a change in software version or an intricacy of the target server or site. Never assume, and make sure to double-check.
3.) Failure to Review with the Team: Great, now you have the clearly-defined SOW, the project plan, and sign-off from all involved. Now you can get started!
….Not quite. Creating a SOW and project plan is all well and good, but if no one knows about it, it loses all effectiveness and value. Hold a project kick-off meeting with all involved in the project. During the meeting, have the entire team review the SOW and Project Plan and identify all key players.
Your project plan should have resources assigned to each task; you want everyone affected in the meeting to review deadlines and tasks. Maybe you’ll discover that the person who used to handle starfighter maintenance now does flight path plotting; maybe you’ll find out that the key engineer who handles programing R2 units is on leave a week before project completion, so you’ll have to adjust certain deadlines to accommodate.
It’s really temping to dismiss this step as “just another meeting” and save time by skipping it; however, the 2 hours saved now will turn into 10 hours down the road, or worse yet, will result in losing a key Rebellion planet.
Also at this kick-off meeting, you should establish and schedule regular, occurring checkpoint meetings throughout the project to review progress and milestones and address roadblocks. Add these meetings to the Project Plan.
There’s much more to bringing a successful project to completion, of course – but this are the top three high-level points that any good project manager, and everyone involved in a project of any size, should keep in mind.
Got any more? Leave them in the comments!