The Business Driven PMO

The agile movement has had a significant influence on best practices for project management.

However, some agile ideas about embracing change, ‘just-in-time’ planning, and eliminating hierarchical decision-making have led to misconceptions about the compatibility of agile projects with PPM processes. Over the next three posts I’ll set the record straight about common project management fallacies that have led to concerns over how to monitor and control an agile project as part of a project portfolio.

Let’s look at the first myth: Agile Projects Don’t Provide Enough Executive Visibility

A large part of the popularity of agile is the belief that teams should be empowered to make business decisions rather than relying on executive stakeholders for approval. Empowering a team, however, does not mean they shouldn’t provide timely executive status reporting. The struggle many agile teams face is the requirement to provide status reporting in a format that is inconsistent with agile practices. For example, a requirement that an agile team maintains a separate task plan to enable reporting on metrics such as ‘percent complete’ can negatively impact the benefits of an agile approach. Instead, executives need to learn how to interpret project status from an agile team rather than impose reporting requirements that are not consistent with agile.

Let’s take percent complete as an example, which provides an indication of project progress. Percent complete for a traditional projects is calculated by summing the actual hours for tasks and dividing by the total task hours for a project. In contrast, an agile project progress is measured by story points delivered. Percent complete is calculated by story points accepted divided by total story points for a project. Educating executives on what a story point is and how it measures progress enables agile teams to report progress in the unit that makes sense for their team.

One caveat is that reporting on ‘percent complete’ on a program when the underlying projects are using different units, such as task hours and story points, can lead to inconsistent results. In this case, finding a common metric across projects is advisable, such as ‘function points’ or ‘business value points’. This requires an organization with a high degree of PPM maturity, a well-defined methodology and strong training programs to educate program and project managers.

The rise of agile development practices is driving many benefits to organizations by creating a culture of continuous feedback and a focus on delivering high quality software that meets customer needs. Although some fallacies around agile development exist, it should not deter PMOs and executives from encouraging agile adoption in their organizations where appropriate. Project managers and PMOs should carefully consider which projects are suitable for agile methodologies. They should also develop a PPM framework that applies to both agile and traditional projects to enable executives to get visibility into project status, regardless of the delivery method.

What are your thoughts? Have you had experience educating executives on the differences between agile and traditional projects? Let me know.

Earlier this year, we polled more than 60 enterprises that have been using Daptiv to track some of the emerging trends in the industry.

Our survey asked about integration plans, budget levels, as well as corporate structure. We had customers from a wide variety of industries including financial services, healthcare and business services. Here are a few interesting results from the research:

1. Business PMOs are prevalent and reporting to the C-Suite

Back in November, we predicted that more enterprise project management offices (EPMOs) will report to the CIO as PPM best practices are taken out of IT and into the business units. Our survey results show that 33% of the respondents have their PMO or EPMO reporting directly to the CIO, with others reporting to C-Level executives including the COO (19%), CEO (11%) or CFO (8%). This indicates the emergence of the PMO as a vital role in shaping not just IT, but overall business strategy.

2. Integration is making PPM the linchpin of strategic decision making

Nearly half of the survey respondent said they have or are planning integration to enterprise systems like ERP, SAP, Oracle, etc. This enables users to gain better insight, management and control over business processes and provides a single view of project costs. Integrating PPM with IT operations tools and application development tools (including agile tools) is also becoming more common and allows enterprises to integrate real-time project data and support a variety of project management methodologies.

3. PMO budgets are increasing

In a potentially good sign of business investment, many Daptiv customers are seeing their budgets increasing in order to take on more projects. Out of all the Daptiv customers responding to the survey, 37% reported that their PMO budget would be increasing, some by as much as 20% or more. Only 6% of those surveyed reported that their budget would be decreasing in 2011.

Let us know what you think – is this consistent with what your organization is seeing? 

I attended Gartner’s 2011 PPM and IT Governance Summit last week with the Daptiv team . Here are a few insights on Gartner’s latest thinking I picked up from the conference:

1. Project Management is in transition.  IT Organizations have realized that not all work can and should be managed as a project.  Moreover, all projects are not created equal and gone are the days of using a waterfall approach for managing all projects.  This is reflected in Gartner’s latest thinking on IT work  which includes  a new framework that categorizes work based on the certainty of requirements and their time to value.  This helps organizations choose the methodologies that best fit the type of work such as agile projects, waterfall projects, service requests, operations, etc.
2. The nature of PMOs in organizations is evolving.  Given how many PMOs have failed due to their perception as “Methodology Police”, PMOs in the future will be less about being the central enforcers of project and program management, governance and compliance.  Instead, PMO functions are more likely to be embedded in business units and more focused on business outcomes.
3. CEOs expect IT to deliver competitive advantage.As we pull out of recession and more investment funds are becoming available, innovating and taking calculated risks are the key to success.  Taking a portfolio approach to IT initiatives will give companies the ability to assess risk vs. reward and make informed decisions on what initiatives best meet their portfolio and investment criteria.
4. PPM is the glue that ties IT Governance, IT Service Management and Enterprise Architecture.  As programs and projects are the methods for creating change, and portfolios the organizing “glue”, a PPM framework , along with well-defined processes, is the best way to tie together the practice areas of IT Governance, IT Service Management and Enterprise Architecture.  PPM vendors looking to serve the IT management space must develop solutions that integrate with these areas.
5. It’s organizational alignment that makes PPM successful.  Gartner re-iterated what many experienced PPM practitioners have learned: If companies don’t have their people and processes in alignment, it is very difficult to achieve success with a PPM tool.  Companies looking to realize business value through PPM should not just select vendors based on the capabilities of a tool but look at the vendors based on their domain expertise and their ability to look at people and processes.

We’ve all heard this before: “It’s really important that everyone starts using this (tool/process/system) right away so that we will be more efficient and have all the information we need to run our business.  But remember, everyone here is very busy and we really can’t let this change interfere with their everyday work.”

In other words – this change is important, but not important enough to invest the time and attention to ensure its success.   Even worse, when efforts fail, the blame gets laid at the feet of the implementers or whatever is being implemented.  Then the effort begins again, with a different set of players only to suffer the same fate.

In contrast, organizations that are successful at change recognize that implementation and adoption are neither instantaneous nor automatic.  They recognize that the investment goes beyond the cost of the new system or the labor to implement it; there is also a significant investment of time and attention required from those stakeholders who need to adopt the new process, tools, etc. 

Successful implementers and adopters know that that additional time is filled with activities focused on making a successful transition.  While training is important, practice makes permanent as the adopter adjusts their work practices and builds expertise in the new way.  Open recognition by leaders of the additional effort is also key; it reinforces the importance of adoption, helps the adopter balance their priorities between getting work done the old way and learning the new and, it helps reinforce new behaviors.

Last, but not least, the transition from old to new is always eased by strong advocates and proficient guides.  These are the people on the ground during the transition – answering questions and helping the adopters be successful.  Ideally these people have strong first-hand knowledge of both the old and the new and are comfortable recognizing and addressing objections and resistance.   And, most importantly, they have the time.

So, even though whatever is being implemented may ultimately save time, up-front time is required  to ensure adoption.   A couple of years ago I was in a meeting where a customer was sharing lessons learned on adoption from the implementation of a new ERP system that had been introduced two years prior.  As he reflected back on the adoption over the past two years he observed:  “The first year we worked for the new system and then the second year it worked for us.”   We can always wonder how much pain could have been avoided with just a little bit of extra time.

As both an IT-PMO Director and CIO, I've had occasion to hire and evaluate quite a number of project managers. During one of those stints a colleague of mine and I decided project managers generally fell into two camps - what we called task managers and project leaders.

The task managers had the "science" of project management down pat. They could put together great task plans, log issues and risks, and produce project status reports. They loved checking off tasks as complete, checking off requirements as done and completing projects on time, on budget, and on scope. 

Problem was, they often missed the target. Say we started a project to enable customers to configure their product on the Web. We had one of these that was proceeding apace using the then-current technology. The PM dutifully checked off the tasks, kept the project in scope, and we were well on our way to having working screens and data. But as I looked at the result, it seemed to me to be difficult to use and required a lot of maintenance. One of the Web developers on my staff suggested a new technology that she claimed could be used to get a better result in half the development time - and she was right. I killed the project and we started a new one. I put the developer in charge of the new project (not a formal PM by training), and we ended up with a great interface that was easy to use and easy to maintain and modify.

What was the difference? The technical project manager did not understand the business target. Indeed, he was not trained in Web development and did not know the technologies. But he did know how to "manage" a project. The problem here is a project isn't something to be managed - it as a process that is intended to achieve certain business outcomes. Without achieving those outcomes, the money and time are both wasted.

Project Leaders, on the other hand, have a good sense for business and understand the desired outcome. They then lead and motivate a team to accomplish that outcome. In one of my favorite projects - an ERP implementation - the project manager knew that managing users expectations as we migrated from one major system to another would be a big challenge. She worked with me on the internal political problems that inevitably arose, and made an ally of the biggest internal skeptic. I knew we were ready to go live when I talked to the skeptic and she said "I didn't think we could do this, but you know what? We're ready". If the skeptic says you're ready, you probably are, and we successfully went live that weekend. This project manager was also not shy about changing scope and requirements if needed to make sure the processes we were implementing turned out right in the new tool, and asked for a slight extension and budget increase. We were slightly over budget and time, with numerous scope changes but guess what - we had a successful ERP implementation in a global company. Not a small achievement by any means.

So what do I look for in project managers? People who understand that project management is as much art as science. People who have the soft skills to understand the business outcomes and lead a team to deliver those outcomes. They need to know the fundamentals of project management, but even more so they understand project management is a craft - and they are masters of that craft.