Posts Tagged With: Valuable projects

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

I get the business rationale for agile, but what’s in it for ME?

what-about-meWhen we read about the rationale for an agile approach to project delivery, the focus is often on the benefits realized by the company or by their customers.

While we can’t marginalize the benefits of early and frequent realization of business value there is a compelling case to be made about higher levels of job satisfaction and engagement for the team members working on successful agile projects when compared with their counterparts on equally successful traditional projects.

Self-organization can certainly contribute – no one enjoys being told what to do, so collaborating with like-minded individuals to come up with the best way to achieve a set of goals is appreciated. Working in a psychologically safe environment and team will also boost job satisfaction by encouraging team members to safely challenge their assumptions about their capabilities. And becoming generalizing specialists through opportunities to perform different types of work will encourage personal development.

But no one says that these practices must remain limited to agile projects. Traditional project delivery approaches don’t discourage a project team from acting in a similar manner to an agile team. Even the agile pattern of long-lived teams works equally well on traditional projects.

But a few agile delivery characteristics stand out.

  • Frequent interaction with customers and other key stakeholders help to reinforce a team member’s appreciation for the importance of the work they are performing. Knowing that the work we are doing matters to someone and getting direct, regular feedback is critical. Of course this requires those interactions to be positive! There’s no reason a savvy project manager couldn’t attempt to create such opportunities on a traditional project, but it might be challenging to match the natural feel and cadence of showcases and similar ceremonies.
  • The culture of continuous improvement generated by a team acting on ideas from successful, blameless retrospectives can be very positive for team members. This coupled with a team lead or project manager’s focus on removing hurdles should encourage a team to maximize their productivity and quality. Understanding that we are performing at our peak can also be a powerful motivator.
  • Witnessing the business value created regularly through our combined work efforts is important. Knowing that what we have worked on has an immediate impact at the end of one or a few sprints can be much more encouraging than having to wait months or even years to see the fruits of our labor.

Never lose sight of the fact that projects and products are delivered by people – the happier they are, the better the outcomes.






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

Create a free website or blog at

%d bloggers like this: