When I was teaching my Project Management training to a client last week, my client said something that stuck with me, “Our problem isn’t progressive elaboration, it’s perpetual elaboration. We will analyze and over analyze and spend so much time trying to break down the work that we forget to do the work.” Such a strong point.
We were talking about right-sizing process. I always emphasize the importance of making sure to check every step along the way that you aren’t doing too much process and not enough work. We talked about work breakdown structures and the concept of Progressive Elaboration.
If you haven’t heard this term, or it’s been a while, “Progressive Elaboration” is a method of continuing to provide further detail into the planning process as it becomes available. The goal is to help the project team to continue to manage with greater accuracy, control the process more effectively, and achieve greater success with project delivery.
Many organizations struggle with, and are on the lookout for, the cases of analysis paralysis that usually takes place during the requirements phase. Another thing to look out for is perpetual elaboration. This is when you spend way too much time focused on getting the schedule perfect and breaking it down to such a level of detail that the project schedule itself becomes unmanageable. We’ve lost sight of the thing that’s most important: DOING the work.
Think about it. What level of detail do you actually need to go to in the schedule and what level of accuracy do you really need in order keep the project moving? Don’t let the planning process become so much of the work that the work isn’t getting done. Instead, look for the level of “just right” that gets you the information you need to move the project team forward and get to the business of getting work accomplished.
Your goal is to elaborate on the plan as you are progressing through the life cycle and gaining more knowledge about the elements that make up that plan. Your goal is to progressively elaborate to a point that is useful to you and the team to keep the project moving forward in the right direction. To keep the team focused on the work of getting the project done.
What you want to avoid is the process of making the project management too much of the work and spinning cycles on getting the plan so detailed and so elaborate that it becomes an unmanageable tool that gets in the way of productivity instead of supporting it.
Progressive elaboration by phase
Let’s look at it from the various project life cycle phases. When you are in the beginning stages of defining a project, a phase I call “Discovery,” you don’t yet know all the details of that project or what will go into ensuring success. You are building a business case and starting to define the “what” and the “why” of the project. At that time, we cannot provide a great deal of accuracy as to how long the project will take or what resources will be required for it to be successful. Make sure you are asking the fundamental questions about the goals, purpose – the why of the project and whatever other details are needed to ensure that the decision makers can make an educated and informed decisions about the priority of this project relative to others and whether or not it should be given the “go ahead” to proceed.
Then, we go into an “Initiation” phase where we develop the charter and start answering some very high-level questions about resource needs, risks, scope, etc. We know a little more and have done a little more digging. We have continued to elaborate on the scope, timeline, etc. We don’t yet know the details of what the plan will reveal, but we have answered another level of questions.
Now we hit “Planning.” During this process, we should begin to develop requirements so that we can effectively plan the work, based on that scope. We build a work breakdown structure (WBS) to further define the work of the project. We know a little more, we are progressively elaborating on the scope, and with that, we can now start addressing the timeline, we know more about what resources we need and when, etc. However, there is still more to learn as we continue through planning and into actual project benefits delivery.
As we continue onto “Delivery,” the execution phase, we then learn more about what reality is going to do to our schedule. Our friend Murphy (remember Murphy’s Law?) peeks his head into our plans and we need to adjust. We are going to learn more and we are going to have to take those learnings and apply them to the schedule and see what impacts are generated…we are progressing and we are elaborating.
This process continues through project delivery, generally, and sometimes doesn’t end until the project does. This can be OK, if we are maintaining a strong hold on scope. We can certainly continue to provide more detail to the process if it’s useful, but if we aren’t controlling the scope process, this is where we will experience scope creep.
Scope creep happens when we don’t have a good change management process to help us control change to scope and we allow too many of the “it’s just one thing, it’s just one feature” kind of conversations to happen. Each one of those, by the way, can be addressed with a “Yes, and…” meaning, we can say, “Yes, we can make those changes and here’s what the impact will be to our timeline and costs.” It’s the triple constraint dance we all must do.
Don’t let them put you in the position of always saying “no” when “yes, and…” will address the situation and put the onus back on the requestor to own the decision and impacts.
So far, progressive elaboration sounds like a nice and healthy process that we do to address new information that comes to us as we go through the project phases. It is. It should be done. It’s helpful to know that it’s perfectly OK to not have all the answers upfront when you start a project and that you will get more information later and can update your plan accordingly. What you want to avoid, however, is spending so much time and energy on getting to the lowest possible level of detail that tracking status becomes a full-time job and you become a low-level tasker instead of a benefits delivery project manager.
Remember, there is no such thing as a perfect plan…until the project is over and we’ve gone back to update that schedule to reflect what happened.
If you are a project manager or responsible for project management process in your organization, think hard about what you require of yourself and the team in terms of project planning activities and deliverables. I highly encourage you to spend sufficient time doing planning upfront and being prepared to adjust as new information becomes available, however you do not want to spend the vast majority of your time focused on continuing to iterate on that same plan at the expense of project delivery.
Remember that project management is not the end game. Project management is the process that we use to drive business results. Your job is to know when and how to use the tools of project management to help you drive those business results in the most efficient manner possible.
Thanks for taking the time to read this article.
I welcome your feedback and insights. Please leave a comment below.
See you online!