Enjoying one of those rare confluences where my blogging, professional and speaking lives all converge at the same moment into the same topic. As it looks like I’ll be presenting this at the upcoming Houston PMI blowout, I figured I’d try to capture it on virtual paper as part of my preparation.
The general question is how to integrate agile project management into a mixed portfolio of agile and non-agile projects. This really ties into the discussion I posted a couple of weeks ago on EPM Bingo, or how to perform a structured analysis of your project portfolio management system.
Start from the Top
The basic gist is to back away from the daily processes, and look at the overall project lifecycle. Regardless of execution methodology, most project lifecycles follow the same standard process, i.e. registering the idea, building the business case, authorizing the project, doing stuff, reporting on stuff, etc. The nuance when we start looking at different management methodologies is to determine where the SDLC is determined, and then assessing the downstream impact of that decision.
The macro view is indeed quite simple – just a couple of boxes. 🙂 I didn’t even need to resort to fancy arrows or circles.
The pre-authorization stages of an agile project are pretty similar to a traditional waterfall approach. We build the business case and do the estimates and maybe a high level risk assessment. It’s at this point in a mixed methodology PPM organization that we might first consider to assign an SDLC model. I won’t digress too far into SDLC determination as that was the topic of this rant.
Suffice it to say, I am strongly of the opinion that the SDLC should be tailored to the scope and risk of the project. In a nutshell, the projected volatility of the scope should really dictate the SDLC model chosen – and that scope might not be accurately defined at this early level in the budgeting/approval process.
Once the SDLC determination is completed, things get more fun. That’s where we need to perform an analysis of the functions we’ll be supporting. By “functions,” I mean the various other offices and roles within the organization that require information from the project team:
- Resource Management
- Release Management
- Architectural Strategy
- Financial Controls and Chargebacks
How do you know which functions you support? Take a look at the existing project lifecycle and catalog the various reports and data that are passed back and forth from the project team to those outside of it. You’ll end up with something like this:
Chances are you went through this exercise informally when PPM processes were first implemented. Now we’re leveraging that to add another project management methodology to the mix. Each of the boxes in the grid above should have defined inputs and outputs to the functional boxes hovering around the perimeter of the system.
Let’s take a look at a couple of those functions in the next post.