Can the perfect process weather the perfect storm ?
In the first two parts of this series we saw what the mechanics are of introducing processes and how processes can be tailored to your project(s). So now you’ve got the perfect process, but you’re still not meeting timelines or quality and performance objectives ! Why ? More often than not, this is because of the tangled web of dependencies our unsuspecting project teams get caught in.
You can try your best to anticipate and manage dependencies thru dependency trees, network diagrams, etc. But what do you do about the dependencies you don’t foresee. The curveballs that come at you from nowhere. How much slack do you build into your schedule ? Do you compress your schedule to accomodate the dependency ? The answer is .. sometimes there’s just no good answer. You just have to accept defeat and suggest the unthinkable… extend project timelines.
Project teams most often don’t manage their dependencies well because they don’t do periodic big-picture views of the project. Its easy to get hung up on task management, so much so that the overall project may have veered off course and become susceptible to new dependencies. The most problematic phases are the detailed design and implementation phases. These phases are likely to introduce so much unforeseen change to a project that you have to watch your back constantly.
After having been burnt by this problem a couple of times, I started to schedule regular project reviews that focus on the health of the project as a whole, in addition to the more frequent task reviews. So, as an example, in one project, I had the immediate project team review the tasks every week, and had a more elaborate overall project review every month. Such an eye-opener for so many people ! There’s nothing like an in-your-face presentation of overall project status, stats, issues and dependencies to drive home the point. It makes the team more watchful of their actions/decisions. It makes the outside community more aware of the course the project is taking, and encourages feedback so new dependencies can be identified early. It makes the executive team aware of the due diligence and support required. You can choose the frequency of these reviews based on the length of your project, but make them a necessary step.
How do you manage project dependencies ? How often do you communicate ? I’d love to hear your experiences.
Yes, one important thing I missed… the right tools to catch the code dependencies. Definitely an indicator that every process also needs the right infrastructure to be successful.
And yes, signing off on the functional document is key in ensuring a good understanding and validation of the situation at hand.
Thx for those important additions to this topic.
The project I work on does have major dependencies. In order to ensure there is no dependency problems we do a nightly build of all the components to ensure code wise there are no issues.
From functional perspective we have a process wherein each team lead has to sign off on a functional document after attending a walkthru of the document.