OK, so for those of you that manage the Project pipeline, I'm sure that many if not most of you have experienced those Charters that don't get approved, or die. The documentation gets completed, it goes to the powers that be, but somehow even though it doesn't get an OK2GO, it doesn't die either. It seems to perpetually stay on hold, but it keeps on getting brought up during the Steering Committee meetings, and six months or a year after its initial pitch, it is decided that the documentation should be reviewed, updated and reviewed again by the team for another OK2GO. Maybe after another ten or 15 hours of labor invested, it again doesn’t get the green light, but still manages to stay alive in the purgatory of the “on Hold” status category. Or better yet, it stays in the “Analysis” stage forever, just sucking up resources and time, and mutates into something that is larger than China.
It makes sense that there are Projects worth doing, but that are not critical or high priority so they hang around waiting for “just the right time”. You know, that time when the moon and constellations are arranged a certain way, and a WNW wind is blowing at exactly 28mph. There’s value in reviewing the Project regularly, but we also have to make sure that we aren’t continuing to beat a dead horse. So what do we do?
The question becomes “how do we make sure that we aren’t continuing to spend a large amount of time and effort on a Project until we have commitment and the proper funding”? Or, looking at it another way, ”how do we limit dollars spent getting something to the “Go/NoGo”, and avoiding the research on the Project expiring for those items on Hold?” The answer lies in how structured you want to be, and how detailed you’re going to get with your parameters. I see quite a few different ways to accomplish this.
You could place limits on the amount of iterations the Project can be reviewed for Go/NoGo. Equate this to the “three strikes you’re out” rule. There are also limits that can be placed on hours spent to get to the decision gate before there are either additional time/dollars allocated or transferred to the Project or the Project is killed. Of course how the PMO and IT departments are structured, as well as the accounting and finance infrastructure of the organization must be taken into consideration to assure a good fit in terms of procedure and ease of execution. There is also the possibility of allowing the Project to expire in the queue after a specified period of time. I mean, at some point the Project will cease to make sense, given the current speed of technological innovation in the marketplace. Now do you see where you can go with this? There are tons of ways to look at it, and many different combinations to achieve an expectation with the masses that things aren’t going to be allowed to sit around forever. Decisions have to be made on what the customers want, said a different way, poop or get off the pot!
Now, there really isn’t anything wrong with having a few hovering potential Projects sitting in the queue, as long as they don’t represent any expenditure of time or energy, and they don’t create confusion or a clog. However, we all appreciate organized, uncluttered data, and keeping the pipeline clean is part of our job, isn’t it?
So let’s “Manage That Pipeline!”
Margaret de Haan - MBA, PMP, CSM