I put Project Management 2.0 as the title just to give Glen Alleman a moment…
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?