How to determine a confidence level in your project schedule – Part Three
This post constitutes the third and last session of my discussion of how to determine confidence level in your schedule. You can look in the archives for previous posts::
-Dependencies. I’m a firm believer that a schedule should show as many dependencies as possible. So, “hard” dependencies occur when A must happen before B. And “soft” dependencies can occur when A must happen before B because they share all, or nearly all resources. This prevents the “everything can start at the same time and only some actually will” phenomenon. It also forces prioritization of tasks and/or projects. And it allows for a dynamically flowing schedule, one that doesn’t require too many hard constraints. (E.g, Must start on April 15th). So you want to link tasks with their predecessors as much as possible. And note that it’s really important to identify all predecessors. Miss a key one to a critical path item and your dates could be way off.
-Risk. To what extent is risk understood and risk mitigations embedded into the project? In many cases, I would say not at all. My observation is that many organizations don’t know how to do risk management. Which is a shame because frankly, it’s not that hard to learn. The hard part is incorporating understanding of risk into your project and discussing it at every meeting. (See earlier post for a discussion of Monte Carlo simulation).
-Team buy-in. A corollary to the above (and maybe all) is whether the team feels they can sign off on the schedule. Do they believe in it and can they do it in the time allotted? Were they allowed to contribute to it or were they told what the dates are? If not, low confidence.-Understanding of work flow. In creating a Work Breakdown Structure as a predecessor to a schedule, we’re fortunate in that we make participants think through their work flow not only within their own discipline but across disciplines. But participants often have a difficult time figuring out what they do, how they do it and how it flows before they can even think of getting to a schedule. And once they have to input it into a schedule, they have a hard time understanding the translation of work flow to schedule, which is basically an artificial construct. And so, it is the project manager’s job to help them understand that transition.
All of this just speaks to the creation of the final schedule. I’m not even addressing here what happens after it’s created, namely the ability of the PM to drive the schedule and the team’s ability to execute, track and manage. Or for that matter, management’s ability to provide the team the tools it needs (resources, money, time) to get the job done.Anyway, that’s my list. Your mileage may vary.
(End of series)
I believe you did brilliant resolution the moment when you picked up this theme of this article of yours here. Do you usually compose your blog entries alone or you work with a writing partner or an assistant?
These are my entries. Occasionally I have a guest blogger on a related theme.