“Don’t manage the unknown and unpredictable the same way you manage the known and predictable.”
– Doug DeCarlo, Oct 2004 – eXtreme Project Management“Managers must be flexible enough to adopt the right approaches at the right time…to find the balance between planning and learning.”
– Arnoud De Meyer, Christopher H. Loch, and Michael T. Pich – Managing Project Uncertainty: From Variation to Chaos
Reflecting on the last ten years of my own experience working on projects, early on, I saw mostly “traditional project management.” That is, project management that places greater emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done very early in the project, and seeks to provide predictability of activities over longer planning horizons. Other terms I’ve heard for this project management style are “predictive” or “sequential (gateway) delivery.” In more recent years, however, my experience has been to see “iterative and incremental” approaches. Again, that is, project management that places less emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done in small amounts iteratively across the project, and seeks to provide predictability of activities only over shorter planning horizons. Other terms I’ve heard for this project management style are “emergent” and “incremental delivery.”
While this is a minimal level of distinction, for our purposes it will be sufficient. This won’t be a post on “good vs. evil” styles of project management. In fact, I’m advising, that might be a “limiting” perspective. Rather, the “focus” is to view projects from a perspective of uncertainty (as a model) to gain insights into these two project management styles that may help us more effectively manage our projects.
Are All Projects the Same?
In your experience, how often have you seen projects managed differently from one another? Is there “evidence” to suggest, based on how you manage or see projects managed, that all projects are the same?
Take a look at this list of a few common project management practices. Do any sound familiar to you as some of the “sure ways” to successfully manage projects that you’ve used or seen along the way?
- Identifying and tracking milestones
- Identifying potential issues and developing risk management plans to reduce and mitigate them
- Utilizing iterations
- Conducting intermittent project plan reviews
Why would you choose to use “iterations”, and what makes them “different” than simply a “short” version of a traditional project management approach, what is often referred to as “mini-waterfalls”? Do your planning horizons (or your iteration lengths) ever vary or are they the same length on each project and for all parts of the project? Is there a lack of clarity in the differences of project management styles and reasons for certain practices that results in us more or less using them, or observing others use them, in the same way on any project we work on, and consequently making them less effective at times? We’ll come back to this question, but first, we’ll consider projects themselves a little more.
Well-Known Projects and Not-Well-Known Projects
What would a “well-known project” look like to you? For starters, it would be a project where many of the requirements and tasks appear very familiar to you already, where you have previous and extensive experience with projects that are very similar. It could be a project with a relatively small set of requirements and tasks, making it fairly straightforward to identify it as a part of a number of larger and similar projects you’ve managed successfully already. Do you think a well-known project would have a small number of assumptions? It is reasonable to expect that a well-known project would in fact have few assumptions, and any, would be ones that could be validated easily or predictably.
Would a well-known project be one that has a limited number of highly predictable outcomes? A well-known project would likely have a small finite number of dependencies such that the possible outcomes are easily enumerable and highly predictable in terms of some (quantifiable) probability. What else would you add to this list?
Now, consider what a “not-well-known project” might look like to you. For starters, it would be a project with requirements and tasks that you have no or little previous experience managing. It may also be a project with a large number of assumptions, and even if the number of assumptions were small, a number of them might be difficult to validate. It would be a project with a high number of dependencies such that the outcomes are not easily enumerable or a number of the possible outcomes are not highly predictable in terms of some (quantifiable) probability.
But these are characteristics often associated with “innovative or break-through” projects, those “game-changing” projects that create “separation” between you and your competitors. They are projects that seek to accomplish something “never-done” before or to accomplish something in a competitively improved way (technology or process). Then, what about the environments we’re managing our projects in? Consider a project managed in the context of a “merger” or in the context of a just released new competitor offering. These factors as well may put any project into the not-well-known context. Again, what else would you add to this list?
Another Frame (Lens)
No surprise, in the context of being well-known or being not-well-known, it’s clear we can see projects are not all the same. So, here’s my earlier question restated in other ways. When was the last time you didn’t “iterate” on a project or managed some part of your project using a “predictive” approach over an “emergent” one? Maybe it is time for a “fresh” look! What makes a “series of mini-waterfall deliveries” different from an “incremental and iterative delivery”, or is it really different? Maybe there is a “new” perspective and different distinction to look for here!
We’ll take another look now at that earlier list of practices, using a different frame (lens). I created this table below as a model for myself, heavily derived from the article “Managing Project Uncertainty: From Variation to Chaos” by Arnoud De Meyer, Christopher H. Loch, and Michael T. Pich. The uncertainty types listed in the middle column are extensively discussed in this article, and while no table exists in the article itself, I feel mine below conveys what I took away from the article. We’ll now go through each row in more detail.
|
Project Management Practice |
Category of Uncertainty |
Project Focus |
| Milestones | Variation | SLA Focused |
| Risk Management | Foreseen Uncertainty | Insurance Focused |
| Iterations | Unforeseen Uncertainty | Learning Focused |
| Project (Assumptions, Goals) Reviews | Chaos | R&D Focused |
Milestones and Variation
Milestones, in my experience, are intended to represent a necessary outcome for the project success, and it’s understood (or assumed) there are decidedly negative consequences if you miss one. Is your experience similar? If so, I would base a “milestone” then only on something well known to be achievable, and highly predictable, even on a longer planning horizon. It doesn’t mean achievable 100% of the time, but it is more than “a wish” for something to be achieved. That is, when established, the milestone is based on information (evidence) supporting my opinion (judgment) that it is achievable and highly predictable, otherwise “as a label” it is of little value.
This brings us to the first type of uncertainty listed in our table, variation. De Meyer et al., describe one form of uncertainty that exists in projects resulting from combining numerous small influences that individually would be costly to plan for or monitor (due to expense or time). However, many times it is possible to measure this “activity” as a range of values (an overall variation) that in turn can be used to cost effectively plan (manage, not control) with a high level of predictability even at longer planning horizons and also monitor this activity throughout a project. Is variation another way to represent a necessary outcome or something similar and as useful?
Here are a couple examples from real world projects. The first is from direct experience as part of a software development team several years ago. We were using an iterative and incremental development (IID) approach. As part of this IID approach, we’d attempt to “estimate” the work that we “expected” to complete in the upcoming short and uniformly fixed-length time period; this was done attempting to (analyze) and estimate each of the small numerous individual work items. These “estimates” were then used to establish and communicate an overall project release plan, which included “milestones” along the way. However, in our context, time and again these particular “estimates” proved not to be accurate (training, or effort put into estimating wasn’t the issue).
We tried another approach and began simply tracking the “lead times” for work items (observing how long they took to complete once they were selected for being worked on). In (weeks), we established measures of variation for how long it took to complete individual work items, and how many work items we’d complete per day (per iteration); over (months) we also established a measure of variation for how many work items we’d complete for any project.
We found these measures of variation proved to be very accurate for us and required significantly less time to acquire from the overall team. To be clear, we continued the software development work itself using an IID (emergent) way of working. However, “milestones” for release planning (forecasting) purposes were now based on well-known, measures of variation in this case, and gave us high predictability over longer planning horizons.
The second example comes from my collaboration with a colleague who is working with a client that is using a similar approach in their project planning efforts. However, in their context, his client has been able to establish lead time measures of variation at the project level as well (lead time variations of projects, not just for work items needed to complete a project). They moved away from estimating individual work items 18 months earlier. Now with well known, project level variation measures in this case, they are in a position to further reduce efforts needed for planning “milestones” for forecasting purposes. In fact, they are at a level of predictability to consider providing their business stakeholders something akin to an SLA (service level of agreement), well known, achievable and highly predictable, for completing any project in their organization.
Both show that a project manager can choose to use iterative and incremental delivery (emergent) practices, but it doesn’t exclude managing some aspects using non-iterative (predictive) practices. Manage what is “predictable” in your project (well-known or can easily and quickly become well-known) differently from what is not predictable! Measures of variance can effectively aggregate numerous “hard or costly to predict” small influences into something “visible”, well-known, and predictable over longer planning horizons.
Risk Management and Foreseen Uncertainty
Risk management, as practiced in traditional project management, is not often something I see explicitly performed on iterative and incremental projects I’ve worked on recently. I believe the “uncertainty” typically addressed by risk management as practiced in traditional methods is, in large part, implicitly diminished by several software development technical practices commonly found in iterative and incrementally managed projects.
This brings us to the second uncertainty type listed in our table, foreseen uncertainty. De Meyer et al. describe foreseen uncertainty by contrasting it with variation. Unlike variation, which is a measure, a range, of the combined influence of numerous small influences, foreseen uncertainty influences are considered “singly” identifiable (distinct) from each other. Here’s another way to contrast these two uncertainty types: 1) view variation, as we’ve described earlier, as inherent in your system, expected to occur (to exist), and for this reason it is often referred to as “common cause variation” (or common chance variation or quantifiable variation); 2) view foreseen uncertainty as not necessarily inherent in your system, but if it is, expect the numbers of these influences to be smaller, and more significantly, the probability of expected occurrence for each would be low, and for this reason it is often referred to “assignable cause variation” (or special cause variation or non-quantifiable variation). In general, foreseen uncertainty are events that you’ve seen happen in your projects or other projects, so even though rare, you can “foresee” them happening, and therefore plan for them using risk management practices.
When I’ve seen risk management used explicitly to address foreseen uncertainty, the focus is on identifying, classifying, evaluating (quantifying), and then planning accordingly to reduce (avoid) potential for occurring or to reduce (mitigate) the negative effects. This is typical of how you would use “insurance” for example to mitigate the effects of a car accident, a home fire, illness, or an early death, along with of course working to reduce these occurrences through performing regular car maintenance, following safe driving practices, monitoring fire hazards in you your home, having a smoke/CO detector, eating right, and exercising.
In a similar fashion, many (technical) practices are “done implicitly” for the most part in “iterative and incremental” managed projects to address foreseen uncertainty. Some examples include: nightly backups, tested backups, software configuration management, continuous integration, automated unit-testing, automated integration testing, automated acceptance testing, and continuous code refactoring. In fact, the iterations themselves are intended to be a form of risk management. However, iterations address even more the uncertainty type we’ll discuss next.
For now, recognize “iterative and incremental” project management practices can be used to provide risk management implicitly for a number of foreseen uncertainty influences, but explicit risk management is still necessary for some foreseen uncertainty influences on your projects. In particular, look for possible events (rare, but foreseeable influences) in the less-well-known (or not-well-known) parts of your project that are not addressed by the common or similar technical practices listed earlier. You are using a number of those above listed technical practices, right?
Iterations and Unforeseen Uncertainty
Iterations, we’ve talked about from the beginning, in particular distinguishing between “iterations” as a series of short “sequential” (mini-water fall) deliveries and “iterations” as a series of “iterative and incremental” deliveries. Since we’re exploring project management with a new frame (lens) here, experimenting a bit, we’ll move forward assuming for the moment we don’t know there is a difference, don’t see one for ourselves, or don’t see a significance (this may be “reality” for most of us). My take, for the moment, from the article by De Meyer et al. is that from a perspective of types of uncertainty, what is key is that a series of “sequential iterations” can be a useful project management practice for addressing the next type of uncertainty we’ll look at in our projects.
This brings us to the third uncertainty type listed in our table, unforeseen uncertainty. De Meyer et al. describe unforeseen uncertainty as influences that can’t be identified in project planning, or if “foreseeable”, they are considered so unlikely you don’t bother with contingencies, or even risk management. This sounds a little odd at first, but contrast this with our earlier context of foreseen uncertainty and “insurance.” You don’t buy insurance for every “conceivable” negative influence remotely possible in your life (in some cases “insurance” doesn’t help you anyway).
These influences, remotely possible, and in some cases never imagined, we’ve seen experienced by others or ourselves, but only faced, when they occurred! During these times focus gets narrowed and acute, perspectives get shifted or re-oriented, and “planning horizons” often get shortened or very short (one day or one week at a time). There is still stability in terms of some assumptions and goals in these instances, but we are in a mode of coping with new situations or information, learning of still more new challenges, and required to explore new and other paths, while forgetting about pursuing others we thought were only recently still possible.
Unforeseen uncertainty results also from an unanticipated combination or interaction of a number of “foreseeable influences.” This is the case that most likely occurs on the not-well-known projects talked about earlier. When unforeseen uncertainty is encountered as we take on a not-well-known project, just as we’d similarly do in our personal lives, our project management practices too need to change to a more narrow focus or “bite-size” approach, and this is where “sequential iterations” come into play more significantly.
The more not-well-known the project, the shorter the planning horizons need to be, and the more frequent they must be revised. The project management perspective and role also “shifts away” from planning and monitoring progress of a few large milestones, and is “re-oriented toward” an emphasis on learning, adapting, exploring new paths or solutions, and creating along the way (more just-in-time, and incremental) new and smaller milestones (targets), and to a greater monitoring of assumptions.
To be clear here, with unforeseen uncertainty you go beyond using predictive or risk management as you see in traditional project management approaches; you incorporate sequential iterations, making them shorter and more frequent as unforeseen uncertainty influences increase, and you shift your perspective from planning and monitoring long range, to an emphasis of adapting, learning, exploring, monitoring assumptions, and reaching frequent incremental smaller milestones (targets).
In the software development contexts I’ve most recently worked in over the last seven years, sequential iterations are the predominant project management practice used in particular because much of software development is related to implementing “never-done-before or new-to-us” features and often using “never-used-before or new-to-us” technologies as well. However, in these contexts, we continued to experiment, using variable (not uniform fixed-length) iteration lengths, and have also decoupled various project aspects (planning, development, incremental deliveries, retrospectives, etc.) from each other, as we discovered more effective iteration frequencies (natural “cadences”) for each aspect.
Project (Assumptions, Goals) Reviews and Chaos
Project reviews, as often described, are likely to be viewed as a status update on the project or an incremental product review. But in our context of discussing uncertainty types, I’m referring to a “review of the overall projects assumptions and goals.” That is, “re-thinking” the project assumptions or goals in whole, not just a “refinement” of the project assumptions or goals.
This brings us to the fourth uncertainty type in our table, chaos. At first glance there may not appear to be any value talking about chaos in projects. Again, contrasting often helps us improve our understanding. De Meyer et al. describe chaos as “extreme uncertainty” and contrast it to unforeseen uncertainty by distinguishing along the lines of the project’s assumptions and project goals. Projects with extreme uncertainty have unstable overall assumptions and goals; projects with unknown uncertainty, while they can approach an appearance of being “chaotic” at times, for the most part maintain a degree of stability along key project assumptions and key project goals.
Projects with “extreme uncertainty” are also often referred to as research and development (R&D) projects. In these types of projects, extreme uncertainty is fully understood and expected. Project reviews in this case have little or nothing to do with obtaining status or “refining” stable project assumptions and goals, but rather much more about “re-thinking” and “re-defining” overall project assumptions and goals based on the latest information. Often, from R&D projects the original “objectives and hoped-for results” are not the end product from these efforts.
I don’t have experience working in a full R&D environment. However, I’ve been a part of team that worked on a project where the original goal was something that had not been done in the business domain. Over the course of the project the main overall goal remained stable, but many project assumptions and sub-goals along the way were unstable, and in fact for a time we were working in an R&D (very chaotic) mode. The team delivered on the project’s primary goal, reasonably near (within months, not years) the company’s desired timeframes, and it was in fact a “first ever” type of product release in this business domain.
While the end result was a successful product release, it was also definitely a narrower and “much refined” version from many of the product targets conceived along the way. It too was the most exciting (fun), challenging (demanding) project I’ve worked on, and as you might imagine provided me a great opportunity to learn a tremendous amount about managing (not controlling) and leading a project with a great deal of unforeseen and, at times, extreme uncertainty.
Closing Thoughts
Look for “differences” between the projects you manage and be open to considering that even a single project may not be “entirely” well-known or not-well-known. Experiment with using measures of variance to “aggregate” small numerous influences inherent in your project, and eventually across projects, and see if they enable you to create, over time with less effort, more predictable “milestones” over longer planning horizons.
View iterations, and in particular the technical practices they enable and that you’d implement, as implicit risk management to address foreseen uncertainties (negative influences that are rare but you see happen); but, also recognize where explicit “traditional” risk management practices are still needed in your project for these types of uncertainties (insurance where needed). When a project has the characteristics of a not-well-known project we discussed, experiment with iterations, if you’re not already, and shorten planning horizons to a point where you’re more regularly meeting “milestones.” [My first “iterative” effort divided a traditional managed project with a twelve month planning horizon into three iterations, each four months long; in time we did evolve to delivering incrementally in the range of weeks].
But more importantly alter your role (and other’s perspective) to being more focused on adapting, learning, and exploring alternate paths or solutions. Lastly, as you manage your changing projects, continue experimenting and tweaking your practices while keeping the quotes at the top of the post in mind!
Take care,
Frank