Agile Portfolio Management
Functional silos… matrixed teams… unnecessary levels of specialization… these are the factors that make it really hard to run stable projects.
People are spread across too much stuff. Keeping up with where people are supposed to be (and when) is a nightmare. When projects change, it is very difficult to assess the impact because of the number of cascading interdependencies.
Unpredictable projects make for unpredictable portfolios. One significant change and the whole thing falls apart. The cost of change is way too high.
When faced with overwhelming system complexity, we move toward service oriented architectures. In the face of overwhelming requirements complexity, we move toward user stories and use cases. These strategies create independence between agents, hide their complexity, and have them interact with each other across defined boundaries.
It helps make each problem self contained and very well defined. When one component is changed, these strategies contain the cascading impact.
Think about Bill Wake’s INVEST model for user stories. Stories should be independent, negotiable, valuable, estimateable, small, and testable. What if we applied the same logic at the project level? What if we created a project portfolio that followed this same general framework?
Let’s see what that might look like?
Independent – Projects have minimal dependencies between them. They only share resources when absolutely necessary. You align releases to minimize date dependencies.
Negotiable – Project objectives are defined up front, not detailed requirements. Negotiable is manifest in the agile backlog.
Valuable – Expected return is defined up front. At the end of the project we can clearly assess if the project yielded the expected return.
Estimateable – Projects are well defined enough to get a handle on their size
Small – No project bigger than 3 – 6 months. Make investment decisions in smaller increments.
Testable – Projects must have well defined acceptance criteria
Could an organization run a backlog of projects like it runs a backlog of stories? Could a portfolio owner make decisions about what projects to bring into the next release based on their priority and relative business value? Could we take the sprint planning metaphor and elevate it to the portfolio? The same kinds of things we do to manage the flow of backlog items through the system would be done to manage the flow of projects, just one level up?
Do these same metaphors apply? I know some folks are doing this. I don’t know of anywhere where this is being written about. Anybody know of someone that has defined a model like this?
Photo Credit: http://www.onshoretechnology.com/EnterpriseServices/BusinessConsulting/tabid/132/Default.aspx
Comments (8)
Artem Marchenko
Latest incarnation of INVEST (as Mike Cohn teaches it, for example) changes “small” into “sized appropriately”. That is top stories should be small enough to take several into iteration, mid-level ones – bigger, and bottom ones can be huge epics of a release size.
Do you think it makes sense to portfolio to size its projects appropriately and not of roughly the same size?
Mike Cottmeyer
I have been thinking at a high level about this approach for a while now… but have not had the opportunity to try it. This is one of those posts that fall into the category of ‘thinking out loud’ or proposing an idea.
I have talked with a few execs about the idea and think it could work. That said, the key would be to make everything start and end within a release boundary. Not that everything could be 3 months, but that each project would be less than 3 months (or 6 whichever your organization decided)
If I were able to pilot this idea, I would use the same principle as I use for iteration planning. My goal is to have all stories fall within the sprint boundaries. Sometimes they carry over but at that point are subject to reprioritization.
Using the sprint planning metaphor, all projects should strive to fall within the release boundaries.
Again… story is to project as project is to portfolio. In this case iteration is to project as release boundary is to portfolio.
Make sense?
Jim Benson
What are the projects? Are they greenfield (entirely from scratch), enhancements, sustaining?
These have different impacts on the organization, but are often treated as “projects”.
Most organizations don’t differentiate at the planning stage and dump the work on the production team wholesale. This causes chaos as different groups fight for scarce resources after a project has started – rather than prior to the allotment of work.
A good understanding of the actual capacity of the team and a rule that you can’t give them team more work than it can process will force the prioritization upstream.
Mike Cottmeyer
I think this approach can work for established products or greenfield.
Established products, it is much easier to jump in with a well defined backlog, break the project into 3-6 month releases, and manage the portfolio in smaller chunks.
For a greenfield project, you have to load your portfolio with small projects that prove the vision and lay the architectural framework. These early projects are investments that may not yield an immediate return. They are higher risk and more speculative.
First you approve a project to validate the business vision and build a small working architectural prototype. If that yields the expected value, then approve a small project to fully flesh out and test the ‘walking skeleton’ of the application.
These early proof of concept projects don’t have to take an entire 3 months and could be small enough to get them done in a single organizational planning cycle.
If your overall product is still on track to deliver the expected business value, approve a first production release.
I would want to balance my portfolio with higher risk new product development and lower risk incremental development.
Mike Cottmeyer
You would clearly have to have an organization and staffing approach to handle this kind of project/portfolio management.
You would want to have established teams where possible and bring projects to teams rather than reconstituting project teams at each planning boundary.
If you did need to juggle people around, the planning boundaries would be the time to do it.
IMO – the sprint planning metaphor scales to this level as well.
Martin Olesen
Hi Mike,
I think the idea of prioritizing projects like you would user stories is very interesting. I do however have some concerns regarding switching cost and predictability.
How do you predict expected value with the needed precision to prioritize, when you believe in the fundamental that the future is unpredictable and the business is therefore allowed to change their priorities regularly?
By splitting solutions (larger) into 3-6 month projects you could end up not realizing the value you expected due to switching costs.
I have tried to detail my concerns with a couple of examples in a post on my own blog (http://www.agilethoughts.dk/?p=116).
Above said, I really like your suggestion and I definitely would like to try the principles out on a portfolio or hear from someone who has.
Nice job Mike!
/Martin
Mike Cottmeyer
I did a bit of a reply to your blog directly: http://www.agilethoughts.dk/?p=116
The key is to lead the organization to be disciplined about delivering business value is smaller increments.
Your comment:
“How do you predict expected value with the needed precision to prioritize, when you believe in the fundamental that the future is unpredictable and the business is therefore allowed to change their priorities regularly?”
What is your alternative? No planning at all?
I have worked with teams that literally think agile is telling them to only plan two weeks at a time, no roadmap, nothing past the next two weeks. Personally I think that thinking is crap and will hurt the agile movement.
Plan to a sufficient level of detail to give the business some idea of what is coming, leave room to inspect and adapt, deliver in short cycles so you can change if you need to, so you can deliver value frequently.
Think about all the concepts we discuss about ‘within projects’… velocity, relative estimating, definition of business value, prioritization, timeboxes, flow, staffing, ownership, pull systems, inspection, adaptation…
They all have a parallel at the portfolio level. Abstraction is higher and planning horizons are longer, but again… I think all the same kinds of things could apply.
If the organization is expecting a waterfall predictive portfolio full of agile projects, that is going to be problematic. It sounds like that may be your fundamental concern? Am I missin your point?
Søren Raaschou
I have had the priviledge to work with a customer on agile portofolio management. They wanted to be able to replan every month ie. XP (extreme planning ;-)
When I came on board they paid a large switching cost (as Martins concern). They did however not want to compromize their freedom in planning every month – the solution had to be found elsewhere.
We chose to focus on DONE and being really sharp on the value of each iteration. DONE is important to eliminate the effect on the following projects and value is important to keep relatively stable priorities. This is beginning to pay off: Projects are allowed to run longer and switching cost are going down.
As an additional effect it has become even more obvious, that you cannot focus too much on value and done. We have reached high predictability and very high value.