Home | Login | Recent Changes | Search | All Pages | Help

InverseRedTapeRule

The effectiveness of any process is inversely related to size of the beaucracy that grows up around it.

The large company that I work in has a process surrounding how software projects are managed. Large staff organizational groups exist - called Project Management Offices (PMOs) - to do nothing but communicate and enforce project beaucracy. Project managers work out of these groups, not business lines so they answer to some staff manager rather than someone who has profit and loss responsibility. These project managers are supported by yet another staff position, project controllers, whose sole job is to fill out the myriad of forms that are required.

If my rule is correct, they could improve the effectiveness of their software project management process by just getting rid of some of the beaucracy and staff positions that surround it. I wonder....

BobKing 2003.03.24

I've been around a couple of projects that had person whose job it was to manage the model of the project schedule (aka the MS project plan). THe fact that that person was there freed up the project manager to actually manage the tasks, relationships, and people that made up the project.

EstherDerby 032503

BobKing 2003.03.25

I agree with Esther's comment about the value of having a person whose job is to keep up with MS Project. On large projects, more than ten people at least a year, the project manager has much to do. The extra person who keeps up with the schedule is a big plus. I have seen PMs try to do this. They usually did a poor job of it and the time they spent on this task kept them from doing other things.

Today is the first day I have read this thread of the wiki. I agree with Bob's opening statement about how extra bureacray drags down projects. Another way to look at this is the staff people have paying jobs. It seems there are many people in the IT and computer business right now without paying jobs. Eliminating some of these staff positions would mean more unemployed people. Maybe eliminating the needless jobs would open up a job for a programmer who would contribute to project success. What I have seen, however, argues against this. If an organization eliminates a staff job, that is the end of it. They don't hire a programmer or tester instead - they just eliminate a job.

The root problem I see is that someone above all this is not doing their job. Some senior manager(s) is not managing. That senior is allowing staff people to hinder work instead of contribute to it. So should we eliminate this senior manager's job? Again, one more person unemployed. I see the better path as trying to convince the senior manager to manage the staff more effectively. Easier said than done.

Just a little different perspective on this.

DwaynePhillips 26 March 2003

At some point, if you can find the right ear, you might get some leverage by arguing that the weight of the accumulated ceremony has become detrimental. Have a story ready for what parts of the ceremony could be discarded (or waived), and why.

I'm thinking that a PMO, like any part of an organism, will defend itself if attacked head on. A stealth war of attrition, where you get waivers for more and more parts of the ceremony, might be more effective.

DaveSmith 26 March 2003

This is where beaurocracy has a chance to start setting in:

I've been around a couple of projects that had person whose job it was to manage the model of the project schedule (aka the MS project plan).

With the "admina-drones run amok" flavor of inept management, the person keeping the chart becomes the one who "knows what's going on", equated with "management." It's downhill from there. One mitigating tactic is the "keep your eyes on the prize" approach. I've found you can often stop the slide toward sensless over-organizaiton by continually turning the conversation back to: "What are we trying to accomplish here?"

Arguing about "bureaucracy" is usually a kind of chaos / order argument where the thing - the red tape - is a stand in. Chaos sometimes causes some discomfort. So does getting organized. Neither chaos nor order is the point, or in fact is the discomfort. People end up arguing because they have different comfort levels with chaos and order. The conversation is personal, although the words chosen are not. The "right" amount of chaos ("freedom" if you're for it) is the amount I'm comfortable with, of course. So is the "right" amount of order ("red tape" if you're against it.)

The trick is to change the conversation to "keep your eyes on the prize." The point is getting something done. So the right amount of chaos, order or discomfort is however much goes with the value we're trying to produce. At any rate, I've found it to be a good tactic to reorient discussions about "chaos" and "red tape" to what we're trying to get done, and work from there. This works well with two rules of thumb:

• Whatever bad and evil thing (chaos or bureaucracy) that is being complained about was done for a reason that made sense to someone at some time. It's useful to find out why, if you can.
• Whoever is complaining the loudest is likely wrong about how much chaos or order we ought to have. Often they're talking about some other horrible experience - the martinets run amok project, or their time at Random-corp - not the problem we're trying to solve right now.

But that's just me. I could be wrong. - JimBullock, 2003.03.26

Management that cannot see the cost, benefit, state and schedule of all the projects cannot make good investment choices. A PMO may enable visibility, which may enable management to eliminate projects that aren't producing and redirect the capital to projects that are underfunded are not funded at all. That action is a good thing.

In my experience though, a PMO may end up as just a smoke screen. It's an action that management can take to look effective rather than be effective. In other words, the executive creates a PMO bureaucracy but the project investments don't change. Although jobs are created, I think this situation is worse than before the PMO office. The employees, especially the first-level manager, are compelled to complete a bunch of bullshit paperwork. And the new PMO jobs may be created by the elimination of other worthwhile jobs.

PMOs often continue to survive on pure inertia. It helped management see the state of the company?s projects. Management corrected the problems. The PMO now becomes a stable bureaucracy that is redirected to prevent fires rather than put out a fire. The more devastating the original fire, the more the inertia. If the bureaucracy is minimal, this state is a good thing. Otherwise, it is a pain in the ass.

What does an employee do about a PMO bureaucracy? I have never changed the direction of a PMO office. Unless I could see that the bureaucracy was at a tipping point or open to change, I would not even make an attempt. I view a PMO like taxes. Either I pay my taxes or I deal with the IRS. I pay my taxes.

The approach that makes sense to me, but I haven't tried, is to build influence with the executives who spoonsor the PMO. By understanding their problems, I may have an opportunity to influence the direction of the PMO.

SteveSmith 2003.03.28

Steve, you've hit on how PMO's often don't work. To paraphrase: The problem a PMO gets created to solve is managing investment and risk, specifically with project activities. The customers of the PMO function are the folks making investment & risk decisions.

I think it falls down because rather than tackle the bear that's causing the problem, PMO's I have seen are full of "how to do this" kinds of stuff, and grade school hallway monitor type taddling. "We'll make a policy that everyone has to use MS-Project, and I'll go narc to teacher on the bad boys and girls who don't." The bear to tackle is in the investment management. What are we trying to do? Are we at all certain that we are making progress?

I've seen at least two things help (Indeed, I've introduced them, and they seemed to help. So I may be wrong, but at least I'm consistent<g>):

• Project charters. Why are we doing this? What is "this?" Why is it good? How will we know when we're done?
• Project portfolios. What's the list? What do we know about each item on the list, like started / not, and all the stuff in the charter?

I think that's maybe the way to influence the executives, by talking in resource allocation language about their inventory of risky investments. Gets the PMO being a staff function, vs. meddling. If they were that smart about getting stuff done, they'd be the project managers, not the project managers. When there was real money on the table - $ to spend on a project - the PMO admini-droids weren't the ones trusted to make something happen. So if the PMO folks are telling the PM's "How" in detail, and dictating execution decisions, there are several possible ways this is wrong. It's wrong at least one of them.

Charter & inventory puts avoided decisions right back where they belong. Hey, guys, we're off doing this thing. Should we? Do we have any confidence in the people we've assigned to deliver? Do we have any insight into what's happening?

-- JimBullock, 2003.03.28

I work in a group that is just now going through an introduction into PMO practices. We are in our 3rd stage of 'acceptance'.

Initially, we did try to accept them believing that once we understood them they would be providing value back to us - like real project costs, cross project issue resolution, consistent status reporting. We were eager to get going. We went through the training and got started with the initiation phase on the projects that needed to begin.

I think that we started to move to the second stage during the training, where we heard many times: "Don't worry about it, just do it." The second stage was disillusionment. There did not seem to be any rhyme or reason to the processes. We found out that managers needed to be within 2% on their monthly actuals which meant that they have to really just tell people what hours they should report on projects - regardless of what they actually spent. There is more - like it takes roughly a week of full time work by the project manager to set up a project (this is after the statement of work is done and the project has been approved). We still believed that after we understood it better, it would provide value to us.

The stage that we are in now is one of open cynicism. We are beginning to create our own processes to provide the value that we had hoped the PMO would provide. Worse yet, we feel defeated. We are slowing down work on projects simply because the PMO processes cannot keep up with the pace that we are working. We will need to let contractors go that we know we need and would have work for right now if only the PMO process could keep up.

I think about looking for work at a smaller company - one that does not have the money to waste on a PMO.

And another corporate group is looming on the horizon - the Corporate Architecture group. Another fantastic idea - take people who have proven themselves to be the best technical people in the company, put them in one group away from where the real work is being done and ask them to ensure that the 'right' technology is being used on projects.

BobKing 2003.03.30

Bob, I feel you pain. God. Admini-droids run amok. It's nonsense like you describe (and I anticipate, the architecture folly that is about to ensue) that gives attempts at project management a bad name.

FWIW, I've seen the grand "we will do projects with some structure" undertaken from time to time, and it generally takes three tries. The first is great hope. The second is that the process & tools don't quite do what was intended. The third is a somewhat tuned, localized set of stuff that produces part of the value that was hoped for. That "three step" seems to be consistent, whether the middle "kind of off" iteration has too much stuff or too little.

Unfortunately, funding for a PMO type exercise often gets thrown at the folks who promise great (impossible?) predictability, and arrive carrying large, thick binders. Binder magic. Once all the overhead is in place not working, the money's been spent, and the project-guru people have another client to list.

The over control temptation happens when people don't have the Right to be Wrong(tm), and when we confuse estimates with predictions. All future activities have variability. Admni-droids are uncomfortable with the unpredictable world, so become unhappy about this. This adds fuel to the "planning is bad and evil" fire.

OTOH, I have several running arguments with some "planning is evil" folks. Bad planning is evil. Bad planning often involves pretending that you know stuff you don't. That's evil. But pretending you don't and can't know and predict stuff you can know and predict is more evil. "We need a pile of code, and it's a big pile, and that'll take a bunch of guys a long while." Well OK. That's something. Now can we get any more precise about that? That's way, way different from giving up on the planning and predicting process entirely.

I do have a two part suggestion for successfully dealing with managing projects:

• Make it OK to not know stuff.
• Once it's OK to be ignorant, ask: "What do we actually know, and how well?"

I have a three part suggestion for introducing PMOs and related as well:

• Require that the folks putting a PMO in place use their own tools & techniques, religiously.
• Offer to pay them on a "risk shared" basis. If this actually helps, you'll get paid. It turns out people are often way, way more confident with someone else's money than they are with their own<g>.
• Suggest that as a high-value service, the PMO (or architecture) ought to be billed back to the projects it supports, and the projects should eagerly seek that help. Of course, that ought to be up to the PMs and their sponsors.<g>

I have done the latter two as a thought experiment as part of a management team talking about introducing "project management." We ended up doing something rational, and the big methodology advocate hated me. (For the rest of time, I assume. I can live with that. The guy was gunning for a field promotion without any accountability - "You all have to do what I say, but I'm not responsible for delivery on your projects.") I have done the former suggestion - eat our own dog food - to some extent every time I've run a support function. It's great feedback on our "service" and gives us credibility with our customers.

But that's just me. I prefer to get stuff done.

-- JimBullock, 2003.03.30

I get the feeling that you are dissatisfied with your job, which concerns me.

What's happening for you?

If you would prefer to talk rather than write, please call me.

SteveSmith 2003.03.31

Dissatisfied is a bit strong for where I am at right now. I went back to employee status for three reasons really - to get connected again at a more detailed level with software project work, to make good on an opportunity to do something significant and to work for someone that I respect. All those reasons are still in play.

In addition, when I first started last year, we were under the corporate radar and the company was experiencing record volumes, so we had an environment wherein we could really just get stuff done.

Now, that we have been made by the corporate radar, we will be reigned in. I don't like it, but in some respects that is a good thing. I am going through an adjustment process and am not really sure where I will end up...

BobKing 2003.03.31

Often, processes and structures are put in place to get this to happen -- regular reporting, MS project, PMO offices... IT seems to me that all of these can work -- or not -- depending on the attitide / culture of the organization, and the / 'bravery' (for lack of a better word) of the individuals within it. A structure can be a major plus if the people and culture are aligned or at least open; if they are not, people can find ways to hide anything.

My $.02 DianeGibson 8-26-03

I am afraid that I disagree mildly.... often the structures are valuable when things are good, because they provide a clear means to raise and address issues. Also, in a more open culture, people are more likely to raise problems with the structure ITSELF, if it becomes to burdensome -- and those problems will be addressed as well...

Boy -- I really wonder how often that comes to pass.... Oh well, something to strive toward, anyway...

DianeGibson

Ashes to ashes, and all that... RobWyatt 2003.9.11