In PlanningSequencingElaboration , I shared my realization that sequencing is less a simplification of scheduling, than scheduling is an optimization of the plan around a time constraint.
Here are some typical variables and constraints that a project plan must contemplate:
1) Cost – can we complete the necessary work and deliver the expected value at a cost that someone is willing to pay.
2) Time – can we complete the necessary work and delivery the expected value in a timeframe that supports some goal.
3) Resources – are the resources/skills/knowledge we need to do the necessary work available.
4) Risk – what unknowns exist in the definition of value or the elaboration of work
As project managers, we are trained how to elaborate the work (build a WBS), how to find the critical path, how to optimize the sequence for dependencies, how to assess and mitigate risk, how to estimate cost, but all of those activities assume that we are optimizing for a single point in time: the completion of the project as a whole. It is this assumption that causes us to optimize in a certain way, and it may exclude the most important variable to optimize for (customer desire).
What if your customer asked you to deliver valuable releases of software to them every month. How would any of these activities or processes help? The answer is they really would be of very little use in that model. The most important thing would be the customers desired sequence of value delivery; which UnitsOfValue will be delivered in each monthly release. In order to balance this, we also would want to understand an optimized risk retirement sequence; that is which of the UnitsOfValue have unknown risk, that might interfere with the delivery of other UnitsOfValue. We might want to negotiate sequence of value delivery to balance the retirement of risk against the delivery of value. This delivery sequence of the UnitsOfValue is then the initial basis of the plan. We do not have an estimated cost or duration, we have not converted UnitsOfValue to UnitsOfWork, and we have not contemplated resources.
What we have done is construct a simple delivery roadmap, a planned sequence of delivery, and agreed with our customer to deliver value in a rational order, on a regular schedule. From there, we can convert units of value to units of work, estimate, allocate resources, form a team (if we don’t already have one), build a schedule.
The point of this all is: if you assume that delivery is single in time, you cannot optimize for value, value is assumed to be fixed. Except that we all know that value (aka scope) is not fixed. So if you assume that scope is fixed, and you cannot optimize for value, when you run out of time or money, you may have nothing to show for it, or you may not have completed the most valuable units.
While this is completely logical and intuitive, what we react to is that optimizing the sequence for value often introduces an opportunity to spend more, or take more time to get to done. The logic goes like this: If we deliver the most valuable unit first, some subsequent unit may require us to build differently than the first, and so we introduce some “re-work” with a less valuable unit. Re-work has a cost. It appears to be a waste. Building something that we know or suspect is temporary, or will be replaced appears to be foolish. When thinking about the plan with a view towards optimizing cost and duration, this is an unacceptable compromise, but may be completely rational when optimizing value delivery. Especially if future funding is uncertain (budget cuts are imminent), and we want to get the most value for our spend.
We have become so accustomed to optimizing cost and time that we don’t think about value in the same way. If we deliver value early, our customer can realize the value sooner, and so might be willing to negotiate on price or schedule.
No Comments