This article focuses on the task level of a project which is the key to merging the different methodologies. There is a lot of articles on line that explain what the merger will look like and the pros and cons of it but I found nothing to explain HOW TO DO IT? This article goes into quite a bit of detail but I felt I had no choice to convey to the reader how to merge the two methodologies with examples.
Agile was created for software development projects. Some of the key benefits of this methodology are flexibility, speed, high quality, and continuous improvement. These features are implemented at the Scrum level. One major problem with Agile is that it does not scale up to large projects due to lack of structure, changing requirements and scope, and lack of a baseline to measure project performance. In my opinion, it works well for small software and IT projects that are less than a year in duration and less than $1M in value.
The Waterfall methodology (sometimes referred to as the PMI method) has structure. The requirements, budget, and schedule are defined at the start of the project. A baseline to measure performance is established at the start of the project. Work is done at the work package (WP) level which is analogous to the Scrum level for Agile. This article describes the WP, planning package (PP), rolling wave (RW) and the Integrated Master Schedule (IMS) which when baselined becomes the performance measurement baseline (PMB) and Work Breakdown Structure (WBS) for each style. These components are part of Earned Value Management (EVM). They are a necessary part of this article to explain how to merge the two methodologies. A discussion on all aspects of EVM is outside the scope of this article.
Why Merge the Two Methodologies?
The most important benefits of merging the two methodologies come as a result of blending the strengths of waterfall and agile methodologies which include: improving the ability to respond in a timely manner to feedback from users, team members, and management, fixed baseline against which project performance can be made, and sufficient structure to facilitate scaling to large projects.
How to Merge Agile with Waterfall
The question becomes-how can the two methodologies be merged to provide the agility, flexibility and speed with a more structured approach and performance measurement? The key to answering this question is the OKR (Objectives and Key Results) approach created by INTEL in the 1980s. The OKR is the linchpin that will make the merger possible.
This paper proposes how merging the best of both management methodologies is practical and can work.
Agile
Work is accomplished at the Scrum level. The project team and tasks are managed by the Scrum Master. This level is where flexibility, speed and agility take place. The team meets typically monthly and decides what tasks need to get done. A month later the team meets to review the status of tasks. Any task not started or partially completed are designated as backlog. The Scrum Master moves the backlog into next month as well as the revised or new tasks. This cycle continues until the project is completed or discontinued.
Waterfall
The following are descriptions and explanations for the key EVM components that will be needed to implement the merger. I am using the Gas Generator System throughout this article to illustrate my points.
Work Package (WP)
A WP defines a task as well as the budget and schedule. It spans a relatively short span such as 3 months. A WP includes activities that must be completed before the work package can be closed. A unique charge number is assigned to each work package to collect the costs for anyone working on it. This is necessary to measure project performance as later explained in this article.
Planning Package (PP)
PPs include efforts that will eventually be identified as separate WPs. They represent far term efforts that cannot be defined in detail at the start of the project. Planning packages includes a budget, and general description.
WP Integrated Master Schedule (IMS)
Figure 1 shows a design WP IMS including the activities and PPs. The first cycle is 3 months long. Near the end of this cycle PP1 is detailed out into WPs that include any changes to the task, budget and schedule that are needed or desired to be changed.
Figure 2 (generated by Humphreys & Associates, one of the best earned value companies in the U.S.) shows the RW approach. The figure shows the first RW cycle to be 9 months duration during which detailed WPs are defined. The remainder of the work is included in the PPs. A RW cycle can be as short as 3 months or as long as needed to suit the project.
Integrated Master Schedule (IMS)
Figure 3 shows the IMS for the Gas Turbine Generator System project. It shows the design WP and other WPs. Only a segment of the IMS is shown due to space constraints. Typically, would be hundreds of WPs and PPs. As shown, only the WP activities get scheduled. The light lines show the links between activities that defines the project schedule logic.
Performance Measurement Baseline (PMB)
Figure 4 shows the Design WP with a PMB. Once the IMS for the project has been approved, it can be saved as a PMB using a feature built into Microsoft Project. It represents the project plan. The PMB is fixed and can only change at the direction of the customer.
As shown in Figure 4, the current schedule has slipped to the PMB. The analysis activity duration was extended. Every activity linked to it also has slipped. The question becomes, why did the analysis activity need more time? You can see problems visually and early allowing maximum time to fix the problem.
Waterfall Work Breakdown Structure (WBS)
Figure 5 shows a segment of the WBS for the Gas Turbine Generator System. There are four levels. The important level for this article is the WP level. This is where work is accomplished. Only a segment of the WBS is shown due to space limitations but there would be hundreds of WPs and PPs for the project.
Objective and Key Results (OKR)
OKRs originated at INTEL during the early 1980s. Some years later they abandoned OKRs but have come back to them and are using them presently. My understanding is Silicon Valley has been using OKRs for years. Apple is one of the companies. According to the Scrum Alliance, “Scrum is an Agile framework for completing complex projects. Scrum was originally formalized for software development projects, but does not work well for a large complex project. The OKRs framework brings into practice some of the essential elements missing from Scrum. One of them is a way to measure performance.
Scrum and OKRs complement each other. OKRs are how you track progress around measurable goals. An Objective is what is to be achieved which is usually the product the project is delivering. Key results define how you get to the objective. The OKR activities are specific, have a timeline, budget and yet realistic. Most of all, they are measurable and verifiable. An OKR should be 3 months in duration.
The Scrum Master is still the leader at the Scrum level with OKRs. He /she can apply speed, quality and creativity to define the activities in terms of task description, budget and schedule. Each week the Scrum Master reviews the status of each activity under the OKR. He/she will still do that but get an estimate for each task in regards to the percent complete. He/she can then input that data to a planner who can work with finance to measure performance. Since each OKR will have a charge number assigned to it for anyone who works on the OTR, finance can determine the actual cost for each OKR. As a result, all the information required to measure OKR performance is task percent complete and actual costs. Finance can then publish the performance of each OKR for the project manager and management to review. Finance report can be color coded (red is bad, yellow is caution, green is good) to easily find the poorly performing OKRs allowing maximum time to determine the root cause and put into place an action plan to mitigate the impact on the project.
Figure 6 shows the OKR for the design task PMB and current schedule. It looks just like the WP PMB. There is very little difference if any between the two at the tasking level. You can see the analysis activity slipping impacting the project IMS.
Figure 7 shows the Gas Turbine Generator System with OKRs WBS. It looks very similar to the Waterfall WBS. On a typical large complex project there would be hundreds of OKRs and OKR PPs. The figure shows a simple view of one OKR to illustrate the point. Even though Agile was developed for software development projects, I wanted to show how it would work for a development project with an objective or delivering the Gas Turbine Generator System.
Integrated Master Schedule (IMS)
Figure 8 shows a partial view of the IMS for the OKR approach. As shown, the objective is the Gas Turbine Generator System. A total of 4 OTRs are shown. 2 for the Compressor/ Turbine and 2 for the Recuperator. For a large complex project that has a period of performance of 2 years, the IMS would show all of the PPs required to deliver the objective. Figure 8 looks very similar to Figure 3.
Summary
Blending the strongest parts of each methodology should result in a faster, more flexible, and less costly approach if implemented properly. That is why merging them makes sense and it is also practical to do. This article explains HOW TO DO IT.
The linchpin that makes it all happen is the OKR. An OKR has a budget, timeline, and performance measurement. The OKR corrects a lot of short comings with the Scrum approach, especially the performance baseline. A number of companies are using it successfully.
For Agile and the Waterfall approach, work is accomplished at the task level. That is the OKR level for Agile and WP level for Waterfall. The OKR is very similar to the WP. They both have activities. The activities have a budget and schedule. Both have a performance baseline.
OKR planning packages can be altered or changed once detailed out to adjust scope, schedule and budget for each activity. The Scrum Master can still apply the adjustments, flexibility and agility desired and required to OKRs.
Bio:
Currently John Ayers is an author, writer, and consultant. He authored a book entitled Project Risk Management. It is on sale on Amazon. He authored a second book entitled How to Get a Project Management Job: Future of Work. It is on sale on Amazon. The first is a text book that includes all of the technical information you will need to become a Project Manager (PM). The second book shows you how to get a PM job. Between the two, you have the secret sauce to succeed. There are links to both books on his website. https://projectriskmanagement.info/He has presented numerous Webinars on project risk management to PMI. He writes columns on project risk management for CERM (certified enterprise risk management). John also writes blogs for Association for Project Management (APM) in the UK. He has conducted a podcast on project risk management. John has published numerous papers on project risk management and project management on LinkedIn. John also hosts the Project Manager Coach club on clubhouse.com.
John earned a BS in Mechanical Engineering and MS in Engineering Management from Northeastern University. He has extensive experience with commercial and U.S. DOD companies. He is a member of the Project Management Institute (PMI. John has managed numerous large high technical development programs worth in excessive of $100M. He has extensive subcontract management experience domestically and foreign. John has held a number of positions over his career including: Director of Programs; Director of Operations; Program Manager; Project Engineer; Engineering Manager; and Design Engineer. He has experience with: design; manufacturing; test; integration; subcontract management; contracts; project management; risk management; and quality control. John is a certified six sigma specialist, and certified to level 2 Earned Value Management (EVM).
Go to his website above to find links to his books on Amazon and dozens of articles he has written on project and project risk management.