The Business Driven PMO

In my last post, I busted a common misperception that agile projects don’t provide enough executive visibility. Today I’m going after a second widely-perceived myth: Agile Projects Lack Reliable Scheduled Finish Dates.

It’s a fact that agile methods are designed to adapt quickly to changing realities, whereas more traditional methods focus on planning the future in detail. Although agile teams shy away from providing guaranteed delivery dates (given the cone of uncertainty around a project), it’s untrue that an agile project can’t provide a scheduled finish date.

Agile teams use ‘just-in-time’ estimation for iterations and focus on delivering business value incrementally. However release and roadmap planning is used for longer range estimates. If an executive hears that an agile team is only prepared to give estimated delivery dates for the next couple of iterations, it should raise a warning flag about the team’s capability to build a credible release plan.

The use of ‘epics’ (large stories) and ‘themes’ (groups of stories) can be used to estimate work that still requires detailed scoping. To be able to estimate with some degree of reliability, an agile team will need to have some degree of normalization around the size of stories and understand their velocity (story points delivered in an iteration).

Once the differences with agile projects are understood, developing a PPM framework with standard metrics that apply to both agile and traditional projects is important. Scheduled finish date is just one of the five common metrics that enable executives to get visibility into project status, regardless of the delivery method:

• Scheduled Finish Date. ‘Planned finish date’ is the estimate made at the inception of a project for the planned delivery date, whereas ‘scheduled finish date’ is the estimate of a project finish date at any given point in time based on current data. For a traditional project, this is based on the task plan and critical path for the project. For an agile project, it is based on the release plan. Given a ‘cone of uncertainty’ exists regardless of project methodology, the accuracy of scheduled finish dates should be comparable for both traditional and agile projects. Comparing scheduled finish date to planned finish date will give an indication of the team’s ability to estimate delivery dates accurately.

• Percent Complete. Percent complete provides an indication of project progress. Percent complete for a traditional project is calculated by summing the hours for completed 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.

• Scope Changes. Percent complete gives an indication of progress, but does not show if the scope is changing on a project. For traditional projects this is typically represented by the number of change requests. For an agile project, it is typically measured by the change in total story points over time.

• Actual Cost vs. Budget. Both traditional and agile projects have capital and operational expenses that are tracked. Actual cost vs. budgeted cost should be reported, regardless of the project methodology.

However, it’s not appropriate to ask an agile team to track time at a task level to calculate resource costs. Instead, resources should be dedicated to an agile team and costs calculated accordingly.

• Project Health. Project health is a summary metric that indicates if a project is ‘on track’, ‘needs attention’ or is ‘in trouble’, usually indicated by Green, Yellow, Red stoplight colors. This metric varies by organization and is often calculated using conditional logic based on the four metrics above, as well as other data such as outstanding issues. One of the simplest ways to calculate project health is to compare actual percent complete with the expected percent complete based on the start date and scheduled finish date (assuming the velocity of work delivery across the project timeframe is uniform). A project health status of ‘needs attention’ or ‘in trouble’ is often triggered when projects are not delivering business value, there are significant scope changes, costs exceed budget or there are major unresolved issues on the project.

Providing these metrics in a dashboard format using a PPM system enables executives to quickly identify projects that require focus or intervention, regardless of the project management methodology employed for its execution.

Do you agree? What’s worked for your organization and what’s fallen flat on its face? Let us know here. 

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.