It is rarely pleasant to miss a deadline, and sometimes it can be downright career-limiting. Last week, we talked about some problems that contribute to missed project dates. Now let’s explore some solutions.
Step 1 – Objectives and Specifications
We have already covered the importance of project objectives and specifications. Of course setting those objectives requires knowing your stakeholders and getting their involvement. In this and other articles I use the term stakeholders to represent the set of people who care about this project. It could be your customers, your manager, people who work in the systems being modeled, or others.
Step 2 – Creating a Project Plan
When creating a project plan, two adages come to mind.
<center><em>“Expect the Best; Plan for the Worst”</em></center>I think it is fine to be an optimist and hope, maybe even expect, that things will go well. But I don’t count on it. I don’t base my plan on optimistic assumptions. I like to start with what seems to be a reasonable estimate, then double it to account for all the things that I know will go wrong. This may seem like “padding” but the objective is to determine an achievable schedule. I have seldom, if ever, found what seems up front to be a “reasonable” schedule to actually be achievable in the end due to the large number of unknowns in a typical project.
Of course you can always spend more time up front studying the problem to reduce the risk to an acceptable level and possibly improve the accuracy of your estimates. But by that time the project has often become irrelevant because the decisions have already been made. Time estimates are always a guess and always wrong, so find a method that works for you and move on.
To me this means be conservative. I try to avoid over-committing and, when possible, avoid sharing my optimistic intentions. For example, while I may have every expectation of creating a compelling 3D animation, I might only guarantee 2D animation or simple 3D animation. Or while I might intend to model some secondary applications so that I might explore some potential system improvements, I would not guarantee that in the project specifications.
In fact, my project specifications usually include three categories:
• Guaranteed Deliverables – No matter what happens, the project is not considered done without them.
• Likely Deliverables – I intend to complete these, but if things go poorly, they may be cut. Often the stakeholders do not even know this list exists, depending on their tolerance for flexibility.
• Wish List – In the rare instance when the project goes exceptionally well, I implement tasks from this list. This list never makes it to a public project plan.
This approach provides me some flexibility to:
a) Avoid disappointing the stakeholders in case the project goes poorly, and
b) Retain the opportunity to delight the stakeholders if the project goes well.
What Comes Next?
These first two steps are just the start of a project. In future articles I will discuss prioritization, agility, communication and many other topics that contribute to making the date and making a successful project.
Until next time, Happy Modeling!
Dave Sturrock
VP Products – Simio LLC