Three Business-Case Arguments for Agile, & The Moose On The Table

Another conversation at the start of the new year - this time in our PMO, concerning project prioritization and resource assignments. Many organizations follow a "parallel" model, launching multiple projects at any one time and working concurrently to move things forward. To be fair, this often occurs because we start work on one or two things, only to have additional worthy business requirements pop-up as time goes by. Unfortunately, we don't stop the first project or delay the second; most teams attempt (with mixed success) to keep multiple plates spinning at the same time. This certainly feels less-than-optimal; stuff gets done, but it seems to take more time than one might expect.

Here's a simplified example; say I'm working on four projects at once, but I'm spreading my effort across them all:

As this picture shows, all the projects take a year to finish; note that none of these efforts deliver any value until they're finished. Resources are dedicated to the projects using the given percentages; I'm dedicating 25% of my time to each of these efforts.

An alternative, of course, is to work on projects serially; finish the first project before you start the second, and so on ...

There are a number of significant benefits to the latter approach - benefits that are easy to put in business terms:

• Higher NPV: Working in parallel mode, none of the projects deliver value until the end of month 12. In serial mode, the first project starts to deliver value in month 3, the second in month 6, and so on. From a cash flow perspective, the NPV of Mode 2 is much greater than Mode 1; this is something most business people grasp immediately.
• Focus leads to Speed and Quality: Possibly an oversimplification, but it seems apparent that if I'm only working on one project at a time, I am wholly focused on that effort, and I can drive to "done" faster. In Mode 1, my attention is diluted as I flip between any number of projects.
• Business Agility: For most teams, once you start a project, it's hard to stop. When I launch multiple projects as in Mode 1, I get "trapped" into trying to finish everything over the course of the 12 months. It becomes very tough for me to adjust my business priorities, react to changes in the competitive environment. On the other hand , if I work the projects in serial fashion, I can take advantages of the breaks between projects to re-evaluate and adjust priorities, refocus efforts on Project 1004, say, earlier than planned if that's where the most value is.

Yes, it's an overly simplified picture, but those are three pretty good business-oriented reasons to shift project teams to working on one thing at a time. The same logic applies to the various Agile methodologies, with short-duration, staged deliverables, shorter time-to-value, and the ability to reprioritize as you go.

I think the biggest reason why most organizations don't do it this way is the "moose on the table", the uncomfortable truth that everyone knows about but no one wants to deal with. Mode 2 is more confrontational; to start the cycle, you're going to have to tell three people (project sponsors for 1002, 1003, and 1004) that their project doesn't prioritize as high as 1001. Human nature, especially in the corporate world, leads us to avoid confrontation - but that's too bad.

... To get maximum benefit, you're going to have to disappoint the majority of your project sponsors - but only for the short term.

... The business likes to see something happening - any activity, even limited to 25% of my focus is "better than nothing" - but that's taking a very narrow focus.

When folks step back and look at the bigger picture, the business benefits of working on fewer projects at any one time jump out at you. Still, it's a tough conversation to have ...

If it was easy, you'd be doing it already, right?