Wednesday, July 26, 2017

When is your Project Backlog Item "Ready" for selection?

As defined in the Agile Project Portfolio Management Framework Guide, the Project Backlog is an ordered list of all projects that might be needed in the organization and is the single source of projects for any changes to be made in the organization. The Portfolio Owner is responsible for the Project Backlog, including its content, availability, and ordering.

The Project Backlog lists all projects, ideas, proposals, enhancements, and fixes that constitute the changes to be made to the organization in the future. See my article on Demand Management for ideas on how to collect all these ideas.

 A Project Backlog is never complete. The earliest development of it only lays out the initially known and best-understood projects. The Project Backlog evolves as the organization and the environment in which it operates evolves. The Project Backlog is dynamic; it constantly changes to identify what the organization needs to be appropriate, competitive, and useful. As long as an organization exists, its Project Backlog also exists.

Project Backlog refinement is the act of adding detail, estimates, and order to items in the Project Backlog. This is an ongoing process in which the Product Owner and the PMO Team collaborate on the details of Project Backlog items. During Project Backlog refinement, items are reviewed and revised. The Portfolio Team decides how and when refinement is done. Refinement usually consumes 50% of the capacity of the Portfolio Owner and PMO Team. However, Project Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Project Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Project Backlog items that will occupy the Portfolio Team for the upcoming Portfolio Cycle are refined so that any one item can be decided on within the Portfolio Planning Meeting. Project Backlog items that can be decided on by the Portfolio Team within a Portfolio Planning Meeting are deemed “Ready” for selection in a Portfolio Planning. Project Backlog items usually acquire this degree of transparency through the above-described refining activities.

The Project Backlog Item

Depending on your organization and your portfolio you will need different information for your Project Backlog Items to make the right decisions. But my experience has shown that the list below will give you a good start.

Sponsorship
Who would be the project sponsor?
Finance
What are the estimated costs? Estimate the following:  
1. Project costs: internal and cash out
2. Yearly operational costs
3. Total Cost of Ownership for 5 years (or shorter when the life expectancy of the project result is shorter)

As explained in our article on Categorization the most effective estimates for the Project Backlog are Range Based Estimates.
Driver
What business problem does the project solve?
Strategy alignment
Which strategic goals does this project align with? See the article on Categorization on how to link project backlog items with strategy. Add regulatory/compliance and operational as option as well.
Risk
Describe what is the impact of not doing this project?
Describe what is the risk of doing this project?
Give one risk valuation High, Medium, Low for use in the risk-value portfolio bubble chart.
Benefits
What is the value of this project to the organization. Express in CHF as well describing in text. List the expected benefits.
Success metrics
How will we measure success? For example:

- Stakeholder satisfaction
- Customer satisfaction
- Quality delivered to customer
- Return on Investment
- Meeting business case objectives
- Customer adoption
- Meeting governance criteria
- Benefits realization

Full scope, on time and in budget has nothing to do with success! It just tells you something about the ouality of your estimations, not the results of your project.
Culture
Is the organization culture right for this kind of project? Describe and give a valuation Yes or No. 
Technology
Do we bring in new technology inhouse or do we build with and upon existing technology? Describe and give a valuation. A categorization that I have used many times is the following: 1) Technology exists in the organization, 2) Technology is easily acquired, 3) Technology is hard to acquire, 4) Technology needs to be created, 5) No technology needed
Approach
Would we buy or make?
Time criticality
Should it be executed in a certain timeframe in order to give benefits? Describe and give a valuation Yes or No.
Client Impact
Would there be a lot of change for our clients? Discontinuing a service could have a very high impact for some Clients. Describe and give one valuation High, Medium or Low.
Employee Impact
Would there be a lot of change for our employees? For example, a new ERP system would have a very high Impact. Describe and give one valuation High, Medium or Low.
Training
Will staff training be required? Add to costs!
Portfolio
How does this project links to other projects in the portfolio? Dependencies? Shared platforms? Double work? Describe.

The moment you have collected the information above you are "Ready" for evaluation and possible selection of this project for you portfolio.
Posted on Wednesday, July 26, 2017 by Henrico Dolfing

0 comments: