I'm going to tell a happy Project Management story now. The project I am just coming to the end of has been one of the best run projects I have ever worked on and in the last ten years of contracting I've worked on a hell of a lot of projects. I wasn't the Project manager, so I'm not big-noting myself. It's easy to point out what's wrong in dysfunctional projects or dysfunctional workplaces generally but it's really refreshing to be able to cite a real world example where most things went right.
Here's the summary version: for a major project to work, you need to have ALL of the following in place -
- A Plan
- Flexibility
- Communication
- Support
- Respect
1. A Plan. It doesn't have to be an exhaustive plan with every task measured down to the micro level (see my previous Project Management post for my views on this idea) but you need to have an idea of where you're going with clearly defined milestones that tell you when you've reached key points in the project.
2. Flexibility. Just deal with the fact that you won't have thought of everything in the plan. Be prepared for the fact your estimates may turn out to be wildly inaccurate. Being right or wrong isn't as important as how you react when you are wrong. When you discover something you didn't know before, take it on board and analyse how it is going to affect the existing plan and milestones. DON'T PRETEND IT ISN'T HAPPENING! Don't pretend you can stick to the original plan if you work a little harder. This is why "Waterfall" fails - things change and it's useless to pretend otherwise. And if you happen to work somewhere toxic enough to punish you for telling the truth about these sorts of things - get another job. Quit or quit complaining.
3. Communication. I'm not talking about a series of interminable meetings that waste everybody's times. I'm talking about real communication - letting people know what's happening and how it will affect them. How you do this is up to you - the best method will vary with the situation; face-to-face, email and/or a wiki are all viable options. I'll do another post on identifying the appropriate levels of communication on another day.
4. Support at all levels of the business. If everyone involved isn't fully on board you are going to face a lot of unnecessary fights. The IT team has to agree, the business has to agree, the users have to agree, management has to agree, external customers have to agree and any vendors involved have to agree. Every day you spend in the early stages of a project getting various "champions" on your side will save you from a week to a month or more further down the line.
5. Respect. You have to respect everyone in your team. Your team has to have the respect of other areas of the business. Without this the project will get derailed by ridiculous shit-fights along the lines of "this is all going wrong because Bozo over there doesn't know what they're doing." The person in question may well be a Bozo who knows nothing. But if there isn't professionalism within a project then everyone suffers.
A few war stories from this project. One of the biggest strengths of this Project manager was that he was always diligent about controlling scope creep. Every time someone had a new idea he would let them know the implications. He didn't start discussions with "No, you can't have that," (a recipe for nasty conflicts) but he would always say "We can look at that but we have to do some analysis first. That's outside the scope we've already agreed on and we need to be sure of what impact it would have on our existing plan." So nobody was ever given a straight "no" but the project didn't turn into some horrific, never-ending death march.
The worst thing that happened was when an influential manager who was nothing directly to do with the project was given the specification documents to read. It wasn't a bad idea to get his opinion, he's an intelligent and experienced IT professional. But it was a terrible idea to show him the specs for the first time a week before we were planning to send the tender out to potential vendors.
You can't "un-ask" someone important (in the political sense) for their opinion just because their opinion becomes inconvenient. The end result of this was that the process of getting the Tender finalised to everyone's satisfaction and sent off kept dragging on. Because this was a totally unplanned event we had no way of knowing how long it would take to resolve and instead of lasting the week we'd allowed for, it took about 5 weeks. And every day we were thinking "maybe we'll be finished in another day or two."
I almost lost it at week 4 and was ready to go postal on my cow-orkers.
I'll finish with what was one of the best surprises of the project. At a critical point in the evaluation process, the project team had committed to the management steering committee to have a decision within two weeks - an aggressive timeline given the circumstances but one we were confident we could meet. The head of the steering committee (the second most senior manager in the entire company) had a look at our proposal and said:
"I don't think you're allowing yourselves enough time. This is a big decision and I'd rather it was done right than done quickly. I think you should spend an extra month on the evaluation and then come back to us."
This sort of common sense shouldn't be a surprise. But I don't remember the last time someone on the business side said, unsolicited, to an IT project team: "You should take more time to make sure this gets done right."
And now, because I'm a contractor, I'll be moving on. With my luck, the next place will be the polar opposite of this place - a madhouse where everything gets done wrong. At least it will provide a lot of blog material.
No comments:
Post a Comment