Posts Tagged With: Valuable projects

What’s blocking your benefits realization?

PMI just released the Benefits Realization Management practice guide this month which provides comprehensive but still easily consumable coverage of a benefits management framework covering principles, practices and roles. There is no doubt that benefits management is a critical competency for any company whether they are for profit or not-for-profit but it is also not well  implemented in many organizations.

Overly optimistic business cases might be one reason for this as I’d covered in an earlier article, but there are other potential causes including:

  • An unwillingness to hold sponsors accountable for expected benefits. While punitive measures may create a culture of fear and drive otherwise effective sponsors away but there still needs to be some way of ensuring that sufficient due diligence has gone into identifying benefits. Independent verification of benefits analysis is one way to reduce inflated expected outcomes without scaring off potential sponsors.
  • A lack of objective definition of the benefits expected to be realized when executing a given investment. Even for initiatives with a financial benefits motive, it may be difficult to demonstrate causality between the outputs of the project and expected financial outcomes as there will usually be more multiple projects with the same types of measures (e.g. increase revenue, reduce costs).
  • Limited monitoring of expected benefits over the life of an investment. Projected benefits like scope, schedule and cost baselines represent what is expected at the point in time when they were defined so ongoing forecasting is crucial. Without this, delivery might be successful within approved scope, schedule and cost constraints, but the project’s ROI is never realized. Sometimes there is no owner identified for tracking benefits during the life of the project while other times an owner has been anointed but is ineffective in that role or is unwilling to declare that the project won’t deliver expected benefits proactively.
  • Benefits realization timelines are excessively long. The more time which passes between the end of a project and when expected benefits should materialize, the more fragile those benefits will be due to the impacts of internal and external changes.
  • Poor project delivery. While the outcomes of a given project may not change, if the costs or timeline for realizing those increase significantly due to delivery issues, the project’s ROI will be worse than expected.

For leaders looking to improve benefit realization from their project investments, doing some root cause analysis to identify why projects aren’t generating expected benefits can help them to focus their improvement efforts.

Mohamed El-Erian – “Investors have to ask themselves two questions. How much can we grow our investments? And, can we afford our mistakes?”

 

 

Advertisements
Categories: Project Management, Project Portfolio Management | Tags: , , , | 1 Comment

How effective is your benefits management framework?

Benefits management, like project risk management, is practiced poorly by most organizations. While project intake processes usually require some articulation of expected benefits, few companies effectively monitor and control the realization of those benefits over the life of a project and beyond. This is especially true with discretionary investments as the benefits from mandatory projects are usually related to risk reduction and are usually immune to changes in strategic objectives or external environmental influences.

So what are key elements of a holistic benefits management framework?

Benefits definition

Beyond stating the expected benefits of a project, an operational definition of how those benefits will be measured and a baseline against which performance can be measured needs to be provided.

It is also important to provide a conservative timeframe within which measured benefits can be directly attributed to a project’s outcomes. This can be quite challenging with enterprise portfolios containing multiple interdependent projects and programs where a single Key Performance Indicator (KPI) might be influenced by a collection of projects. In such cases, governance committees should determine whether expected benefits should be measured at a higher level and the contribution of individual projects pro-rated in some manner. It also helps to have individual sponsorship at the KPI level to avoid overlaps in benefits recognition.

The defense of a project’s business case needs to include a thorough analysis of projected benefits by an independent party. This analysis should focus on assumptions and risks impacting benefits realization. The business case should clearly indicate who is responsible for monitoring and reporting on benefits over the life of the project and for the portion of the benefits tracking lifecycle beyond the end of the project.

Finally, governance bodies should specify a “kill threshold” so that projects whose benefits erode below this threshold will be terminated.

Benefits re-forecasting

Once baselines have been approved, regular re-forecasting is crucial to avoid continued investment in projects experiencing significant benefits erosion. The specific frequency of these re-forecasts is context-specific, but a minimum cadence should be established at the portfolio level to support normal portfolio monitoring and reporting practices.

Releases, phase end gates and change requests should all include a benefits re-forecast and review.

For those projects where business value starts to accumulate prior to the end of the project, tracking and reporting of these benefits should be incorporated as part of normal project performance reporting practices.

A good project manager will influence factors affecting business value and is not afraid to call for a project’s cancellation if expected benefits won’t be realized.

Post-project benefits tracking

This is the weakest of the stages of benefits management as a project manager is no longer around to influence a business owner to track and report on realized benefits. Confirming ownership for these practices as one of the transition activities at the end of a project can help, but tying the quality of benefits management practices on their past projects to the evaluation of new project business cases is one way to build “skin in the game” for business owners and project sponsors.

The Sixth Edition of the PMBOK® Guide defines project management as “The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.” It would be ideal if the Seventh Edition enhanced this definition by modifying it to “The application of knowledge, skills, tools, and techniques to project activities to achieve benefits by meeting the project requirements.” Doing so will provide a valuable reminder that project management has to be about more than stakeholder satisfaction and delivering within scope, schedule, cost and quality baselines.

Categories: Project Management, Project Portfolio Management | Tags: , , | 1 Comment

How do your pods divide and conquer?

chopping-woodA good practice with agile delivery is to keep team sizes small to reduce the number of communication channels. But when planning a product release which cannot be delivered by a single pod within a reasonable amount of time, we need to structure the work across multiple pods of five to a dozen team members working in parallel but also orchestrating release cadence and work item priority based on the dependencies between work streams.

So how should work be structured across the pods?

Focus on capabilities

Capability-centric pods take ownership for completing one or multiple features or customer journeys which will provide meaningful value to their stakeholders. For example, a pod working to launch a purchasing portal might deliver browsing and searching capabilities for users.

Benefits of feature-centric pods include that they will rarely struggle with demonstrating tangible progress to their stakeholders at the end of each sprint and as they have end-to-end responsibility for a customer-facing feature, the magnitude of coordination between pods to deliver value is reduced. Should funding for the product run short, there is a greater likelihood of delivering some key functionality to their customers.

While feature focused pods align well to the “what”, from a solution design perspective, there is an increased requirement of cross-pod collaboration to ensure that data models and design approaches are aligned, and there could be specific enabling capabilities which get distributed in this model but which might have been better delivered by a single pod. Specialized competencies might also need to be stretched across multiple pods if the features each pod is delivering requires those skills.

Focus on components

Component-centric pods divide work based on a defined solution design or architecture. For example, one pod might take ownership for data interfaces while another is responsible for user experience. This model resolves the concerns with the capability-centric approach but introduces the need for greater discipline from an integration testing perspective and can make it challenging for individual pods to be able to demonstrate tangible evidence for what they have achieved to their non-technical stakeholders. Given the higher degree of feature-based cross-pod dependencies, productivity differences between pods can also cause greater impacts than with a capability-centric approach.

So let’s be pragmatic with our approaches!

Sometimes, the right answer might be to use a hybrid of the component and capability models. For example, if multiple capabilities are relying on a solid data foundation, a pod might take on that work and start earlier than other feature-based teams to address foundational dependencies.

 

 

Categories: Agile, Project Management | Tags: , , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: