A Project Management Article by Mark Tolbert
In January 2012, Mark Tolbert presentated a popular PM Tools Workshop "Agile Project Management versus the PMBOK Guide and Earned Value Management". This article is Part Four of a seven part series that he wrote on the topic. To read parts one and two, please visit www.pmiwdc.org/articles. Be on the look out for the July - September Newsletters for the remaining three sections. You can also access a print friendly version of the article.
Other Misconceptions about the PMBOK® Guide. (Areas where people believe it is inconsistent with APM. It is not.)
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.
Note: this article reflects the viewpoint of the author, Mark Tolbert, and does not necessarily represent the views of PMIWDC. If you disagree with or object to the views expressed here, please let us know