That last post, Your Schedule is Totally Mental, prompted long time reader and occasional drinking buddy Magnus to chime in with two excellent questions:
Do you also think that all schedules can or should follow the *same* (arcane or standardized, old or new, blue or red, agile or fatcat) schedule model?
How far ahead are you able to do almost perfect, good and less great predictions in your schedule? How does your scheduling model affect your prediction capabilities?
…which leads me to conclude that Magnus is hanging out with the project managers I was working with last week who asked me the same questions – or simply made the same assumptions about what I’m going to say before the workshops even started.
Let me state this unequivocally at the beginning of this conversation:
Not All Work Is Created Equal
No lifecycle model fits all projects. One of the leading causes of failures for most PMOs, if not the leading cause of failure, is the ignorance of that fact and the attempt to shoehorn all work into the same model. Lifecycles should be paired with projects like wine and cheese (or in Texas, artisanal beer and brisket).
There, I’ve said it. Let’s just put it out there as an opening premise and build from that. What’s interesting is that I was about to write that “No process fits all projects,” but on reflection decided not to. Because we can have a single high level process that captures work, categorizes work, assesses risk, and then assigns a lifecycle model according to predetermined triggers. In that case, arguably there is a single process, but it’s at a high level…which brings us to the federal model of process design that stipulates that the process is defined at the level appropriate to the process. (See here and here for a couple of 2011 discussions of this model – which I note in retrospect also earned a comment from Magnus.)
So the trick is to pair the model with the work to be performed, which generally, but not universally implies that we’re talking about work being performed in the IT domain. Why IT? Because, IT is one of those domains that typically manages work that could map to different lifecycle models. As I’ve spent the last few years bouncing back and forth between building pipe and building code, I usually contrast this to construction, which typically starts with a better defined scope than most IT projects.
A Triage Model
The best model I’ve yet to find to break down lifecycle models in a manner that’s easily explainable is a model I found years ago in Terry Williams’ Modeling Complex Projects which references a 1993 model by JR. Turner and RA. Cochrane. Reproduced in the form of a graph here, it provides a useful framework for assessing the risks inherent in a project.
In this framework, a project may be assessed by how well the scope of work is known vs. how well the method is known by which we will achieve this scope. In the top left, both elements are well-defined, i.e. we’re using proven technology to deliver a project scope which all of the team members and stakeholders are familiar with. I’d place pipeline construction in this quadrant. In the IT world, this may typically map to an infrastructure project, where we’re deploying X number of servers or virtualizing hardware that’s gone off lease.
In the top right quadrant, we might have something where the scope is undetermined or hazy, but the technology is pretty well known. For instance, we’re using an existing database platform to deliver an application to support a brand new business process. The process is probably still being defined, but we have experienced staff familiar with the technology.
In the lower left quadrant, we have establish scope but a method that is new to the organization or the project team. For example, we might be porting an existing application from an older technology to a new technology – while keeping the functionality the same.
And last but not least, if we’re looking for the trifecta (Bifecta? Difecta?) of managing systemic risk, we might go for the bottom right quadrant, developing with a new technology to meet an uncertain scope.
Pairing Scope Management Models with Lifecycles
Now, the discerning reader at this point would ask if we’re looking at scope management models or risk management models. Essentially at this point, it’s the same thing. Much of the risk is introduced from the scope, and step 1 in any risk assessment exercise would be to ensure that we’re implementing the project management structures in a way that they will effectively manage risk – which if you’re following a “one methodology fits all” practice probably does not apply.
So what lifecycle maps to each quadrant of the model? Far be it from to be an expert on the nuts and bolts of specific lifecycles, but I would submit the following as a starting point:
|Known||Known||A traditional waterfall lifecycle is appropriate to this scenario. “We’ve done similar work before and can estimate it without too much difficulty.”|
|Known||Unknown||Shorten the design cycle, but extend the development cycle. Plan multiple quality checkpoints into the project design to ensure the team is meeting its goals. Ensure plenty of testing is included in the project. Consider an iterative development cycle with multiple internal prototypes reviewed before showing them to the stakeholders.|
|Unknown||Known||Plan for multiple prototyping sessions to ensure the requirements are being met. Release early and often to allow the organization time to acclimate to the changes and to refine their own processes accordingly per the magic stone model.|
|Unknown||Unknown||See above but with more stringent quality control and even more system design and release iterations.|
Now is Agile the solution to all of this? I know some people that would claim yes. I’ve always taken a more moderate approach, which is to say that a properly managed Agile methodology is appropriate to some of these lifecycle models – provided that you’re using an appropriate form of project management rigor and have dedicated technical resources. I certainly wouldn’t just label the project as “agile” because a simple waterfall methodology is inappropriate and then jettison all rigor and process. That would be wrong.
Next up: ‘Ware the bean counters! Mapping estimating processes to a multiple lifecycle environment.