• As of December 2011, there were over 470,000 PMPs worldwide. Therefore, (as of today – April of 2012) – PMI must be very close to announcing there are now 500,000 PMPs!
• The PMP – is by far – the most internationally recognized certification for project management.
• Surveys show that project managers with the PMP certification are paid, on average, 14% more in salary than non-PMPs
• The U.S. Federal government is making the PMP a requirement for all their project managers and program managers.
• Many enterprise corporations also require their project managers to be PMPs.
• If you are looking for a PM position, you will significantly improve your chances by having a PMP 
• As of May of 2011, there were over 346,000 members in PMI
• PMI was started in 1969, and the first PMP exams were administered in 1984

For me, as a long-time PMP Prep instructor, there were a number of good corrections and changes from version four that will make the new edition more clear and logical. However, my main concern going in was, “Will PMI really address Agile? Will they make a concerted effort to truly include Agile within the framework?” On this score, I’m quite disappointed with the apparent lack of recognition that they must really do this, and make some systemic changes. Just think of the number of project managers today using Agile, and consider that the majority of these PMs seem to say the PMBOK Guide, as it exists today, is not really that relevant!  Very soon, I think, PMI will announce that there are 500,000 PMPs in the world today. Assume 65% to 70% of these PMPs are managing software projects. Of these, PMI’s own studies say 90% are using some form of Agile. So, with some simple math, that reduces to over 300,000 PMPs now using Agile methodologies – mostly in place of processes and methodologies defined in the PMBOK Guide! PMI should be very concerned that the PMBOK Guide may become regarded as irrelevant by the majority of project managers, if they don’t make significant changes.

Most of the Agile proponents have their hopes tied to the Software Extension to the PMBOK Guide that is scheduled for release at the end of 2012. I am optimistic this will include specific Agile methodologies, but I also believe the “higher level framework” – the PMBOK Guide – shoujld also fully embrace Agile.

It’s not all negative, and they did take some small first steps on this issue. They finally mention Agile in the PMBOK Guide, and define a new lifecycle model: the Adaptive or Agile model. They explicitly say that Agile methodologies can be seen as an implementation of rolling wave panning. Also, as they spell out how progressive elaboration is often done, they leave a lot of room for including the Agile Project Management approach. They explicitly say that doing prototyping is a good approach for mitigating risk when requirements are quite undefined, and high volatility is anticipated.

 However, this was just a first step, and much of the PMBOK Guide still has a heavy bias to the “prescriptive” – (sequential/waterfall) – model. For instance:

• They say the project management plan should be formally approved, and they make it sound like this is a single event. Once the project management plan has been approved, we must start formal configuration management. (All change requests are submitted in writing, and passed through the change control and configuration management systems.) In Agile, or in an adaptive model, it wouldn’t work like this. The project management plan, in effect, might be approved and re-baselined at the end of every iteration – (every Sprint). Then the team, along with the customer, will go through the approval processes/adaptive processes at the end of the Sprint. Also, a new backlog would be defined for the next Sprint. Secondly, in Agile, the team would decide within the iteration, or Sprint, the level of documentation needed, and when and how configuration management would be done for the new backlog (requirements) created in the Sprint. (It would be a much more flexible, JIT or “pull” system.) For much of the new backlog, the team might decide to wait until the end of the Sprint (or Iteration) to do the version management and Configuration management.
• PMI heavily favors using earned value methodology on all projects. This requires defining very detailed plans and baselines for the entire project early in the project. (The main purpose of EVM is to see if a project is in trouble in the early stages.) Therefore, we need a very accurate BAC (Budget at Completion) to be defined early in the project. This will not happen in Agile. Early on with very volatile requirements, we often won’t know how many iterations or Sprints will be required for the entire project.
• There are vestiges of the waterfall method in other places. In the Quality Management chapter they say that quality assurance is done during the planning phases and implementation phases, and quality control is done in the implementation phase and closing phases. This is not consistent with the Agile/adaptive model where all these processes could be used fairly equally in all Sprints or iterations.

 In the draft of version five of the PMBOK, all the traditional language, tools and methodologies are included:

•  A very detailed PM Plan with many (15) subsidiary plans
•  Formal Change Control and Configuration Management
•  Three baselines, including the Scope Baseline with the WBS as one of the key components
•  Four classic estimating techniques – (Bottom-Up, PERT, Parametric and Analogous)
•  The seven classic Quality Control Tools
•  Qualitative and Quantitative Risk Techniques

However, they’ve not chosen to mention any new terminology or approaches defined in the Agile methodologies. For example, there is no mention of:  

•  An FBS (Feature Breakdown Structure)
•  Burn-down charts
•  Burn-up charts
•  Kanban
•  Fibonacci estimating – Planning Poker
•  Osmotic communications

 For those interested in a comparison of the draft of version five with version four, the main changes are:

The most significant change involves changing the process matrix. In version four, there was a deliberate attempt to reduce the number of processes, inputs, outputs and tools and techniques from version three. Now, in version five, they are going back the other direction – of course! In version five, they’ve added five more processes and a new knowledge area. Now there are now 10 knowledge areas and 47 processes. But it’s not as major a change as it would appear on the surface. They’ve taken “Identify Stakeholders” and “Manage Stakeholder Expectations” out of Communications Management, and moved these two processes into the new knowledge area – “Stakeholder Management.”  Also, two of the five new processes they’ve created are also in this knowledge area: “Plan Stakeholder Engagement” and “Control Stakeholder Engagement.”

The other three new processes they’ve created just articulate in detail a concept that existed in the earlier versions of the PMBOK Guide: it was always understood that we had a Scope Management Plan, a Schedule Management Plan and a Cost Management Plan. But in version 4 there were no specific processes in the respective knowledge areas to create these management plans. Instead, in the introductory paragraphs of each of these knowledge areas, they said something to the effect: “Although not shown here as a discrete process, the work involved in performing the processes of (the knowledge area ) is preceded by an earlier planning effort  in Develop Project Management Plan … which produces the management plan. In version five, we now have distinct processes in the respective knowledge areas to create each of these management plans.. So, hopefully, for students who will be preparing to take the PMP Exam when it is based on version 5, this just adds clarity to an idea that existed in the earlier versions of the PMBOK Guide.

So, in summary, there are now 47 processes (5 new processes): four new planning processes (all create management plans): Plan Scope Management, Plan Schedule Management, Plan Cost Management and Plan Stakeholder Management; and a new Monitoring and Controlling Process – Control Stakeholder Engagement; They’ve renamed two processes: Distribute Information is now Manage Communications; and Manage Stakeholder Expectations is now Manage Stakeholder Engagement. So, the number of processes in each process group are now:

                                                               i.      Initiating – 2

                                                             ii.      Planning – 24

                                                            iii.      Executing – 8

                                                           iv.      Monitoring and Controlling – 11

                                                             v.      Closing – 2

There are many other more minor differences to point out, but that would take several pages and probably only be of interest to PMP Prep instructors!

I would love to hear your thoughts. Please send me your feedback!

Mark Tolbert

1) How and why the PMP exam is much different than most tests you’ve taken in the past.

2) What makes it a very difficult test: one of the most difficult tests you probably will ever attempt!

3) The application process,  and the sequence of events from submitting your application to getting the test scheduled. (We also discuss the audit process.)

4) An overview of the Prometric testing centers.

5) The percentage breakdown of questions on the exam.

The first video is located at: http://www.youtube.com/watch?v=f12l2t61wmM.

Part 2 - http://www.youtube.com/watch?v=ruHAGMbuePs 

Part 3 – http://www.youtube.com/watch?v=xyfrt6E1x38

The first YouTube Exam Strategy video can be found at – http://www.youtube.com/my_videos_edit?ns=1&feature=vm&video_id=-kSoUQQwJ9g.  You’ll also easily find the other three videos, but they are:

Part 2 – http://www.youtube.com/watch?v=zDngzowPk6w

Part 3 – http://www.youtube.com/watch?v=sWLR9vynERY 

Part 4 – http://www.youtube.com/watch?v=y0k0_A3EuDc

What things would you like to see changed, added or deleted?

Here are a few thougths I have about areas to address:

•  
  • The RDS says “Project Selection is no longer in scope for the PMP.” To the contrary, there still are project selection questions on the exam.
  • The RDS doesn’t mention configuration management, only change management
  • The RDS doesn’t mention a Scope Statement – or “Define Scope” – just Requirements gathering
  • For more comments, see Mapping the RDS to the PMBOK Guide

   

• Incorporate & address Agile Methodologies in more substantive way. (See other articles on Agile vs. PMBOK® Guide posted on this blog.)
• Project Management Plan – There should be a subsidiary plan for Closing. (Like we have a Change Management Plan & Configuration Management Plan, we need a Closing Subsidiary Plan.)
• Distinguish more clearly between Change Management and Configuration Management, and define better how they overlap and work together. Is PMI still standing behind view of version three that Configuration management is more inclusive: (includes within it Change Management?)
• Clarify better the distinction and purpose of Contingency Reserves and Management Reserves. PMI made substantial improvements in version four on this topic, but there is still some vagueness and ambiguity:  
  • If Contingency Reserves are often part of the Cost Performance Baseline, and this is often equated in Earned Value with the Performance Measurement Baseline, then Contingency Reserves are a part of Earned Value Measurement. (We do plan to spend some, if not most, of the Contingency Reserves. We do expect a number of the risks in risk register to occur.) 
  • On the other hand, some people hold (e.g. – the PMI Earned Value Standard?) that reserves are never part of EVM. This is controversial, and the current version of the PMBOK® Guide implies contingency reserves are part of Earned Value.
• Make the PMBOK® Guide and the RDS (Role Delineation Study – aka “PMP Examination Content Outline” – consistent! The PMP Exam is supposed to be based off the RDS, but this doesn’t seem to really true, and there are a few places where the two documents go different directions. For example,

 You really want to get started on your application right away. Don’t put this off until after taking a PMP Prep class, because that will result in delaying the earliest time you can take the test until almost two weeks after your class has ended. You don’t want that to happen: the best strategy is to get the test scheduled very soon after completing your training. Most ‘PMP Prep Boot Camps’ are exactly that! I set expectations for students in my classes that they need to be very focused. We cover a tremendous amount of material, definitions and details in the four days at a very rapid pace. I also tell the students that from the time class ends until the time they take the test, they need to put in 2-3 hours a night reviewing notes, doing practice tests and, generally, staying very current with the materials. I then ask, “Are you going to do this consistently three weeks after class has ended?” I doubt that very much. So, plan to take the test right after completing your PMP Prep training. In order to do that, it’s best to have the application filled out ahead of time, if possible. Here are some additional points about the application process:

• Most students indicate it takes a full day, at least, to complete the application.
• It’s best to fill out the application online. Go to http://www.pmi.org  - the certification section for the online application.
• You can enter project experience going back eight years. First, you need to get all your project records in order. An excellent spreadsheet to help you organize your information can be found at http://tinyurl.com/yehhygl.  After entering information into the spreadsheet, you can simply cut and paste into the online application.
• You can use experience outside of the normal workplace. For example, if you led or directed activities for a charity, or a local civic group – that’s project management!
• You can list experience even if you weren’t specifically called the “Project Manager.” As long as you were doing project management work: planning, directing work against the plans, checking progress and “monitoring and controlling” – you were doing project management work.
• Roughly, two-thirds of the experience you list should be divided evenly between the categories of “planning,” “executing” or “monitoring and controlling.”  The remaining one-third should be divided between the categories of “initiating” and “closing.”  (See notes below describing the five process groups.)
• There’s also a requirement on the application for 35 contact hours (or Project Management education hours). These are credit hours from any formal project management instruction you’ve taken. This could be virtual training or classroom training. There is no time restriction on how long ago the training occurred, but you will want to have a certificate for the class in case your application is audited. (More on that below!)  Many students use the hours from their PMP Prep class for the 35 contact hours: (most four day PMP Prep classes provide the 35 hours in and of themselves). In this case, the application cannot be submitted to PMI until the PMP Prep class is completed. 

 2)   Submitting the Application and the Audit Process 

•  If you have earned the 35 contact hours before attending a PMP class, you should submit your application before your PMP Prep class. (Again, if possible, you want to schedule the exam as soon as you can after completing the class.)
• After submitting your application, PMI will take approximately one week (five business days) to process your application.
• After approving your application, PMI will inform you that you are now ready to pay for the exam.
• Within moments of paying for the exam, you will find out if you have been selected for an audit!

-   PMI randomly audits up to 20% of all applications. The audit is not triggered by anything in the application; the audit process is just one key way PMI is validating the PMP certification.

-   If you are audited, PMI sends you an email with a .pdf attachment that contains letters to go to all the managers you used in your application. You will need to obtain their signatures on the letters vouching for the experience you reported.

-   Additionally, you will need to provide a copy of your college degree and certificates of the classes you used for the 35 contact hours.

-   You will also have to provide more details for the experience you listed in the application showing that you have appropriate experience in all five process groups: (Initiating, Planning, Executing, Monitoring & Controlling, and Closing) – see below for more information on the process groups.

-   You will package together all the signed letters from your managers, along with the other documentation, and ship this to PMI.

-   It takes approximately another week for PMI to process this information, and complete the audit.

• Once the audit is completed – (or, in the more normal case where you are not audited) – you will receive an email from PMI with an authorization code to use for scheduling your exam at a Prometric testing center. (You do have the option to take a written test, but I’ve only had one or two students use this option in the last five years. With the written test, it may take over a month to get the results on the test!)
• You will use the authorization code to log into the Prometric website – http://www.prometric.com and schedule your exam. (You will be able to see all the testing centers within a certain radius of an address or zip-code you enter. You can then pick any of the testing centers, and check available times to schedule your test.)

3) Review of the Five Process Groups and Activities That Belong to Each Category

For your application, you need to list activities that fall into all five process groups defined in the PMBOK Guide: (Initiating, Planning, Executing, Monitoring & Controlling and Closing). The bulk (probably about two-thirds) of your time should be comprised by activities in Planning, Executing and Monitoring & Controlling; but you do need to find some activities that also belong to Initiating and Closing. Here are high-level descriptions of the categories, and examples of activities that would occur in each category.

Initiating

• ­This is where the project is first authorized (Develop Charter), and the phases of the project are authorized.
• It also includes the activities to identify all the stakeholders: people who are positively or negatively impacted by project.
• So, list any experience where you assisted senior management in doing project selection: analyzing the ROI or benefits that are expected by the projects being considered. List activities to assist the sponsor in creating and issuing the project charter. Also, describe activities you were involved in to identify the different stakeholders for the project, define their powers and influence on the project, and define strategies for how you will manage the stakeholders.
• Though it doesn’t need to be a lot, you do need to list some activities in your application that fit into this category.

Planning

• Of the 42 processes in the PMBOK Guide, 20 are planning processes. We do planning in all nine knowledge areas, so a large amount of the experience you list will fit into the planning category.  
• This includes activities to define the scope statement, create the WBS, develop the schedule, and do cost estimating and determine the budget for the project. It also includes planning for Risks, Quality, Human Resources, Communications and Outsourcing (Procurement) for the project. All these “subsidiary plans” and baselines become part of the Project Management Plan – the most important plan of all.
• As you describe your planning activities in your application, use the PMI terminology and processes as best as you can.

Executing  

• As a project manager, you spend the bulk of your time directing execution against the project management plan: seeing that all the elements of the plan are being correctly followed and implemented. This includes:
  •  Ensuring deliverables & work called for in the plan are created at the right time, by the right people, in the right sequence
  • Running meetings and distributing reports: (status reports, progress reports, variance reports, … )
  • Managing and handling other project communications
  • Doing team development
  • Managing stakeholders
  • Assisting with procurement negotiations for outsourcing activities       

 Monitoring & Controlling  

• Once we start executing, we must monitor & control our progress. We must check and compare our actual performance for the project against the project management plan. Monitoring and Controlling occurs in almost every knowledge area – (all except HR), – and it occurs from the very beginning of the project to the final close. Describe activities in your application that address:
  • Checking variance against any of the three baselines: Scope, Schedule or Cost baselines
  • Doing Earned Value measurements and forecasting
  • If there is variance from any of the baselines in the project management plan, recommending corrective actions to get back on plan
  • Even better, be proactive and do risk management properly, so negative risks are planned for and anticipated. Take steps in advance to avoid, mitigate or transfer the negative risks.  
  • Realize that change is a fact of life for projects. Therefore, plan for change, – and  always have -  formal configuration management and change control systems.
  • As change occurs, ensure change requests go through a formal evaluation and approval process. Ensure baselines and other affected parts of the project management plan are properly updated; ensure baselines are consistent with one another, and balance is maintained between the “ triple constraints” impacting the project.

Closing  

• Just like you did for the Initiating Process Group, you must find some project activities in your application that fall into the Closing category.  This includes both steps to formally close the project, steps to close project phases, and steps to formally close out any subcontracts negotiated for the project. This includes activities such as:  
  • Getting the customer’s final, formal acceptance of all project deliverables
  • Doing a project “post mortem” to capture lessons learned a final time
  • Archiving all project records (both at the end of the project, and the end of project phases)
  • Releasing project resources
  • Assisting senior management with the “phase gate” reviews and possible “kill point” decisions (at the end of project phases)

 “Revolution or Evolution?”

1)      Introduction – Overview  

 It has been a little over ten years since the Agile Manifesto was published.  Over these 10 years, the interest level in APM (Agile Project Management) and the specific methodologies included within the “Agile umbrella” – such as Scrum, Extreme programming, Lean, Crystal, DSDM and Feature Driven Development – has steadily increased. APM is certainly not a passing fad. More and more people are departing from running their projects using the traditional methods, and are using Agile methodologies instead.  

 In the last few years it appears that Agile Project Management has crossed a key boundary from being in an “early adoption phase” into “mainstream adoption.”  With PMI’s recent announcement of the PMI-ACP Agile Certification, this will further increase the interest level in Agile Project Management, and validate its acceptance as a key way to manage many types of projects. For companies and project managers who have been slow to get educated on this new approach, the time is now: get up-to-speed with APM and its benefits, or perhaps risk becoming obsolete!

APM was originally conceived of as just a new way of project management for software projects only, but today it’s being applied successfully in many different industries and applications. It is most applicable for projects where it is expected the requirements will change significantly during the course of the project: the customer does not up front exactly what they want; .therefore, we will iteratively create prototypes of the product or service, and allow the requirements to “emerge” or be discovered in progress. Since software projects often include the most malleable requirements, they are excellent candidates for using APM. But today, many other projects are excellent candidates too. In Jim Highsmith’s excellent book, Agile Project Management: Creating Innovative Products – he points out that many products that were once thought to be hardware only are now really hybrid products with a significant software component, and the software component keeps increasing. Cell phones are great example: in just a few years they have evolved from being products with relatively little software to being products with hundreds of thousands of lines of software code that drive all aspects of the operation of the phone. Even in architecture and building design, the use of CAD and other modeling and prototyping techniques has had huge implications for how to approach the project.  

In the January 2012 PMNetwork magazine, there is a feature article on the adoption of Agile, and of 4,770 software project managers that PMI interviewed, 90% said they were using some form of Agile. Additionally, most of these PMs cite having much a higher level of success using Agile than they had with the just traditional methods. Also, as reported by PMI, the use of Agile methodologies has tripled from December of 2008 to May of 2011.

So, today, we seem to have two dominant schools of thought regarding project management: the traditional approach whose practices and processes are best articulated in the PMBOK® Guide, and this new school of thought – Agile Project Management (APM).  The key writers and authors of books on APM describe this new approach as a revolutionary approach: a complete departure from the traditional way of managing projects. Is this really correct? Are they recommending discarding many of the key practices and processes that are defined in the PMBOK®  Guide? Yes, oftentimes, this seems to be the case! In Doug DeCarlo’s book, Extreme Project Management, he quotes a PMP managing pension implementations, “I always believed that the project management profession is doing itself a disservice if it doesn’t recognize that many, if not most, projects don’t follow the guidelines set forth by PMI’s PMBOK®  Guide.”

In APM, they certainly have adopted a whole set of new concepts and terms and terminology, and they rarely reference the tried-and-true core concepts defined in the PMBOK®  Guide: creating a very detailed WBS, managing project performance against baselines, using Earned Value Methodology, having formal change control and configuration management systems, and thoroughly documenting all aspects of our projects. Though many of these terms do map onto the old tried-and-true terms, or there is a lot of overlap at least, the authors of APM say it’s very important to come up with new terminology to connote the key themes they are emphasizing in APM.

On the other hand, can we make the case that Agile Project Management is really a refinement and extension of tools-techniques and processes that are already defined in the PMBOK® Guide? This, of course, is the PMI view. They would remind us that the PMBOK® Guide is not meant to be a menu of how to do projects. Instead, it is to be understood as a higher level framework of best practices and methodologies that support projects in any industry, no matter how simple or how complex. It has always been understood that added to the 42 processes described in the PMBOK® Guide, there can be many other more specific approaches and methodologies that fit different projects in different situations, and in different industries. These more specific methodologies could be seen as extensions of tools and techniques that are defined for the processes. On the pmi.org website, on the FAQ page for the new PMI-ACP certification, the distinction between PMBOK® Guide and Agile is described in this way: “The PMBOK® Guide – Fourth Edition contains principles of project management and project management processes. These processes describe “what should be done during the management of a project.’ Agile methodologies are different in that they describe ‘how to do the things that should be done’ – in short, ‘what versus how’.”

So, can we reconcile this apparent disconnect? I think, in large part, we can! I think there are three major areas where Agile supporters reject Traditional Project Management – (and, in the same breath, the PMI view and PMBOK® Guide) – where this criticism either does not apply to the PMBOK® Guide, or they have misunderstood or misrepresented the PMBOK® Guide.

• Rejection of the “Waterfall Method”
• Rejection of formal change management and configuration management
• Rejection of the traditional project manager’s role and the team members’ roles

However, I would argue Agile methodologies do define a different framework and philosophical approach for managing projects that is currently not embraced in the PMBOK® Guide. The PMBOK® Guide currently defines a very formal, prescriptive – (or “Push approach”) – for managing projects. It requires, as PMPs, we should create a very detailed project management plan at the beginning of the project with its many subsidiary plans, and define accurately the three key baselines: Scope baseline, Schedule baseline and Cost baseline. We should use Earned Value Methodology on all projects.  

Agile, on the other hand, dictates using a far less formal approach – (or “Pull Approach.”) We will discover requirements in an iterative way, and let them emerge; 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 Agile, new concepts and terminology have been introduced to replace the older traditional terms: the WBS is replaced with an FBS – (Feature Breakdown Structure), the classic baselines are not mentioned, the project manager’s role is redefined, and new concepts such as “burn-down charts” are introduced to measure progress on a project – (within a Sprint). As a long-time PMP – (since 1995) – and supporter of PMI, I believe that for the PMP to remain as relevant in the next ten years as its past 25+ years, I think the PMBOK® Guide must be broadened to include this different approach of Agile Project Management.  

I have broken the rest of the paper into six sections:

1. APM’s (Agile Project Management’s) criticism of the Waterfall method
2. Defending the PMBOK® Guide against this criticism
3. Other Agile Misconceptions About the PMBOK® Guide
4. There Are Two Different Philosophical Approaches Being Defined
5. Version Five of the PMBOK® Guide – How Will It Address Agile?
6. Conclusion – What Approach Is Best In What Situation?

Lastly, I’ve created YouTube video clips created for the January 17^th PMTools presentation slides!  The first video clip is – http://www.youtube.com/watch?v=ptG1xopSEIM

Waterfall Method

Let’s take a step back, and describe how software projects were often done in the past with the waterfall method, and contrast this with the much more iterative approach that’s recommended in Agile Project Management.

In the past, the classic way most of us designed new software applications was to use the “waterfall method.” A precise sequence of phases was undertaken to plan the project, execute, test and close out the project. We first captured our high level requirements – (user requirements, functional requirements or business requirements). In the old way of doing things, this might take a couple of months alone. We then defined the “subsystem specifications,” or the system architecture including file layouts and the modular layout of key program pieces.  Again, for a large application, this might take a couple of months. Then the programmers could begin their work, and start the development phase coding all the modules. Depending on the size of the software application this could take a year or even longer. Then the application went through unit testing and integrated testing, and this continued until the application passed all of the acceptance tests. Again, this could take months. Therefore, it might easily be more than a year before the customer actually saw the working application! What has happened in this timeframe, – in this one to two years? Of course, the customer’s requirements have changed.  Also, it’s not until the customer has seen the application and used it, that they understand what they truly need.  And, even worse, it may not be until the customer actually sees the application that we learn if we really understood their requirements to begin with. So, in a very large percentage of cases, there’s going to be some disappointment when the customer does see the application, and major corrections are going to be needed. Depending on the number of changes, and the level of these changes, it may be a significant amount of time before the customer gets the application they truly need, and significant additional expenditures could be required. We have many of the ingredients of project failure: scope creep, schedule delays, cost overruns and an unhappy customer!

Agile’s Iterative Approach

Again, Agile is meant to address situations where it is a given that at the beginning of the project where the requirements are very undefined: the customer does not really know in any depth what they need, or what they want. Therefore, we will undertake the project in such a way to let these requirements emerge, or be discovered. Therefore, with Agile Project Management (APM), we will use a very iterative approach to tease out these requirements. We must have a strong “product owner” (or product owner team) that can analyze and identify key requirements – or the product backlog – at the outset.  We then go through a series of iterations  – (or in Scrum – “sprints.”) An initial set of the product backlog is chosen for the first iteration, and this is developed by the project team very quickly – usually within a two week to four week time frame. (Again in Scrum, this would usually be a one-month “sprint.”) In all cases, in APM, it’s a defined “time boxed” short period of time.  

The team is given complete freedom and authority on how to best develop (or elaborate) the “stories” (or requirements) for the first iteration  The team usually consists of 7 to 8 cross-functional, co-located dedicated individuals, and they (not the project manager) are responsible and accountable for creating the backlog within the defined timeframe. They are empowered, and given complete autonomy and independence on how best to achieve this backlog in the required timeframe. They should not be interfered with during this iteration by upper management, or other stakeholders. The project manager – (in Scrum – the scrum master) is acting principally as a facilitator, and his or her key job is to remove barriers and obstacles that could impede the team from achieving their goals, and ensure that they are not interfered with.

The team meets on a daily basis, – (in a “standup meeting” – or in a “Scrum.”)   This is a short 10 to 15 minute meeting where everyone remains standing (resembling a rugby scrum). Assuming the meetings occur at the beginning of each day, each individual describes what they have accomplished the previous day, what they will do today, and what issues they may be facing. (At the standup meeting, the purpose is not to solve any of these issues, instead, they are taken off-line, and the team members independently decide best how to resolve the issues.) At the end of each iteration, the customer – along with the team and product owner – reviews the product backlog (prototype) that has been created, and it is either accepted or not. Ideally, the product backlog created during the iteration is something that could be put into production, and truly used. Also, at the end of each iteration the team goes through a “review or adaptive process” – to catch their breath and get reenergized, and to reflect, learn and adapt. This is usually just a half-day meeting. After each iteration, a new backlog is chosen for the next iteration, and new features and requirements are added on to the previous prototype.

The prototype is progressively elaborated in repeated iterations (or sprints), in a very efficient manner. The customer (product owner) gets to see real tangible products very quickly, and determine the features that are most important and those that are not. In APM, they say we are able to “identify fast failures.”

This Iterative Approach Used in Agile Solves Most of the Problems of Waterall  

By using the Agile approach, this will solve most of the problems previously mentioned with the waterfall method:

• We will quickly get feedback from the customer – (not wait the traditional amount of time of more than a year as we did with the waterfall model).
  • ­As Doug DeCarlo says, we will be able to “Identify Fast Failures:” – early in the project we will learn what is not working.
  • Determine if we did understand the requirements properly
• Also, oftentimes, it’s not until the customer sees and uses the product that they truly understand what they need.
  • Oftentimes, requirements they thought were essential, they realize are not!)
• So, we don’t waste time on non-essential requirements.
• We won’t waste time planning and trying to estimate the unknown.
• We 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.
• From Doug DeCarlo’s book,  “If a picture is worth a thousand words, a prototype is worth a thousand pictures!”

So, again, most authors of books and articles on Agile Project Management view APM as a complete departure from practices described in the PMBOK® Guide. They describe it as a new revolutionary approach, 180° in the another direction from the PMBOK®  Guide, As noted above, in APM, most of the traditional terminology has been replaced by new terms and jargon. This is on purpose! The authors of these new approaches are very aware there are similarities in meaning between the new terms and traditional definitions, but they want to use new terms to emphasize that in APM, teams will be managed in a different way, requirements will be handled differently, and in general, it will not be the old standard way of doing projects.  Also, they go to lengths to describe different approaches for managing projects: from planning, through monitoring and controlling, change control and documentation. For these authors, this is a new revolutionary approach.  

In APM, it’s a mistake to try to plan the project in detail upfront, and then stick to these plans or baselines. There is less focus on meeting the classic “triple constraints” and holding to these.  Instead, according to the Agile manifesto of 2001, the key areas of focus are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

In APM, a key theme is that the requirements will be allowed to emerge as we move through the project. Doug DeCarlo describes the traditional method as, “Ready-Aim-Fire,” and the Agile approach as “Ready-Fire-Aim!” We are allowing for continual adjustments and changes to requirements as a move through the project. Ken Schwaber, in his book, Agile Project Management, uses the analogy of planning a car trip to illustrate the APM approach. Perhaps we are planning a trip from Washington, DC to Burlington, Vermont. Do we want to plan the route out in detail before leaving Washington, DC? Probably not with today’s GPS devices, and the ability to monitor traffic in a real-time way. Starting out, we may make some general plans for our route, but allow for adjustments and alterations in real-time during the trip.

 Defending the PMBOK® Guide Against This Attack on “Traditional Project Management” 

 But the PMBOK® Guide also allows that projects could be planned in a very iterative fashion: we often use “rolling wave planning.” This means we will plan in detail things that are occurring right away in the project, and only sketch-in at a high level things that will occur farther out in the future. (We will include “planning packages” in our WBS for these “sketched-in” items.) Later, as we approach the time the planning packages are needed, we will come back – in our second wave of planning  or third wave of planning – and fill in the details. So, PMI does not have any problem within an iterative approach to project management. Prototyping is also specifically mentioned as an important “tool and technique” in the process: Collect Requirements.

 We can see that much of the Agile practitioner’s criticism of traditional project management is really a criticism of the waterfall method of project management, and is not a criticism of the approach defined in the PMBOK® Guide.

Therefore, one could definitely make the argument that in APM and Scrum, iterations (or Sprints) can be viewed as a special case of Rolling-Wave Planning.

For Both Agile and PMI, Processes From Different Process Groups Are Used in Both Iterations (or Sprints) and Phases. 

In Agile, it is understood that within every iteration (or Sprint) a variety of different processes will be used: the team will be allowed a lot of freedom in planning how to do the Sprint, then the team will execute to create the product backlog defined for the Sprint: (the products, deliverables or services), adjustments will be made during the end, and also at the end. This type of activity is very much like doing Monitoring and Controlling processes described in the PMBOK® Guide.

In the PMBOK® Guide the five process groups are also used iteratively in all phases of a project in a very a similar way. (One of the most common mistakes about the PMBOK® Guide is to confuse the five process groups with sequential phases of a project! This is completely incorrect! See page 41 in Version Four of the PMBOK® Guide.) Part of the formal standard is that we should use processes from all five process groups in each phase. Yes, all projects are initiated formally in Develop Charter, but also, all phases must be initiated too. Likewise, just as the project should be formally closed, all phases are also formally closed (as part of Close Project or Phase of Project). We must execute in every phase, since we are creating deliverables in every phase. (In the early planning phases, the deliverables are documents or plans.) And, of course, monitoring and controlling checks on the activities of the other four process groups, so it is always being used: from the very beginning to the very end. Planning is perhaps the most difficult to see being used in all phases. It’s easy to see that it would be used up front in the early planning phases, but why would we still be using planning processes at the end of the project? There are actually two good reasons for this: (1) we are always looking for ways to make improvements, to do continual improvement (Kaizen), and improve our products, plans, baselines or processes; and (2) Rolling-Wave Planning. We may purposefully save some planning for the very end: the “punch list” or “walk through plan.”  So, normally, there are even updates to be done to plans and documents at the very end of the project in closing.

 Managing Teams – Team Interaction – Team Development

One of the most important parts of all Agile Project Management methodologies is the approach taken for managing the project team, and the collaboration between all key stakeholders – (the product owner, the project manager, the project team, and also the customer) – at all times in the project. Agile methodology is most appropriate for projects where we need to maximize creativity in designing new products and solutions. The customer does not know what they want, and we expect there will be a lot of volatility with the requirements. In this environment, we need high energy teams that are very empowered, very motivated, self-reliant who will be resourceful and will use a lot of initiative. A key role for the project manager (or Scrum master) is to remove barriers that could impede the team, and ensure that the team has the tools they need, and they are not interfered with from the outside. The project manager does not assign tasks and work to the team members – (the team members decide for themselves how best to achieve their goals). The project manager is usually serving in a role more as a facilitator or in a supporting capacity.

All the literature that I have read for Agile methodologies emphasizes that the best management style to follow is consistent with “Theory Y” or “Management by Objectives” philosophies. Management assigns the high level objectives to be met (the product master picks the key product backlog) – and then allows a lot of freedom and trust for the team members to go about achieving the requirements. It is best for an iteration, if the team is made up of seven or eight co-located individuals who are dedicated to the project. 

The PMI View Allows for Project Managers to Adopt Many Management Styles

For APM, in their view of traditional project management, the project manager takes on more of a directing role, and prescribes roles and responsibilities and tasks for team members to carry out. However, actually, PMI’s vision is that as project managers we wear a lot of different hats. There are times we must be quite a directing project manager, and times that we are more of a supporting, facilitating project manager in line with the APM model. There’s no one style that fits all situations. They would say the management style described for the project manager (or Scrum master) in APM is just one of a number of different management styles that PMs need to become versatile with.

Also, like the Agile proponents, PMI agrees that co-location will lead to improved team performance. (In the process­ Develop Project Team, co-location is listed as one of the key tools-techniques.) APM and PMI both support this is as a key way to improve team performance since:

• Communications between team members will be much more efficient. With face-to-face communications team members get to see the body language and tone of voice of the other party, and this is an important part of communications. Also, we eliminate the delays of waiting for responses to voice-mail messages and email messages.
• Team “chemistry” will be much better as team members get to work closely together. 

Change Management & Configuration Management. Monitoring & Controlling – Measuring Progress Against Baselines

For PMI, from the very beginning of the project to the very end, we must always constantly monitor and control work for the project. We are always checking the heartbeat of the project. We are always comparing our actual project performance against what we planned to do: the three baselines.  We are checking for variance from the baselines, and if we find variance, we normally recommend corrective actions to get back on the plan or the baselines. Also, we are always forecasting where we think will finish up for the project based on our actual performance to date. For PMI, Earned Value Methodology provides the best way to do monitoring and controlling. We must have accurate baselines defined early in the project, and then we can use to earned value techniques to measure CPI and SPI and obtain valuable information about how the project is likely to finish up. We can determine very early in the life of the project if it is in trouble.

Most supporters of Agile have quite a negative view of this type of monitoring and controlling activity. They find this activity of recommending corrective actions to get back on plan distasteful. They believe it’s repressing change, and trying to enforce the original baselines. Since with APM, they are all about change, they don’t want to take any types of steps that would be repressive. In a similar vein, they would find formal change control systems and formal configuration management systems to be overly bureaucratic and repressive. Similarly, all the effort that would go into documenting change requests and evaluating change requests could restrict the team members from doing their “real work” of the project.

I don’t believe this is a fair criticism of the PMI view. The intent of monitoring and controlling systems, and the intent of formal change control systems, is not to repress change. PMI understands that change is a fact of life, it is going to happen, but we need to plan for it, assign roles and responsibilities, and ensure that we are tracking changes as they are approved, and updating the latest versions and revisions of our products. Failing to do this well, especially configuration management, has led to some of the largest disasters in project management in the last decade: (for example, the cost overruns –  billions in euros, and years of schedule delays for the A380A Airbus program).

Also, the intent of corrective actions in the PMBOK® Guide is not to enforce the original baselines – for it is understood that baselines can and will change. “Corrective actions” help get us back to the latest approved baseline(s). Furthermore, it is understood that many times there will change requests that require significant change to the baselines, and “rebaselining” is needed.  In APM, since we do not typically have the three baselines that we can measure our performance against, we do not do monitoring and controlling in the same manner as described in the PMBOK®  Guide. (But, in some sense, we do have baselines! Since each iteration is a well–defined, time – boxed engagement, it is clear what the schedule will be, and also it would be very easy to calculate the costs would be for each iteration.) 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. That gets much more difficult in Agile, and we will discuss that more in our summary.

 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.