Sid Kemp is a business consultant and author of 10 books on project management and business success.
Progressive Elaboration - Build Project Success Step by Step
Many people fear creating a good project plan - they think it takes too long. The Project Management Institute (PMI) has a solution called Progressive Elaboration. It's a fancy term for doing good design step by step until we deliver great results.
A complaint I often get from people I train in project management is that it must take way too long to define a project precisely enough to prevent project disaster. They are concerned that we will plan forever, and never get any work done.That is a real concern, and I call it paralysis by analysis. But excellent planning and design does not need to lead to paralysis by analysis.
Understanding three key points will unlock the idea - and the value - of quality design through progressive elaboration.
- Precision is not the same as detail.
- Getting it right the first time is cheaper.
- We don't have to design it all at once, up front.
Read on to learn more.
Precision is Not the Same as Detail
The key to progressive elaboration is that we can start at a very high level, with a general picture of what we want. Then we can move ahead with the project, and move down into finer and finer details as we go. That way, we start working early, and we keep working as we develop our design. This prevents paralysis by analysis.
To do this well, we must be very clear: A high-level scope statement or design may not be detailed, but it must still be precise. It can be short and simple, but it must be free of all vagueness.
A Case Study: Website Improvements to Increase Conversion Rate
In this case, typical from my consulting work, we look at a company that has a good marketing and advertising campaign - many people are coming to their web sites. And market research shows that the people who are coming are in their target market. Also, they have a good, steady product line - no need to change things there. But, after people come to the site, many do not buy. We need to increase the conversion rate, also called the close rate. What can be done?
Let's progressively elaborate the scope of this project:
- Executive level scope statement: Changes will be made to the website to increase conversion rate, that is, the percentage of people who actually buy something out of those who arrive at the site. Once we increase that rate, we want to maintain the new rate. Scope exclusion: There will be no changes to marketing or to our product line. Those check out fine.
- Executive level measurement: This would involve the current conversion rate, studies of industry-standard conversion rates, the setting of goals for a new conversion rate by a specified date.
- Management level scope statement: Changes to the website must increase conversion rate without interfering with uptime, productivity, or shopping cart and financial management. Changes and their consequences must be traceable, so we learn what to keep, what to throw away, and what to keep improving.
- Management approach: Management selects certain products to experiment on. Successful experiments will be replicated to all appropriate products.
- Technical issues: We research details, listed below.
- Technical approach: We design experiments, testing different options to compare them and see what works.
These six steps progressively elaborate the project design. Each level of thinking provides more detail - more elaboration - as we make progress designing and implementing new web pages.
Note that there are at least three different teams of people - probably four, if we have both technical marketing experts and technical programmers. Each team comes on when needed and adds to the detail essential to success.
More elaboration: Diving Into the Marketing Details
Here is a partial list of technical details of marketing (not of web design) that the project will work on to increase the conversion rate.
- Fewer clicks to close. Studies show that the more clicks between arriving on a page and closing the deal, the more people abandon the site. So pages can be streamlined to increase the conversion rate.
- Creating a sense of urgency. If a product looks like it will be around later, people often delay a purchase - and then never come back. The technical marketing team may have to return to the executives to ask if short-term discount sales are an acceptable way to increase the close rate.
- Eliminate confusion. Detailed instructions and lots of legal language will reduce the close rate.
- Direct landing pages. Ads should go straight to landing pages that are sales pages for the item advertised.
- Welcome customers back. Using cookies, customer login, or both, we can direct returning customers to where they most want to go. We can also check back with the executive about keeping credit cards on file to streamline future purchases.
As you can see, none of these ideas needs to be thought of at the beginning. The executive level sets the goal, the management guides direction, and then the technical teams progressively elaborate how the changes will achieve the goal.
Artists Have Always Used Progressive Elaboration
Getting it Right the First Time is Cheaper
On any project, there are only three choices in terms of quality and results:
- The least expensive choice is to get things defined right the first time.
- The second option is to get it wrong, then fix it during the project.
- The third option is to get it wrong, and deliver bad results.
So, all in all, it is better to be clear and precise at the beginning. How much better? Scores of studies over the last 40 years have shown that the there is a ratio across the cost of preventing an error; the cost of fixing an error during the project; and the cost of cleaning up the mess after the project. And the minimum ratio is 1:10:100. So an error that can be prevented in an extra hour of planning at $100/hour will take ten hours of project time and $1,000 to fix during the project, and take 100 hours and $10,000 if we have to do a recall after the project is done. And ratios much higher than 1:10:100 have been found if we use best practices in quality management to do defect-free design from the very beginning.
The Lesson: Progressive elaboration - developing more detail as we move forward - always makes sense. Sloppy work never makes sense.
We Don't Have to Do it All At Once
We do good, clear work every step of the way. At the same time, we don't have to get the whole project defined all at once, or define all the details at the beginning. Instead, we can work in stages. We are clear and accurate in each stage, but we get more detailed as we go. This is called Progressive Elaboration. Doing it well includes:
- Starting with the big picture, and working our way down into the details.
- Being clear in each meeting, writing up the results, and getting them confirmed.
- Keeping track of how much we have defined, and how much is not defined yet.
- Bringing the right people to each meeting. Early meetings are more likely to be with executives and higher-level managers. And we project managers are likely to be at all the meetings. As we seek to discover details of process, workflow, and interface, we work more with the workers. And, as meetings get more technical, we need more technical people (such as programmers and engineers) involved on the project side.
- We keep going until every detail of every feature of the product or service we are creating or improving is defined. However, we may have a lot of the program written or the product developed as we continue to detail out other parts.
Progressive Elaboration for Projects That Fix Problems
Projects that fix problems are a special case where progressive elaboration is particularly useful.
A problem is something that has come up that stops the company or a production line from working the way it used to work. So the goal is already clear: Get this d**mn*d thing working! Executive involvement is minimal, and managers have little to do except provide support. In fact, since managers already know what the "thing" is and how it's supposed to work, "Get this d**mn*d thing working!" is a complete and precise statement of high-level, executive scope.
Case Study: 2006 Launch Delay of the Space Shuttle Atlantis
A good example of this type of project occurred in 2006, when problems in a 10-year-old fuel gauge that measured the amount of hydrogen in the fuel tanks on the Space Shuttle Atlantis went on the fritz. The gauge became unreliable, sometimes showing the tank was empty when it was full, and the problem was intermittent.
The executive level scope statement would be clear: Fix the fuel gauge so we can fly the shuttle!
However, as we investigate the problem level by level, using progressive elaboration, we find four technical issues that make it more and more difficult to solve the problem:
- Management decision: If we know the gauge is faulty, can we just turn it off, and rely on other gauges, and fly anyway. There was a lot of debate about this. But it was finally decided that an essential safety feature, Main Engine Cut Off (MECO) would not be reliable without this gauge. So the management decision was that the gauge had to be fixed.
- Technical issue: The problem was intermittent. Therefore, any test that was passed was not proof that the gauge was working and that the shuttle could fly safely. The specific problem had to be found to be sure that it was fixed.
- Detailed technical issue: The gauge was not a simple device. It involved many different components and the electrical connectors between them. Some of these were buried deep in the shuttle's wiring. Just locating all the components and cleaning their connectors was a big job. More than once, the engineers thought they had fixed the problem, but the gauge did not test clean.
- Very detailed technical issue: The design plans for the Space Shuttle may not have been an exact match for the Atlantis as it was built. Parts had been upgraded and replaced. One engineer reported that finding all the parts of the gauge was an exploratory mission, that they were still finding out how the Space Shuttle worked!
This illustrates how a very simple executive directive must be elaborated progressively to finer and finer levels of detail to ensure success. However, this elaboration does not have to occur as part of planning. As each component of the fuel gauge was reached, it could be cleaned, tested, and documented. This is what is meant by progressive elaboration on a project that fixes a problem.
Progressive Elaboration is Not Just for Scope
Although this article focuses on progressive elaboration in developing the Scope Definition and Work Breakdown Structure (WBS), the concept of progressive elaboration is broader than that. In fact, it can be applied to all nine areas of managing a project. Here are some examples:
Progressive Elaboration of the Project Communications Plan
The first version of the project communications plan might just be a contact list of team members and project customers. We elaborate this by:
- Identifying all project stakeholders and adding them to the list
- Deciding how to communicate with each stakeholder
- Deciding how to include the Voice of the Customer in the project
Elaboration of Risk Management in a Project
The formal steps of Project Risk Management progressively elaborate our definition of project risk - what could go wrong - and our response through:
- Risk identification, where we make our initial list of risks.
- Risk analysis, where we evaluate and prioritize risks
- Risk response planning, where we decide what to do to prevent risk events, and what to do if they happen
- Risk monitoring and control, where we watch for risks, seek out new risks, and handle them as they happen.
From these examples, you can see that progressive elaboration is a standard practice for all nine areas of project management.
Progressive Elaboration and Project Life Cycles
Progressive elaboration can be applied differently on different projects. In choosing how to do progressive elaboration, the key is to link the elaboration of detail to the project life cycle you are using.
Progressive Elaboration in the Classic Waterfall
In the classic waterfall, or system development life cycle (SDLC) all planning precedes execution. Therefore, progressive elaboration of scope all occurs in the planning stages.
Progressive Elaboration With Fast Tracking
If the classic waterfall is modified to allow fast-tracking, then the whole product is broken up into modules. As planning is completed for each module, development can go ahead for that module, while others are still being planned. In this life cycle, some modules are elaborated faster than others.
Concurrent Project Management
Concurrent project management was developed by Hewlett-Packard and is now used widely in the automotive industry. By bringing together all the different specialists at the beginning, a project life cycle (say, for bringing a new concept car to market) can be reduced from five years to 18 months! In concurrent project management, progressive elaboration is done early and fast by cross-functional teams.
Zero-Defect Software Development
The zero-defect method of software development focuses on precision to prevent errors from getting into the code. Early elaboration of design, followed by early elaboration of the code itself, with multiple reviews puts multiple eyes on the problem, creating the highest quality software at the lowest cost. By putting 80% of the effort into good design, testing and debugging, which are expensive, are drastically reduced.
The Spiral Model
The spiral model was a precursor to Agile Development. It puts features on a schedule, and, if a feature runs late, it is dropped to a later cycle in the spiral. each feature is elaborated as it comes up for design and then again, in the next cycle, when it comes up for development.
JAD and RAD
JAD, joint application development, and RAD, rapid application development, are not actual life cycle alternatives. Rather, they are techniques of requirements elicitation that affect the life cycle. Putting designers and programmers in close proximity to their clients, the users of the application, speeds up development. Frequent meetings allow for rapid progressive elaboration. And this approach is a key component of Agile Development.
Progressive Elaboration in Agile Development
Agile Development, also called Agile Programming, is the latest approach to the project life cycle, and works particularly well with today's object-oriented code and web development platforms. Programmers work closely with the customer, often residing permanently in each customer department. Using prototyping and rapid modification of applications, design is merged with development. Progressive elaboration is a constant process throughout the project.
What Do You Think of Progressive Elaboration?
Progressive Elaboration Keeps the Project Moving
So, the final lesson is this: Whatever type of project we are working on, and whatever life cycle and other methodologies we choose, we don't plan, and then go. With progressive elaboration, we plan and we go, and we keep planning as we go.
This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.
Saviz on September 26, 2017:
Dear Mr. Kemp
Regarding your article, I want to plan a project with progressive elaboration. I just want to ask how to get progress from the plan when the size of the project change over time. As in my project, resource will not be allocated until the next month.
Would you please send me a plan of progressive elaboration as a sample?
I look forward to hearing from you.