In that last post, I talked briefly about how to perform a functional analysis as a prelude to integrating agile project methodologies into a mixed PPM environment. In this post, I’d like take a closer look at some of the functions and identify examples of where their processes would have to be tailored to interface with an agile governance methodology.
Schedule and Financial Controls
Clearly, one of the first steps in integrating agile project management is flagging your agile projects and ensure they are excluded from many of your current reports. You’ll do this because if you’re tracking stage gate compliance on your other projects, you’ll need to identify a mechanism to exempt these agile projects from that structure – and then develop another report that meets organizational needs to track schedule progress on agile projects. This, in turn, may confuse your report readers who now need to look at multiple report types to understand the different project types.
One potential solution to this would be to roll your reporting up a level. Instead of creating different executive reports for each project methodology, identify what question you’re really asking and whether or not a common report could encompass both methodologies. Often the solution is to aggregate the reporting up a level.
In IT, aggregating your reporting might typically mean reporting not at the project level, but at the application level. For example, I may have multiple projects supporting a specific application. I could then track an aggregated budget for project work that supports an application at the application level to show cost overruns. When I drill into that, I can go to the project level – which would then be tailored by methodology.
Chances are that if you’re the kind of organization that worries about PPM processes, you’re probably tracking resource allocation. I won’t go to far on this topic as I discussed it last week in The Increasingly Misnamed Project Server…..but suffice it to say that your standard resource management tool may not be suited to managing agile projects.
In this case, rather than shoehorning the agile methodology into a tool not suited for it, consider using something more appropriate, provided that the task and work tracking mechanism feeds into your centralized resource management tool. In this case, when paired with TFS for task management, something like Project Server simply serves as a work aggregation tool, and not a work tracking tool. Taking it one step further, the agile delivery can be managed in Excel, then passed via TFS back into the centralized Project Server resource capacity.
Those are but some of the functions that would need to be considered when integrating agile project management into a PPM portfolio. The list goes on and on.
Finally, let’s finish this post where we started…back at the macro level. We’ve now knit a new methodology into our PPM processes. What’s the inevitable end result of this? Well, a more agile planning process. The inevitable result of PPM maturity and functional maturity is to get more granular in the planning process. What you’ll find is that your portfolio of work will increasingly look like an agile project writ large, with a backlog of work and a predicted burndown. Each quarter, work items will be swapped out and reprioritized.
Why is that? Take a look at this presentation from Mike Cottmeyer for his take. If I interpret his slides correctly, once we get to the point of mature PPM, we can estimate our available resource capacity well enough that we can begin to apply a kanban system to our portfolio, i.e. we only allow work into the pipeline when we know we have enough capacity. The corollary to that is that we start to chunk out our work into smaller chunks in order to generate the value possible using the available resources at the time.
As the PPM process becomes more nimble, the operational cost of planning goes down. And as the operational cost of planning goes down, the relative value of the PPM process overall goes up.