For this post we are going to take a bit of a different path from the usual offerings and move into the less technical waters of project management. And to start things off and provide of today’s topic…
“Question: How does a large software project get to be one year late?
Answer: One day at a time!”,
Frederick Brooks in The Mythical Man-Month
And herein lies the problem with project delays. As human beings we are not very good at noticing small changes that are spread out over a long period of time. Our brains are much better tuned towards big, drastic, loud changes and that is what gives rise to common fallacies like the belief that major events have major causes. We are just not tuned to think that something in and of itself insignificant could have major consequences. We are certainly not tuned to think that many small things spread over weeks or months could derail an important project.
And yet this is precisely how things tend to happen with software projects. There is often no single momentous event where before it we were certain to meet a critical deadline and after it we are not. There might be a single moment where we notice we are going to be late, but that’s not how we got there.
pipeline optimisations for projects
So how can we deal with this? This is where taking practices that are commonplace when solving technical problems and applying them to management can help. Let’s say you need to performance optimise a data processing pipeline. In order to do that you need to find where its bottlenecks are and as a prerequisite to doing that you obviously need to measure the current performance of its various components.
That gives rise to two important concepts of project management:
- Milestones, as a way of measuring progress
- Critical Path Method, as a way of determining what the bottleneck is
Each of these topics deserve their own post so for this post we will cover just milestones and revisit the critical path method in a later post.
Milestones are at the heart of time estimating a project. You can’t estimate what you don’t measure. Alternatively if you measure it, but only once when you’ve already reached the finish line, then you don’t have many options left to you. Axiomatically by that time if anything has gone wrong (and something will have) you are already late. Any further actions you take at that point will only decide how much later it’s going to be.
It then follows logically that the earlier you detect a problem the more options you have in dealing with it and that is where milestones help. They allow you to codify a set of expectations about where the project should be at different times in its progress and let you detect slippage when you can still take action to handle it.
For milestones to be truly effective they need to satisfy a few properties. They need to:
- measure real progress towards the project’s goals
- be unambiguous in what they measure and how they measure it
The first of those should hopefully be made obvious with a simple example. A project can involve dozens or hundreds of components. A milestone that measures how many of these components are considered finished, but completely ignores the integrations between them fails this property. After all, every single component can be working perfectly and the project as a whole can still be failing its overall goals because the interactions between them don’t work as envisioned. For a milestone to make sense it has to measure the progress of each part and how that part contributes to the overall project.
The second property is equally if not more critical and yet it’s frequently overlooked. It’s easy to hand-wave some requirements into a milestone and call it a day, but that creates two problems. A problem of direction and a problem of satisfaction.
The problem of direction is that vague milestones translate to vague plans for the engineers that have to meet them. If the milestone is “product X is user friendly”, then the engineers will be forced to fill the ambiguities with their own individual interpretations. There is no guarantee that all those interpretations will match and different members of the team will end up with different, possibly contradictory, understandings about what the overall objectives are.
The problem of satisfaction is one of determining when the milestone is met. It’s about having a before and an after and a clear transition between the two. Similarly if the milestone is “ensure service Y is well tested” and I have written five unit tests and one integration test for it is the milestone met? What if I’ve written one hundred tests? When am I done?
This kind of vagueness could cause one of two things. The deadline could be missed as people keep adding more work to the milestone and move the goalposts backwards or the goals of the milestone could be unmet as “done” is redefined to avoid missing the deadline and the goalposts are moved forward. In addition there is a very significant morale effect in play here as people derive satisfaction from seeing clear goals met. It creates a feeling of success and progress in the team that is invaluable. Few things can be more damaging to morale as the feeling that nothing is getting achieved. Frederick Brooks expresses these ideas very succinctly when he says that it’s better to be specific and wrong than vague and right.
That’s it for this week. Hope we see you again for the next one.
If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.