Life after project completion: Is a project complete without benefits realization?

In our day-to-day project management and PMO activities, the easiest and the most important thing missed is planning ahead for what happens AFTER we cross the finish line. So technically speaking, once project managers hand over the reins of the completed project to the business owner, their job is just half done. For a project to be considered complete, project managers must focus on the other half, which is “Benefits Realization”.

Benefit realization is the confirmation that the value a project was expected to generate really does get delivered.  In our everyday project management lives it is easy to get buried in details around task management, risk mitigation, resource capacity, balancing budgets and all the other moving parts.  We often forget why we set out to do the project in the first place:  the delivery of a product or service, an enhancement or improvement, or a capability.  For example to meet some new regulation, standard or market demand.  But what if, after we deliver the goods, and did exactly what the customer asked for, we realize that all the effort and resources we used to deliver the project don’t amount to what they were supposed to?  That’s exactly what benefits realization is all about.

We’ve all heard of ROI – return on investment.  It is the concept of an investment of some combination of resources (people, money, equipment, etc.) yielding a benefit to the investor.  A high ROI means the investment gains compare favorably to investment cost. As a performance measure, it is one of the best methods to evaluate the efficiency of an investment.  ROI does not exclusively have to be in financial terms.  It can easily be an operational advantage, an improvement in position, or other positive change.  In order to compare the efficiency of a number of different investments we need to compare like measures, which is why a financial ROI is one of the most commonly used.  Unfortunately, without benefits realization, our ROI is simply a guess.  And that is why benefits realization is so important.

I’ve discussed with   many of our clients about this and have found out that there is a need for a wide degree of maturity around the realization process.  This is an indication that while the concept of realization is gaining interest, it is still far from a mature practice.  Which presents a great opportunity for those organizations that are not doing it – now is a great time to implement this practice.

How to launch a benefits realization initiative?

One of the best approaches involves setting goals, tracking against those goals and including a ‘hand-off’ step, similar to the passing of the baton in an Olympic relay race.  Tactical steps you can take include:

  • Set your sights:  using whatever calculation available, combined with experience and validated by results from similar projects, come up with a target for what the value you think the project will deliver.  Set that as the initial estimate.  Enlist the help of a financial leader or controller to help set the original estimates.
  • Continual monitoring:  Using the initial estimates or targets as a first guess, continue to refine the success factors throughout the lifecycle of the project.  These are often called forecasts or committed values and are more accurate than the original estimates.  It is best to continue revising these figures throughout the lifecycle of the project.  The objective here is to have these forecasted numbers eventually match the actuals.
  • Start tracking actuals now:  some project can actually generate benefits even before the project is complete.  What a great win for the project team to be able to report these.
  • Put a plan in place: Add a milestone or stage beyond the Complete step called Close or ‘Realization’ and set a validation step 3, 6 or 12 months after the project is complete.  It sets the expectation that the work is not over at Complete.
  • It is outside of the project manager’s responsibility:  As the project comes closer to its Complete or End date, engage the financial sponsor and the process owner (the person who is benefiting or owning the project’s or product’s outcome, improvement or change) and have them start validating and “owning” the numbers.
  • Go back to the beginning:  how accurate were your original estimates compared with your forecasts and your actuals?  Take those learning and apply them to future estimates.  This is called continual improvement – applying lessons learned and best practices to improve the entire PMO.

One last point is that it isn’t always about the money.  Sometimes projects generate other value, such as an improvement in customer satisfaction, or increase market share by launching a game changing product.  It is important to be able to quantify the value of these types of projects even if they do not generate direct revenue or cost improvements.  Many organizations call these ‘Level 2” or “Indirect Benefits”.

Finally, is a project complete without benefits realization?  To the project manager who’s already run their marathon and marked the project as complete, I expect their answer to be ‘yes’, but common sense tells us otherwise.  As a best practice, one of the most important factors in a projects success isn’t “how we did it” – coming in under schedule or under budget – but “what we did” – that the project delivered what it set out to do.

Survey Finds Resource Management is the Top Business Challenge for Senior Executives

We recently surveyed 100 senior IT executives at the Gartner PPM and IT Governance Summit from May 20-22, 2013 to gauge and analyze the key business challenges faced by organizations in today’s economy. Interestingly 67% of respondents considered resource management as their top business challenge, 28% of them found it difficult to justify the value delivered by the Project Management Office. 22% stated that keeping track of time and money leakages was a concern. Only 5% considered delivering change without overburdening their staff as their main issue, which can likely be attributed to their usage of PPM software and resulting benefits.

“67% of Senior Executives Identified Prioritizing Work to Fit Available Resource Capacity as Their Biggest Business Challenge”

Project Management Offices are increasingly seen as custodians of the resource management process within organizations, and this is validated by another study conducted by pmsolutions research – “The State of the PMO 2012”.  The study looked at a broad spectrum of companies across the globe and found that the number one priority for the PMOs is to “Improve Resource Planning and Forecasting Process.” Pointing towards similar findings, both the Daptiv survey and the pmsolutions’ study reveal that overcoming resource management challenges will be vital for PMOs to justify their value in the future.

You can find the details of the survey here.

Introducing and Setting Up a Project Management Office

In my last article we delved into organizational maturity for setting up a PMO; this article will deep dive into how to introduce a PMO without disrupting the established system. The first step is good communication–clear and complete information reduces confusion and eliminates resistance based on fear and conjecture.

Communicate the mission, objectives and purpose of the PMO. Be open and transparent regarding the decisions and activities of the PMO. Inform the enterprise of the reason(s) the PMO exists, what it will do and how it will bring value to the enterprise. Also, demonstrate how the PMO will be a partner and not a hindrance in working toward the success of everyone in the enterprise.

Once the need to set up a PMO has been identified and the communication campaign is actively underway, the PMO must be designed from the beginning to meet the specific needs and environment of the business it supports. Project Management Offices take on many roles depending on their mission and objective, hence setting up a PMO is not a short-term activity. It requires significant effort to complete analysis, design, planning, review and implementation. Cooperation and involvement from the business is essential to ensure the PMO meets their needs. Involving the business early and often by keeping open communication channels and soliciting feedback will allow you to manage expectations regarding the amount of time and effort required to set up a PMO.

Setting the priorities of the PMO
In order to move ahead with the planning process, the business should first set the priorities of the deliverables and services of the PMO. Next, assemble a planning and implementation team that includes stakeholders in addition to the PMO subject matter experts. In my opinion, business stakeholders must be involved throughout this process to analyze and take ownership of business needs and progress. On the planning side, it should be phased out, using a rolling wave approach as opposed to a “big bang” approach. These phases should be scheduled out using the roadmap model with detailed planning occurring at the initiation of each phase. This makes the planning current and more relevant to the prevailing business condition.

Laying down project management processes
The next major task is to identify processes and tools required to support the services and functions the PMO will perform. Depending on business needs and budget, an organization may either develop in-house tools or purchase tools from vendors to help streamline projects. Project management processes should be designed to guide the project managers in the performance of the project. PM processes need to be adaptable to meet the needs of any project. A simple project with little risk may require a very light application of the process, whereas a complex project or a project with high levels of risk will necessarily require a more rigorous process.

Project management processes are generally based on standards or best practices such as PMI’s Project Management Body of Knowledge (PMBOK), PRINCE2 and agile. In addition to general purpose standards, organizations may also require and benefit from specialized project management best practices such as process improvement (Six Sigma), new product development and Go-To-Market.

Project Portfolio Management (PPM) is another function often found in PMOs. Organizations turn to PPM to manage their entire portfolio of projects, much like a portfolio of investments. In fact, projects are investments and companies expect to get the maximum return and benefit from these investments. PPM is the process by which they achieve this. Through project selection, project mix evaluation, portfolio monitoring and other activities, PPM is used to maximize returns on the portfolio.

Resource management (RM) often becomes the responsibility of the PMO because it is a natural partner with project management and project portfolio management. Within every organization there is a finite supply of resource types–including people, financial, and physical assets. Resource constraints affect both project work and operational work, the normal day-to-day work of the business. Accordingly, resource management processes should track the operational work (the day-to-day activities) in addition to project-specific work being done by the business in order to paint a complete picture of the total capacity or work an organization can truly deliver.

It is evident that these PMO functions are integrated and integral to the success of an organization. While organizations can adopt some of these elements, ultimately an organization needs to implement each of these disciplines to some degree to manage its program office effectively, even if they are being managed at different degrees of maturity. The project portfolio lifecycle encompasses elements of the project management process, the resource management process and financial management.

Keeping the PMO Relevant
To complete the whole cycle of project implementation and as part of a continuous improvement program, regular feedback from teams/project managers will help maintain the efficacy of the PMO at all times. It’s helpful to develop a continuous improvement program that includes:

  • Periodic reviews of the PMO objectives against the needs of the business
  • Measurements of the processes and tools such as effectiveness, adoption and consistent use
  • Identify areas for improvement

In the end, be sure to give new processes and tools time to be used long enough to overcome learning curves and to gather enough feedback and data to be able to make well-informed decisions. By their very nature, program management office teams are change agents. They institute new processes, implement new tools and may bring about changes in the way organizations conduct business. When planning for organizational change, the PMO must create conditions for change. Be aware of the politics of the organization, and build a base of support for change within the organization.

The third and final part of this series will touch upon metrics and how to measure success of PMO.

Linking Business Strategy and Projects

Introduction:

Most of us recognize that having a strategy is a critical element for growing and improving an enterprise.  It is the strategy that defines the purpose or mission of the enterprise, establishes a clear vision of what we want to become, and provides goals or targets for accomplishing that envisioned future state.  In short, the strategy defines where we are going and ensures that we are all working in concert toward that same destination.

Unlike strategies, which broadly span the organization and are directional in nature, projects are tactical; they focus on creating specific capabilities, deliverables or outcomes.  Optimally, our projects (what we do) are in direct support of our strategy (where we want to go) and become the mechanism by which our strategies are implemented.  If we undertake projects that do not align with our strategy, we risk expending valuable time and resources on efforts that may not contribute to the long-term success of the organization.

Creating a clear linkage between strategy and projects can be a challenge, particularly in large organizations, but the benefits are well worth the effort.  In this article we will explore some practical approaches to establishing a clear linkage and using that linkage to realize tangible business results.

Create an Integrated Plan

In most cases, the translation of strategic objectives directly to individual tactics (or projects) results in a disjointed, scattershot approach where some strategic objectives are addressed by multiple, overlapping projects while other strategic objectives are ignored at the project level.  To avoid this, the successful organization creates an integrated plan that recognizes and records interim levels of goals and objectives that essentially cascade strategic objectives down through an organization.

Structure the Plan to Establish Alignment  (Top Down)

An integrated strategic plan helps us ensure that we’ve covered all the bases by successively defining how each level within an organization is going to contribute to the achievement of a set of objectives established at the level above.  For example, if the Executive Committee has established a set of strategic objectives, the second level of the integrated plan may consist of strategic initiatives or strategic goals that each division leader identifies for their division in support of the strategic plan.   The level below the division repeats the process to define how they’re going to support the division goals by defining programs, and so on until at the lowest level of the plan specific tactics or projects are defined (see Figure 1).

While the above example uses the organization hierarchy as the framework for creating the integrated plan, other hierarchies like line of business, product line, or geographical location may be more appropriate for organizing and building the top down integrated plan.  Regardless of the structure of the hierarchy, the process is top down, with each successive level identifying and defining their goals.  Each level clearly identifies who is accountable for performance at a given level and who provides oversight for the level below.  One could also argue that the integrated plan provides us with a model for sponsorship, with each level acting as the sponsor for the efforts directly below it in the hierarchy.

Figure 1:  The Integrated Plan

While the number of levels in the plan may vary based on the size and complexity of the organization, the structure of any level must recognize the objectives in the level directly above, thereby encouraging greater alignment as objectives are pushed out across and through the enterprise.

Quantify Goals and Objectives

While the communication of goals and objectives has value in maintaining ‘directional correctness’ for the organization, quantifying those goals and objectives provides clear targets for planning and measuring performance.

In quantifying objectives we need to focus on both sides of the business case: The return or benefit expected and the amount of investment expected to achieve that return.   Quantified cost and benefit targets remove ambiguity from the planning process.  If we create a plan assuming unlimited return or unlimited investment we have no way of evaluating or determining which initiatives, programs or projects actually represent the most advantageous mix in our portfolio of strategic investments.

Validate the Integrated Plan Bottom Up

As the Integrated Plan is created by cascading objectives from top to bottom, each successive level down is validated by the level above.  In other words, the individual or group responsible for a level must review the aggregate of plans from the level below to ensure that the individual pieces and parts from the lower level will, in the aggregate, accomplish the higher level objectives.

Perhaps the most difficult part of the bottom up validation process is dealing with the imprecision of the process.  While we do want to make sure that what is being planned at a lower level will realistically yield expected benefits for expected investment, there are no guarantees.  Consequently, in doing our validation we should not expect lower level numbers to tidily add up to the higher level numbers, but instead manage to realistic ranges of variations and recognize that as the plan is executed, adjustments and decisions will be needed to maintain alignment.

Be Flexible and Iterative

While we have presented a fairly structured top-down approach, it is important to remember that creating the integrated plan is not a rigid, linear process.  For example, it is not necessary to wait to start creating a lower level of the plan before the higher level is set in stone.  In many organizations, the construction of the integrated plan is an ongoing process where each level of the hierarchy is continuously adjusting based upon new information as it becomes available or in response to changing business needs.

Tracking:  Maintaining Alignment

While creating an integrated plan goes a long way in creating alignment to the strategy, maintaining that alignment over time is equally critical.  The primary difference here is that while creating the plan is typically driven top down, information used for tracking progress flows from the bottom up.  The key here is that the flow of information needs to be directed upward through the integrated plan in such a way that each successive level has the appropriate level of information for decision making.

As with any type of tracking, the first challenge is to determine what type of information is meaningful, determining the appropriate source for that information, and creating the processes to collect, analyze, and distribute it.  Additionally, we need to establish accountability and timeframes for information collection.

Collecting Information

Typically data collection for tracking starts at the project level.  Fortunately we have a plethora of mechanisms and processes for doing this and, in most organizations, accountability lands squarely with the Project Manager.

Where it gets fuzzier is when strategic goals and objectives cannot be tied to a single project or measured during project execution.  Tracking the realization of benefits is a good example of where the information from the project(s) is not adequate for tracking progress to a goal.  Let’s say we have a goal of increasing client satisfaction with our website by 20% before year-end as measured by survey responses.  To accomplish this objective, we have identified 3 projects to improve different aspects of the site.  Two of the projects will build on the work done on the first.   We’re making the assumption that each of the projects will yield some improvement in customer satisfaction, but the full benefit won’t be realized until all three projects have been completed.

In this example, we do need to understand projects, both individually and in the aggregate, but this information does not provide any measurement for tracking achievement of the 20% improvement in customer satisfaction.  In this case, we need to recognize that the tracking process that yields the appropriate information resides not in the projects, but instead at a higher level of our integrated plan.  Furthermore, whoever is responsible for setting and achieving the objectives in that level of the plan is also accountable for reporting on the progress at that level.  In other words, when we talk about performance information flowing upward through the integrated plan, it is realistic to assume that additional information and analysis will be added at each level.

Data Collection and Reporting Cycles

Establishing the frequency for reporting against the various levels of the plan may vary widely even within a single enterprise.  That said, establishing minimum requirements including frequencies and content of status reports and plan updates is critical to ensure that the right information is available at the right time.  One approach to establishing these requirements is to determine key review meetings at or toward the top of the hierarchy and work backwards from there.

If the Executive Committee meets quarterly to review the strategic plan, then the level below should be doing their analysis and tracking quarterly – with enough time before the meeting to compile the results.  Lower levels will report more frequently, with the general guideline that each successive level updates its plans and reports at least once, if not twice, before the status report at the next level is due.  Unless there is a compelling business case for doing otherwise, tracking and reporting more than weekly tends to add overhead without much offsetting benefit.

Maintaining the Integrated Plan

Like any other kind of plan, the integrated plan is a model of what we expect to happen.  It gives us a yardstick by which we can measure our progress against our goals.   It is not exactly what will happen nor is it something that will continue to add value if not maintained.

Whether we’re updating the plan to address a performance variance, or changing a high-level strategic goal to respond to market forces, the integrated plan may need to change.  Processes for making and communicating these changes keep the plan relevant and helps maintain the linkage between projects and strategy.

Conclusion

In summary, linking individual project efforts to a strategy is more than throwing a bunch of projects at the wall and seeing what will stick.  Building an integrated plan that cascades strategic objectives down through the enterprise creates a clear linkage between strategies and tactics (projects) while clearly identifying interim level goals, objectives, and accountability.  The integrated plan also provides a practical approach to collecting information for tracking progress and making adjustments across an organization.

While creating and maintaining an integrated plan can be challenging, the value-add of ensuring alignment to a strategy is well worth the effort.

The Future of Project Portfolio Management – Perspectives from the Gartner PPM Summit

Gartner gave us an interesting look into the future of PPM this week, and projects as we know them may be left behind. I’ve been wondering about this for some time, as the pace of business continues to accelerate and business changes – represented by projects – are called on to deliver results faster and more frequently. But I’m getting ahead of myself.

Let’s rewind from projects back up the business stack for a clearer view. Gartner did this nicely from their opening keynote through their multitude of breakout sessions – many of which were standing room only. In this note I can only summarize the model, but I will delve more deeply into each area in future posts.

First, we must remember why we execute projects – to implement change in the business. Be it incremental improvements in efficiencies enabled by minor software enhancements, or transformational change in the form of a merger – projects have been our vehicle. Gartner rightly points out that the pace of this change is accelerating to the point where it is almost constant. Can the old annual planning cycles and waterfall projects really keep up with this pace?

Most projects today involve changes to some application system, as IT has become thoroughly embedded in most modern enterprises.  Techniques like Agile can continuously release improvements to these applications, taking in ideas for change and working them into a continuously prioritized stream of stories. And these stories – which represent useful business changes – can be released frequently. We are now talking weeks or months to roll out changes to applications, instead of years.

How to manage all those applications? Enter Application Portfolio Management. Much like managing a portfolio of projects, APM rationalizes and prioritizes applications. Andy Kyte (VP & Gartner Fellow) gave a dynamic presentation on APM for Executives that boiled this concept down to some simple truths. He reminded us that applications are really means to an end – business value. Using that as the goal enables us to make decisions not only about which apps should stay and which should go, but where they should reside. Do we really need all those systems in house, or would a SaaS or even a BPO model provide the desired business outcomes more efficiently?

This brings us to the top of the stack – business value. IT systems do not in and of themselves provide any value at all. So what does IT really provide? Business Capabilities! And here Gartner sounded an interesting new theme. Instead of seeing capabilities as just part of the EA stack, consider these like products. A SaaS shop like Daptiv, of course, delivers PPM capabilities as a product – and we see it that way. IT shops should consider that they are really delivering products like Purchasing Management, Workforce Management, and Strategic Sourcing. Viewing these as products allows IT to focus their efforts on delivering business value rather than just technology.

So now we see the full model being proposed by Gartner. It really uses some tried and true techniques from Enterprise Architecture and adds a few twists. We start with business capabilities at the top, which are now enabled by IT products – apps and supporting infrastructure to enable those capabilities. And we move away from simple application and project management to product management. And now that we have products to support, we implement a continuous change cycle – such as Agile – to ensure changes to the business outcome driven capabilities are implemented quickly and frequently.

The current pace of business is such that the old model has lost its usefulness and would leave us eating someone else’s competitive dust.