As defined in the Simple Portfolio Management Framework, 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 an 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 the 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 quality 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 in-house 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 link 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 your portfolio.
