A Project Management Article by Mark Tolbert
In January 2012, Mark Tolbert presentated a popular PM Tools Workshop "Agile Project Management versus the PMBOK Guide and Earned Value Management". This article is Part Five of a seven part series that he wrote on the topic. To read earlier parts, please visit www.pmiwdc.org/articles. Be on the look out for the August and September Newsletters for the last two sections. You can also access a print friendly version of the article.
There Are Two Different Philosophical Approaches Being Defined!
PMI is right that a number of the key parts of the Agile approach can be seen as extensions of the approach defined in the PMBOK® Guide:
- The PMBOK® Guide supports doing projects in an iterative manner. Iterations or Sprints can be seen as a special case of Rolling Wave Planning.
- The formal change control systems and configuration management systems required in the PMBOK® Guide are not intended to repress change or enforce the original baselines.
- The freedom and the empowerment provided the project team members in Agile, and the role of the project manager as a facilitator in Agile, can be seen as just one possible model that the PMBOK® Guide could allow.
However, this doesn't completely settle the issue. It doesn't get to the heart of the matter: the approach defined with Agile methodologies fundamentally does go a different direction from the direction defined in the PMBOK® Guide.
The PMBOK® Guide is a formal ANSI standard for how a project should be done. It is a prescriptive or “push model.” The PMBOK® Guide defines a framework of nine knowledge areas, five process groups and 42 processes. Each of the 42 processes belongs to both one knowledge area and one process group. As PMPs, part of the standard is that for every project at some point in time we should use each of the 42 processes. (In every knowledge area, there is an introductory paragraph that reads, “Each process occurs at least once in every project and occurs in one or more of the project phases, if the project is divided into phases.”)
Also, as PMPs, for every project we should develop a very detailed, "fine-grained” project management plan that is formal, and which contains upwards at 15 subsidiary plans and baselines. We would never do a project without developing such a complete project management plan. For example, it would be poor project management – (some people say a violation of the Code of Conduct!) – to do a project without a written Communications Management Plan, Procurement Management Plan, Risk Management Plan, etc. This project management plan must be formally approved by key stakeholders - senior managers, the sponsor, functional managers and sometimes even the customer - before we start the "execution phase.”
Additionally, as project managers we are using many other documents to support the project management plan: e.g. - Requirements Documentation, Requirements Traceability Matrix, Issue Log, Change Log, Risk Register, Assumptions Log, … See the appendix on page 350 in the PMBOK Guide for the complete list of all 38 project documents! (PMI includes language for any of the components of the Project Management Plan: “… the plan can be formal or informal, highly detailed are broadly framed, and based on the needs of the project.” But, since all the subsidiary plans are part of the formal project management plan, and must be written documents, PMI is expecting some level of formality for all of them.)
Also, PMI strongly recommends that Earned Value Methodology (EVM) should be used on all projects. As PMP's we completely understand that if we are not using EVM we really have no idea at any given point in time in a project the true value of work that's been completed: we have no idea whether we are truly on budget or on schedule! However, in order to use Earned Value Method, we must have very accurate baselines defined right at the beginning of the project.
In order to have such accurate baselines, we need to have gone through in-depth planning that could provide "bottom-up estimates" for the baselines. We would really have to go through all the planning processes defined in Scope Management, all the planning processes defined in Time Management, and the two planning processes defined in Cost Management. And this really wouldn't be enough! In parallel with these planning processes, we would really need to do all of remaining planning processes in all knowledge areas – and there are a total of 20 planning processes!
So in the PMI model, we are doing very in-depth detailed planning at the beginning of the project, and getting the project management plan formally blessed before we start execution. This is very prescriptive. As PMPs, we understand we should not skip any of these planning processes.
On the other hand, the Agile model is a much more flexible, “pull” model. Where the project requirements are volatile and are going to change – when we don't know what we want exactly upfront - we will need more of a “pull concept.” We will discover requirements, and let them emerge; therefore, we need more of a JIT approach – (“Just-in-Time” approach).
We will let the team choose as they move through the project what documentation is needed, what type of subsidiary planning is needed, and what level of detail is needed in the plans. Some of it will be invented on the fly. APM defines basic guidelines, and provides tools and techniques and best practices for the team, but allows the team at great deal of freedom and flexibility for how to deal with the individual project they are working on.
In APM, we do not typically have the three baselines that are defined in the PMBOK® Guide: – (Scope Baseline, Schedule Baseline and Cost Baseline). Therefore, we cannot use Earned Value to measure our performance in the typical way. It is understood at the beginning of the project that the requirements will be changing significantly. Since we don't know what the final features will be for the product, we don’t how many prototypes or iterations it will take to develop the final solution. Therefore we cannot give a final projection for the budget – (the BAC or “Budget at Completion”), and cannot accurately estimate the schedule out to the end of the project.
Yet, we do have baselines for each of the individual iterations or Sprints! Since each iteration or Sprint is a well–defined, time – boxed effort, it is clear what the schedule will be, and also it will be easy to calculate the costs for each iteration – (since we know the labor costs and the tools and equipment that will be needed.) The problem in APM will be forecasting the overall budget for the entire project, and the overall schedule: putting all the iterations together into a release plan, and projecting a final schedule and budget for the project. This is much more difficult in Agile, and is probably the source of most complaints of using this approach. We will address this again in the summary.
Requirements Gathering, Scope Definition and the WBS
There is another key area where APM and the PMBOK Guide go in quite different directions. This concerns how scope requirements should be collected, and how these requirements will be decomposed into more detailed requirements.
In all the Agile methodologies, it is essential that we define our requirements in a very customer focused way. We first ask, "What is the customer looking for?" So, the requirements start out as high level functional or business requirements – (capabilities) – and as they evolve into more and more detail as we progress through iterations, they still stay focused on the customer's view. “Capabilities” eventually evolve into “features” and then “stories," or tasks. Team members estimate the amount of time it will take them to accomplish their work in terms of these stories or tasks. (Even at the lowest level, a story is something that returns customer value.)
In the PMI view, we also start with the customer view of requirements, but we quickly translate these customer requirements into engineering or design requirements. In the process Collect Requirements, for new product development, we use tools such as Voice of the Customer – (VOC) - which is part of Quality Function Design – (QFD) to first get the customers’ requirements. (In software applications, we use something quite similar – Joint Application Design – JAD.) We get our engineers out of their offices, and out of their cubicles, meeting with customers, following them around in their daily jobs, observing what they're really doing, perhaps trying out the customer's job, and truly understanding the customers’ needs.
However, in QFD, we then map the customer requirements onto detailed design requirements and engineering requirements. (In Six Sigma, this is captured in a "House of Quality," or a Matrix Diagram.) For PMI, we also trace this evolution in a document called the “Requirements Traceability Matrix.” This helps the project team determine if the final detailed engineering design requirements and testing requirements really do satisfy the original business and customer requirements. The engineering requirements eventually get translated into the Scope Statement, and this gets decomposed into the WBS. The WBS is all about deliverables, products and nouns: it breaks down products in a hierarchical manner from products – to platforms – to groups, and eventually to components and parts. It needs to include project scope as well as product scope, but it is all about deliverables.
On the other hand, in the different Agile methodologies, we stay with a completely customer focused hierarchical breakdown: we go from applications – to business area – to capabilities – to features, and finally to stories or tasks.
Our team members will plan how to do the stories, and will write up story cards. On the back of each story card, they may define the technical engineering and design requirements for each story, but they develop their estimates from the stories.
This is not just a minor difference of opinion of the proper way to collect requirements and define the scope for the project. For the advocates of APM, it indicates a completely fundamental difference in the point of view about obtaining requirements, and shows a completely different mindset.
The question is, do we try to define in detail on paper all of the customer’s requirements up front, and translate these into detailed engineering specifications – on paper? Or do we take a totally different approach of gathering the customer’s requirements and desired capabilities at a high level, and then let the requirements emerge or be discovered through the iterative creation of prototypes.
As we have seen, when there is a lot of uncertainty concerning the requirements, the advantages of using the APM approach are:
- If we try to define all requirements in detail upfront, we will often find later that many of these requirements were not needed. Therefore, with APM, we can cut out a lot of wasted time.
- When there is a lot of uncertainty with requirements, it's a waste of time trying to estimate detailed activities and tasks for those requirements. (You cannot accurately estimate the unknown.)
- If we can quickly create prototypes – (or iterations) – usually within one month iterations, and get customer feedback on these iterations, we will much more efficiently and practically identify the requirements. Again, “If a picture is worth a thousand words, then a prototype is worth a thousand pictures!”
- We will have a cross functional team working together creating the prototype – (or the iteration) – and this is all centered on capabilities, and features that provide functionality for the customer. During the iteration, we come up with a working prototype that is tested and documented. Therefore, the work that would normally occur across several phases in the traditional model – (design – implementation – testing – documentation) – all occurs within a one month iteration, and the cross functional team is responsible for the iteration. Therefore, we do not have the scenario where business analysts define the customer requirements, and then hand these off to the engineers to try to implement who then hand off their products to testing and quality control, and then, finally, we document the product or service. Oftentimes, in this scenario, there will be a number of disconnects and places where the original customer requirements get lost in the translation.
For PMI, the WBS is the heart of all planning processes, and will virtually drive all other types of planning such as scheduling, budgeting, planning for quality, risk identification, and planning for procurements. The lowest, most detailed level of the WBS is the “work-package” level. The WBS is fundamentally about deliverables and engineering requirements, and therefore later, the estimates for schedule durations and cost estimates of activities are largely driven by the technical products. In the traditional/PMI approach different teams are responsible for the different views of requirements.
With the APM approach, we would not focus on a WBS per se, but on an FBS (Feature Breakdown Structure) instead. Also, in Agile, the entire team collaborates throughout each iteration with the detailed breakdown of the features and stories: a customer focus is maintained.
Note: this article reflects the viewpoint of the author, Mark Tolbert, and does not necessarily represent the views of PMIWDC. If you disagree with or object to the views expressed here, please let us know