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/certapp 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.

PMI has indicated that the first draft of version 5 of the PMBOK® Guide will be released on the pmi.org website on February 17, 2012. Project managers and PMPs will then have much of the remainder of 2012 to send PMI comments and requested changes. Version 5 of the PMBOK® Guide is to be formally released on December 31, 2012.

So, it will be very interesting to see what changes will be made in the PMBOK® Guide to address Agile methodologies. (Today, Version Four of the PMBOK®  Guide does not mention Agile at all.) The initial feedback from PMI is that they will mention Agile, but will not explore these methodologies in any depth.

Based on conclusions that I have been arguing for, I would like to see more substantive changes made. As a first stab, I think the following chapters could be changed:

• Chapter 2 – Expand on the discussion of iterative life-cycle approach to discuss Agile methodologies specifically. Also, in the discussion of key stakeholder roles on projects, include discussion of stakeholder roles defined in the Agile models.
• Chapter 4 – Develop Project Management Plan – Do we always need the level of formality currently defined in the PMBOK®  Guide? Do we always need all the subsidiary plans and supporting documents? Does the project management plan always require formal approval? Is this always a single, one-time event? Can we allow for more informal models, and “pull/JIT” models?
• Chapter 5 – Scope Management – Should the Agile approach be included? (An approach that sticks entirely with a customer focused view for defining requirements and features?)
• Chapter 7 – Earned Value Methodology – Should the new, alternative approaches being created for Agile methodologies be included? (e.g. – Burn Down Charts, Burn Up Charts?)
• Chapter 9 – Human Resource Management – Again, possibly include the different stakeholder roles defined in Agile, and the different approach to team development, and managing the team members?

As a long-time PMP, and a supporter of PMI and the local Washington DC chapter, I fear that if they do not address making such changes, the PMBOK Guide will become less and less relevant and useful for project managers.

 So, if we accept that there are two basic and different philosophical approaches to managing projects being defined: (1) the prescriptive or “push approach” of the PMBOK® Guide, and (2) the less formal “pull approach” of Agile methodologies – which approach is best in what situation? Based on what we’ve described so far –  

 Agile will be best when:

•  Creativity is at a premium. (Perhaps we’re in a very competitive marketplace, or a very rapidly changing marketplace.)
• Requirements are undefined at the beginning. (The customer does not know what they really need, or only has a very high level definition.)
• There are very tight schedule constraints: we need to deliver a solution as quickly as possible, even if it does not have the full feature set.

 The Prescriptive (Push) Approach of the PMBOK® Guide will be best when:

•  The requirements are clearly defined up front, in the beginning – (Fixed Price Contracts)
• The requirements cannot change, and there are very tight constraints. (Also, often Fixed Price Contracts)
• Projects where we have to “get it right the first time.” (The devil is in the details.”) (For example, event planning – PMI’s project for the next Global Congress Meeting!) Perhaps projects dealing with crisis situations or emergencies.
• Large projects with geographically dispersed teams, many suppliers and many interdependencies.
• The cost of making changes will be prohibitive.

 Also, I think the answer will really depend on how we want to plan for the end of the project: forecast the schedule, forecast the budget, handle risks and meet constraints!

Projects are almost always undertaken with some very difficult challenges defined at the very beginning! As project managers, we are never given all the time we would like to have for planning, we are never given all the money we think we need to do the project properly, and we are never given all the resources we would like to have. It’s quite the opposite. Most times, we are given some seemingly impossible constraints limiting the project.

It is very typical that we start a project with the following scenario: we meet with the sponsor – (product owner in APM) – to understand the business need for the project and why we’re doing the project, and this all gets articulated and defined in the project charter. Then the sponsor usually has some tough questions for us, and tough constraints that must be met. We are often asked something like, “Now you can get this project completed in nine months, yes? And, furthermore, it must not cost more than $500,000, – understood?” What is the right answer? Many project managers just take these marching orders in stride, and answer that they and their team will do their best to meet all these constraints! (We will be good soldiers, and put up a good fight even if the project is starting in critical condition – the dashboard is entirely “red flashing lights” – at the outset.)

But this is not only a bad idea for the PM and his or her team, (trying to do the impossible), it’s also not the right thing to tell the sponsor.  Upper management really needs to really know if the project is in “critical condition” at the start. So, the right answer is, “I don’t know yet!” “I don’t know if we have the right resources, the right skill sets, and enough time to create the required products within this budget constraint.  I’ll need to do a lot more detailed planning, and I’ll come back in a few weeks and let you know what we can get done in this timeframe for this amount of money.” That would really be the recommended approach as defined in the PMBOK®  Guide. In order to do this, at minimum, we have to go through all the Scope planning processes, the Time Management planning processes and the Cost Management planning processes. (We really need to do all the planning processes in all knowledge areas to properly put together the three baselines!)

We will deal with this scenario in a very different way in APM.  If we can develop our first iteration – (prototype) ­– within one month with a key set of core features, then we will have gone a long way to validate that we have the right skill sets, and that we can successfully pull this project off. Even when we have completely impractical constraints, APM may work better than trying to plan everything out in detail upfront to know whether or not we have what it takes to do the project. This is just another case where Pareto’s law comes into play.  Often times, 80% of the customer’s true needs will come from 20% of the requirements. If we attack this vital set of requirements in the first few iterations, we will go a long way to validating the project. Also, oftentimes, after seeing the first few prototypes, the customer may realize that a number of the requirements they thought originally were absolutely necessary, are really not necessary at all and can be eliminated.

As Doug DeCarlo says, Agile methods and prototyping help us identify “Fast Failures.” We see very quickly what is not going to work, and what will not meet customer requirements. We don’t waste a lot of time and money planning and developing requirements that are not going to work. A classic cause of project failure, and even in a larger way – corporate failure – is that of “half-baked projects:” projects that are allowed to survive for too long and soak up valuable company resources that should have been eliminated early on in their lifecycle.  APM could be integral in helping companies see what projects are “half-baked,” and not going to work.

So, we have two different approaches for dealing with the risks of “impossible projects” with “impossible constraints.”

Management also always wants to know at the beginning how long the project is going to take, and what it is going to cost. If we are in the “Fixed Price World,” doing a type of project that we have done many times before – (and this is a “cookie-cutter project”) – the requirements will be well known, and we can do a bottom-up estimate to get a very accurate budget and schedule. (This is not to say that this type of project will be easy. Quite the contrary, oftentimes there will be tremendous challenges in bringing diverse sets of resources together at the right time, for the right cost and in the right sequence. It could be one of those projects where the old saying of, “The Devil is in the details” truly applies!)

But Agile Project Management is most applicable where the requirements will be fluid, the customer does not know exactly what they want, and we will have to discover these requirements or let them emerge. So how do we predict the final schedule and budget in this uncertain world? It is very difficult. One of the main criticisms of APM is that it does not deal with these needed forecasts very well. We are going from the prior situation of having impossible constraints, and impossible plans, to having no plans at all! And this may be worse! (The team tells upper management that because things are so uncertain, they cannot make any predictions.) So, in APM, advanced techniques must be used to do release planning, and do the forecasts for the end of the project. Estimating the amount of work and time required for stories is still a necessity, estimating the number of stories for features is needed, and estimating the number of features that can be included in a release is needed. It is not an exact science in this world where there will be significant volatility with the requirements.

On the good side of things, we will be getting real feedback and results early on in the project with the first iterations. We will see how the estimates for these iterations worked out, and we can start to project the overall “velocity” for the entire project. To be able to use Earned Value Methodology, we do need detailed baselines defined at the beginning of the project that we will measure our performance against. With EVM, we can measure such things as CPI and SPI early in the project – (20% into the project) – and get an indicator if the project is in trouble. Similarly, in APM, the first iterations and prototypes are giving us a reality check on the project.

The bottom-line is that it appears that the August 31 changes did not bring about any major changes to the exam:  there is no indication of major changes in subject areas, or in the level of difficulty of the test. So, whatever changes were made, they appear to be more “evolutionary” rather than “revolutionary.”   

Even though the RDS says “project selection is no longer in scope for the PMP,” it appears there still are questions on the exam on NPV, IRR, Payback Period, Opportunity Costs, …  Also, there still are questions on:

• AOA – (Activity on Arrow diagrams)
• Older theories of motivation: Maslow, Herzberg, McClelland

 So, the guidance that students should still make the PMBOK Guide their primary reference point is still holding true. For the places that the PMBOK Guide and the RDS go in different directions, focus on the PMBOK Guide. Read the RDS also, but realize it’s a more condensed, generalized view of the key domains (process groups) governing projects. It supports the PMBOK Guide  in almost all instances. (For all the gory details comparing and contrasting the two documents, please see our article “Mapping the RDS to the PMBOK Guide.”

Update – October 14. (See October updates in bold-italics below!)

This has been a hot topic on a number of PM related LinkedIn forums and groups for the last six months or longer. As you probably know, the PMP exam changed in a pretty significant way on August 31. A year ago, PMI announced that 30% of the exam questions would be changing on August 31 to be more in line with the current Role Delineation Study (RDS).  PMI has also said that all Professional Responsibility questions would be mixed with content from the nine knowledge areas, and there would be no separate category for Professional Responsibility on the exam.  In August, they also announced that candidates taking the test on or after August 31 through September would not get their results on the exam for four to six weeks! ( October 7 Update- We are now back to normal, and starting on October 7th, all students who took the test after August 31 received their results. Students taking the test today will receive their results at the Prometric testing center shortly after completing the test.) So, the prevailing opinion seems to be that most of the changes on the exam would be due to mixing professional responsibility questions with content from the nine knowledge areas. But could this really explain changing 30% of the questions in their database of 14,000 PMP exam questions? That doesn’t seem to add up. Up until August 31, Professional Responsibility questions only made up about 8% of the exam questions, or roughly, 17 out of the 200 questions on an individual test. If 30% of the questions changed because they now include some professional responsibility content, then that would imply that 60 questions on a 200 question test included some professional responsibility content. I doubt that PMI has decided to make that significant a change in the direction of the test.

Their announcement indicated the change in the test was needed to conform with ISO standards requiring a ‘Role Delineation Study’ to be performed on a regular basis. The current RDS is fairly short, high-level document that’s only 14 pages – (see – http://www.pmi.org/en/Certification/Project-Management-Professional-PMP/~/media/PDF/Certifications/PMP%20Examination%20Content%20Outline_2010.ashx .

If we interpret the five ‘domains’ of the RDS to be the same as the five process groups of the PMBOK Guide  – (a fairly logical inference, I think!), it is also true that the various tasks that are defined for each domain map fairly straightforwardly onto the processes in the PMBOK Guide. At a high level, “life is good:” the RDS and the PMBOK Guide are quite consistent and compatible. When we dig below the surface a little bit, we will find some discrepancies, but these will probably just annoy those of us trying to teach PMP prep courses, and those of us who like to dig into the technicalities of the PMBOK Guide. (If you would like to see more on the technical details comparing the RDS to the current PMBOK Guide, please see our post that provides a table mapping these processes – http://www.bestpractices-pmptraining.com/mapping-the-rds-to-the-pmbok-guide/ )

Should students worry about the relatively few places where the documents go different directions? I think not. In general, students need to be aware that:

• The test has never been purely based on the PMBOK Guide. (Test questions can come from any materials in the “PMBOK” – the universe of literature that PMI deems relevant for project management. Knowing the 42 processes in the PMBOK Guide, and the key ITTO (Inputs, Tools–Techniques and Outputs), probably prepares students for successfully handling 70% of the questions on the test. However, for most students who have taken a PMP Prep course, there will still be other strange questions and terms on the exam they have not heard before.)
• 80% of the questions are situational questions, and students need to ‘think on their feet’ and recognize in the situations being presented key aspects of processes, and the key ITTO. But the test is not literal, and they will not give you the exact spelling of processes or the ITTO.
• The RDS is also called the “PMP Exam Specification Outline.”
• PMI has performed several Role Delineated Studies in the past.  The earliest one I know of was released in 2000.
• So, perhaps the RDS is just emphasizing this higher level outline or framework for the PMP exam.
• Hopefully, it will remain true that the best strategy for the test is to focus primarily on materials in the PMBOK Guide.
• The RDS document does not provide any specifics or guidance on how the exam has been changed. For example, for the new exam, they might have removed all questions relating to project selection methods: (NPV, IRR, Payback Period, … ). The RDS states this is no longer considered in scope for the PMP! (October 14 Update - Students are reporting that there are still some questions on the new exam on project selection! Perhaps these types of questions are being diminished though. Also, one might think they’ve removed some of the dated “Theories of Motivation” that have been on the test for a long time: questions on Maslow, Herzberg, McCelland, … They could justify removing these types of questions by saying these theories are no longer part of the RDS. (October 14 Update - Students have reported seeing questions on the new exam on these personalities and ‘Theories of Motivation.’) Similarly, perhaps they have removed all “(AOA) Activity–on–Arrow” questions on the same grounds. (October 14 Update - Again, students have still reported seeing AOA questions and network diagram problems.) By the way, version four of the PMBOK Guide does not mention AOA either!. So, overall, there does not appear to be significant change in content (additions or deletions) in the new exam. I think, generally, they are diminishing the number of questions requiring mathematical calculations – (there will probably only be 5 to 7 such questions – and they are diminishing the number of questions in categories described above.!