Dear Bob ...
My question pertains to prioritizing projects: I'm a supervisor in the IT shop that supports a fairly large city department (~1500 personnel). We have 27 IT folks dedicated to supporting the department. (I say "dedicated" because we do get some additional support from the city IT staff too, but only limited support, since they're not cleared.) There are 3 of us working supervisors, plus the IT Manager.
For some time now, I have been fighting with our upper management to better address how projects are being doled out to us. I've stressed how we (the IT shop) have got to get a handle on this process because our folks are feeling overwhelmed and getting burnt out. I've had more than one person tell me "I don’t care what projects you want me to work on, just tell me which ones those are, and stop changing the list every week!"
So my senior management devised a plan to help us out by implementing a formal project request process (which we've done), and then they will prioritize the projects for us. Right now there are 55 approved projects on this list! And, of course, they're listed in 1,2,3… priority order. Which goes completely against your recommendations as stated in your book [the writer is referring to Chapter 10 of Keep the Joint Running: A Manifesto for 21st Century Information Technology - Bob].
At first, when this process was implemented, I thought it was a good idea, since it really didn't matter to me how many projects were on the list, since our folks could only work on the top 6 or 8 at any one time. But what's been happening is that as a new "hot" project comes up, they'll send me a new project list with this project listed as #7. So whatever we've done for projects 7, 8 & 9 have to stop, or be readjusted, to accommodate this new project schedule. Overall, projects are getting done, but the administrative overhead we expend to "manage" this process is killing us and our staff.
So according to your book, I need to convince my senior management to go with a single master project plan where all the approved projects are listed. And the response that someone who submits a project, should be either "No" or "When." I've read, and re-read this section several times, and I think I understand this, in principle. But how can I assure my management that the projects will be worked in the order they wish, if we do implement your approach?
- Governanced to death
Dear Governanced ...
Here's how I think you need to modify the process to make it work, and it isn't a very complicated change.
It's merely a very difficult change. It is to establish one more, inviolable rule: Once a project launches, it either continues to completion uninterrupted, or senior management decides to kill it.
The only circumstances in which a project might be put on hold is temporarily, for a couple of days, to deal with an extraordinary crisis.
What this means is that in addition to needing a master schedule, senior management needs to respect it. They can adjust the sequence of the not-yet-started projects all they want. They have to leave the ones that have left the starting gate alone.
There is another alternative, but it's radical, and might not fit your situation at all. That's to move away from projects in their traditional guise altogether, and instead to manage everything according to scheduled releases. It's a Scrummish approach: You'd organize into application teams, break projects as they're currently defined down into collections of enhancements that are as independent as you can make them, and redefine governance as a process for managing the enhancements "backlog," to use the Scrum vocabulary.
This doesn't fit every situation. In particular, it doesn't fit situations where you need to implement major new modules. But when your application portfolio is relatively stable and your projects are geared to extending their functionality, it can work quite well.
The trick in all of this isn't the governance itself, whichever way senior management decides to go. It's having the leadership to make it happen and the discipline to consistently apply it.
Which gets to something that's going to sound like a sales pitch, but is meant as serious advice: This is the sort of solution that's most easily implemented with outside help ... not because it's all that hard to understand, but because of what's needed to get the decision-makers past the mental hurdles associated with acknowledging that what they created isn't quite good enough.
Add to that the need for each member of the governance committee to think like a leader of the entire organization rather than as a representative of a particular area. Frequently, it's easier for an outsider to facilitate the process.