Lately I’ve found myself inadvertently looking at programme planning and engineering management. I didn’t think I would have ever needed to do that, much less that it would interest me, but there you go.
I needed to think of a way to develop a robust model to handle a change to a system (say upgrading a piece of equipment) and its impact on a variety of different related elements (such as maintenance burden, supply, transport etc). We do this sort thing a lot, but it became sensible to think about whether you could formalise this as a model.
Being technically-minded people, we usually capture the engineering aspects quite well. But as with most things, there is a schedule of some sort to manage – the user wants something at particular point in time. In order to deliver to a schedule, there is a need to determine duration of different activities and how each activity relates to each other.
How do we estimate?
We estimate badly. Over the years I’ve seen and used a variety of techniques to estimate my work and that of others. There is a small caveat in that a lot of our work is intangible and the progress of a report I write, for example, is dependent on the information that feeds it, and that is out of my control to a large extent. Still, we are asked to estimate and we have a variety of methods in use:
- Think of a number and double it
- It’s usually about 6 weeks
- Attempt a work breakdown structure but then the two techniques above can still be applied
- T-shirt sizing (small/medium/large tasks) but these shouldn’t really be used to drive time estimates
- Look at when the deadline is and guess how hard you’d have to work to fit the job in
I’m being a bit flippant here; we do have a lot of experience that we can use as well, and we manage to deliver successfully the majority of the time. But it’s an annoying part of our process.
How do we schedule?
At our local level, we do this well. For us, we rely on evidence being delivered before we can deliver our work, and the project’s report can only be delivered once each contributing report – and its own set of evidence – is completed. Prior to that, the evidence generation activities have to be completed. So you can see how we can start to work a few steps back from our work and could probably sketch a path of what needs to happen in what order. I won’t talk about time at this point, mainly for the reasons in the section above.
When we begin to consider external dependencies, the problem becomes greater. Each external dependency we identify most likely has its own set of dependencies, but these are not always visible to us. Instead, we have a limited amount of information available to us: sometimes we may have an indication of the underlying schedule; sometimes we may only have a forecast date of completion; and in the worst case we may only know whether or not it has been completed.
In order for our own estimate to be reasonable, we need to be confident in understanding our schedule. But since we cannot rely on seeing everything with transparency and certainty, I am tempted to suggest that we cannot expect to produce an accurate and confident estimate. And in realising this I may have reverse engineered the ideas underpinning PERT.
The Programme Evaluation and Review Technique adds uncertainty to scheduling. It also puts more emphasis on the dependencies than the time (at least from my understanding). Rather than with a Gantt chart where you might end up finding the critical path after estimating what will be done and when, with PERT the critical path is more of a starting point. The effort of a PERT chart is in determining the order of dependencies first, and once an estimate of duration is known (and possibly with the use of uncertainty too), the critical path can be seen in the form of something that looks like a flow chart. If uncertainty is used, the critical path will have early and late elements to it. At the end of the planning process, the earliest and latest end dates can be found for a given start date.
Gantt charts, on the other hand, are much more widely used and seem to have a greater focus on dates and durations from the outset. It may be that a bottom-up estimate produces a set of tasks and durations; these can then be organised by looking at dependencies or date-based constraints. An alternative, and one that I see used quite often too, is to start with the specified deadline and work out how much time is available, how much the work can be shortened or squeezed, and thereby give an indication of the risk of delivery. To the technical community, they may find themselves asked how long something will take, only to be told how much time they have, somehow be expected to make up for the difference. Not ideal.
How could we schedule better?
In our work there are usually some constraints, some unknowns, but also some things that we can confidently estimate. The constraints are often:
- Fixed deadline
- Limited number of resources
The unknowns can include:
- Emerging complexity of the assessment
- Additional document requirements beyond those originally sought
Finally, the sensible estimates can be:
- 80% of evidence requirements
- Documents required to satisfy evidence requirements
- Overall judgement of assessment complexity and technical risk
There is some overlap in these categories, and that is largely driven by people’s expertise and recent experience. It can be hard to quantify, but some tasks feel easy or complex based on these things.
If we have this boundary to operate within, we should be able to start building a framework based on what we know or are confident about, and use that to influence the risk associated with the more unknown aspects of the work. As an example, below we have three tasks that contribute towards a deadline, and several evidence requirements.
graph LR; E1[Evidence 1] E2[Evidence 2] E3[Evidence 3] D1[Known dependency 1] D2[Known dependency 2] A1[Assessment 1] A2[Assessment 2] A3[Assessment 3] D1 --> E1; D1 --> E2; D2 --> E2; E1 --> A2; E1 --> A1; E2 --> A2; E3 --> A3; A1 -->Deadline; A2 -->Deadline; A3 --> Deadline;
Assessment 1 and
Assessment 2 are dependent on the same piece of evidence, with
Assessment 2 having an additional dependency.
Assessment 3 is independent with its own single evidence requirement. Finally, we know a little bit more about the content of
Evidence 1 and
Evidence 2, and they share a dependency. So far there is no sense of time here, but we already know that the project has a critical dependency in the form of
Known dependency 1; its completion has a large impact on the majority of the assessment.
All the other dependencies are also required to be complete, but
Evidence 3 only affects
Assessment 3. This sort of knowledge is useful, as it can help identify risk in the project, and with risk identified it might be possible to apply mitigations.
By this point, we might know the deadline and some of the dates that evidence is is due. But we also know that there is more risk surrounding
Assessment 1 and
Assessment 2, with common dependencies affecting the majority of the assessment. So even without starting to estimate effort, there is quite a lot of information available.
I have avoided the topic of estimating effort so far, but as my thoughts on this develop I find there to be more value in understanding the evidence requirements and dependencies first, before any consideration of effort required. Clearly, if there is a time constraint (as there usually always is), estimating effort must still be done, so I will share those thoughts in future.
I’m publishing this as part of 100 Days to Offload. You can join in yourself by visiting https://100daystooffload.com.