Top Navigation

In a fast moving, technology driven marketplace, companies are forced to adapt and deliver quickly or become yesterday’s news. As a result, agile delivery models, optimizing one’s workforce by automating processes and off-shoring work have become standard business practice.

This paper focuses on agile delivery models and the role of the Project Management Office (PMO) in an agile organization. My perspective is based on delivery experience in both the traditional waterfall methodology and the agile delivery model, establishing and running a PMO in both types of environments.

What is a PMO?

In most instances, a PMO is a name given to a person or team within an organization that manages the processes, standards and best practices of project management. Project management in this context can mean establishing these practices, as well as enforcing and perpetuating their use within an organization. Tangible deliverables are the specific templates used for status reporting, issue and risk management, communications plans or dashboards produced for executive leadership. Project management can also be the approach taken on how projects are run and setting expectations for any individual managing a project in the organization. A PMO may also provide a pool of resources from which a project manager is chosen to run a specific project. Finally, depending on the role of the PMO in an organization, a PMO may also determine whether a project is approved for investment or not based on criteria established by the organization.

PMOs and the Agile Delivery Model

At first glance, a PMO and the agile delivery model appear to be at odds. A PMO is structured, stresses documentation and supports project managers. The agile delivery model is less formal, requires minimal documentation and distributes traditional project management tasks across the project team. Seems cut and dry that they are polar opposites? Not quite. Viewing both in a holistic manner, we see that both have the same goal in mind- prioritizing what’s most important in order for an organization to reap the maximum benefits from the limited resources and budget. Having experienced first-hand the merging of these worlds at our clients, I strongly believe that PMOs add value in an agile environment. The trick is to blend or hybridize what works best from each world. I address five major PMO functions below and discuss their applicability in an agile environment.

Establish Standards

One of the main purposes of a PMO is to establish standards for use by project managers in an organization. This is typically in the form of documentation standards. The benefits derived from having standard documentation include being able to effectively communicate with leadership what can be expected from an organization’s project management team. Standardized documentation also enables a quicker ramp-up of new or less experienced project managers coming into an organization. As mentioned earlier, the agile delivery model minimizes the use of documentation in general. However, it does support utilization of tools necessary to support a project. This inherent flexibility gives an organization the ability to use as much or as little documentation as desired. Having managed several projects under the agile delivery model, the answer in my experience lies somewhere in between. An overabundance of documentation is far too cumbersome while having none creates more work to communicate appropriately across multiple resources, teams and geographies. Here are my recommendations on what documentation works well for agile projects:

• Project Plan – The project plan outlines overall project duration as well as when sprints start and end. Detailed tasks for each sprint will be identified at Sprint Planning meetings. Management of budget and resource allocation can be accomplished assuming the project plan feeds into a resource / time tracking tool.
• Status Reports / Dashboard – In order to best communicate to executive leadership the status of a project, a status report, project dashboard or burn-up/down chart provides the simplest means to do so. Structured correctly, the high level budget, timeline and any risks or issues can be highlighted to leadership for their review or action.
• Risk and Issue Logs – All projects have risks and issues. As projects get larger, there will be more of them. In order to best track these and confirm appropriate actions are being taken on them, a risk / issue log needs to be created and managed.
• Lessons Learned – At the end of each sprint, a retrospective meeting is held to discuss what went well and what did not. Beyond the discussing of these items at the meeting, capturing and publishing them helps in translating them into action items.

Encourage Communication

Agile projects require constant communication between members of the project team. Depending on how tasks are broken out, resources will constantly be either asking for things or providing things to others on the team. This is especially so when there are impediments to completing a given task where several people may eventually get involved in removing an impediment. A PMO may have a more structured process for these discussions but does not conflict with an agile approach. Below are the four types of meetings in an agile (Scrum) delivery model and their relationship to the traditional waterfall model:

Establishing Processes

As mentioned in the previous section, there is an inherent set of required meetings under the agile delivery model. Every sprint has a specific set of meetings set aside to address the start of the sprint, the progress of the sprint and the completion of the sprint. A PMO also can help to establish a set of required meetings to support the various phases of a project: analysis, design, testing, implementation, and production support. With Agile, these meetings occur cyclically by sprint while a PMO in support of waterfall projects does the same by project phase.

Agile is very flexible in allowing changes during development. One of the key reasons why our clients have adopted agile is not only to see results sooner but also to have the ability to re-prioritize during project development. For example, after the Sprint Planning meeting if the client decides they would like to add a new requirement to the sprint, this is acceptable (as long as something else of equal or greater value gets dropped from the sprint). Design approach changes are also acceptable within a sprint as long as it does not exceed the capacity of the resources to do the work. A PMO would be supportive of this approach by providing a structure by which changes are tracked and approved, sometimes referred to as Change Orders. In the case of new requirements (requirements that were not part of the original scope of the overall project), a Change Order would document the change and obtain agreement between the client and vendor on additional incurred costs.

Supporting Release Management

Although not specifically responsible for release management, a PMO indirectly supports this function by providing data to release management in support of their planning and decision making. Having a PMO standardize project plans and status reports:

• Allows release management to develop release plans quicker and with greater accuracy
• Highlights resource availability and capacity
• Identifies possible development or testing environment conflicts where multiple projects may need to use the same environments
• Identifies dependencies between projects
• Enhances overall communication to stakeholders

The need to manage projects in this manner would be necessary regardless of development methodology and a PMO, in support of release management, would fill this need.

Estimating Costs

Estimating costs for typical PMO managed, waterfall based projects follows the standard gather requirements and size method. Sizing is usually based on several factors including experience level of resources selected for the project, historical estimates of similar projects done previously and utilizing an estimating tool using data derived from both of the above. In the agile delivery model an estimate is provided based on the available scope at the beginning of the project but a more accurate sizing is done at the sprint level during sprint planning. Should the estimates coming out of sprint planning cause the overall budget to be exceeded, additional monies would need to be obtained via Change Order (or approved use of contingency) or there would need to be a de-scoping exercise to lessen the work to fall back within budget.

A compromise on cost estimating works best in an agile environment. Being able to provide the estimated cost to the client at the start of each sprint for the scope of the sprint would be ideal. In reality, however, a client would want the estimate for the entire scope of work at the beginning of a project in order to appropriate enough budget from their project sponsor. As such, a detailed estimate needs to be calculated at the beginning of the project in order to come up with a sizing that the client can refer to as a realistic number. A counter-balance to this is to have sufficient contingency set aside to cover any overages that may result out of a given sprint planning meeting should those initial estimates fall short. Estimating in this manner is another process that a PMO can help establish for project managers.

Conclusion

The difficult economic landscape of today makes it more challenging to justify any added costs without a return in equal or higher value. A PMO can provide that value in an Agile enabled organization. One has to come to an understanding that a PMO is not tied to waterfall methodology. A PMO is just another tool, albeit a powerful one, that is methodology independent. The perception that a PMO goes hand in hand with traditional waterfall projects needs to be decoupled to avoid throwing the baby out with the bathwater.

About the Author

Jeffrey Kitsu is a Manager at Kenny & Company. Mr. Kitsu has over 20 years of IT Project Management experience of which the past ten were spent managing large projects Fortune 500 companies. Mr. Kitsu holds a BS, Mathematics / Computer Science, from the University of Nevada-Reno and is a PMP and CSM. He is a former Consultant with Accenture. You can contact Jeffrey via this blog or at www.michaelskenny.com.

About Kenny & Company

Kenny & Company is a management consulting firm offering Strategy, Operations and Technology services to our clients.

We exist because we love to do the work. After management consulting for 20+ years at some of the largest consulting companies globally, our partners realized that when it comes to consulting, bigger doesn’t always mean better. Instead, we’ve created a place where our ideas and opinions are grounded in experience, analysis and facts, leading to real problem solving and real solutions – a truly collaborative experience with our clients making their business our business.

We focus on getting the work done and prefer to let our work speak for itself. When we do speak, we don’t talk about ourselves, but rather about what we do for our clients. We’re proud of the strong character our entire team brings, the high intensity in which we thrive, and above all, doing great work.

This article was first published on www.michaelskenny.com on June 24, 2011. The views and opinions expressed in this article are provided by Kenny & Company to provide general business information on a particular topic and do not constitute professional advice with respect to your business.

Using Agile Methods for Enterprise Software Implementations by Darin Archer and Will Yen, Kenny & Company is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.