Archive for March 2008
Dr. Do-little
So you’re the hardworking techie who’s just been promoted to project manager. Congratulations and all that, of course, but I’m sure you realise that your new job has very little to do with your old one. Chalk and cheese or caramel and chilli are comparisons that come to mind.
“What’s that you say? You didn’t know?”
You shake your head. “They didn’t tell me,” you reply.
“Well, of course they didn’t,” I respond, and rush back home to continue this piece…
The transition from a techie to a project manager can be a difficult one. The biggest and hardest adjustment is this: project managers are responsible for a whole lot of stuff that they don’t do themselves. The best way to explain what I mean is through my own experience.
As a project manager I’m responsible for the success of a project although I’m not directly involved in the nuts-and-bolts of its implementation. I depend on the team for the latter. In effect, as far as technical work is concerned, I’m Dr. Do-little – I do very little (if any) coding or design.
So what do I do? The facetious answer is: I manage projects. To most people who don’t know what project managers do, this sounds like a Very Important Job. One in which I get to order people around, tell them what needs to be done and by when. The reality, as all experienced PMs know, couldn’t be more different. The following paragraphs should serve to illustrate just how so.
A lot of my time and effort is spent in ensuring that others can do their work unimpeded by obstacles of any kind – political, physical, communication-related or whatever. (Ah, I see that look of disbelief on your face now – but believe you me, it’s true.) Some examples of this include: following up with vendors; making sure that a developer has the stuff he needs to proceed with cutting code; resolving misunderstandings between developers or between developers and users, and so on.
Another aspect of a PM’s job is negotiation. Sometimes it seems that I spend entire days negotiating – with team members (cajoling… no pleading… with them to get the module finished by Friday, as they’d promised) or with vendors (to try and get them to ship the hardware that was to have arrived yesterday) etc.
Finally, because I’ll be the first one out of the door if the project fails, it is in my interest to ensure things are on track. Here too, things aren’t black and white (or even red, amber and green as those wonderful traffic light status reports show) – they’re in several hundred fine shades of gray. A task can be late but still be under control. Even more paradoxically, it could be early but getting out of control. There’s way more to keeping projects on track than is detailed in status reports. You have to have an eye out for potential trouble, or project banana skins as I’ve called them in an earlier piece. For example, a task could have finished early because the developer wanted to finish it up before resigning – things are about to spin out of control and you’re not yet aware of it.
I may be Dr. Do-little in that I don’t cut code or do design. And although I don’t to a Very Important Job, I do a reasonably important one. Without my efforts, the project may well fail. So, to the novice project manager I say: welcome to the infuriating and frustrating world of project management. Remember, in the end – when your projects are successful – it can also be very rewarding.
Two project managers, one project
Some projects are run by more than one project manager (PM). The most common manifestation of this is on projects that have a clear distinction between business and technical responsibilities. In such cases it is logical, not to mention efficient, to divide these responsibilities between two PMs – one from the business and the other from the tech side. At first sight this arrangement appears to violate one of Henri Fayol’s principles of management: unity of command. Further, with two people running the show, there’s an increased potential for confusion regarding roles and responsibilities. One is, therefore, justified in thinking that two PMs on a project implies trouble (or should I say, double trouble?). However, from experience I can say that such an arrangement works well, providing some simple and fairly obvious guidelines are followed. So, if you have the double-edged fortune of being one half of a project management team, here’s some unsolicited advice from someone who has been there:
-
Develop a good rapport with your counterpart: As I’ve written about elsewhere, communication is the basis of good project management. It is easier (and a lot more fun) to communicate with someone you like and get along with. Hence this is number one in my list: get to know your counterpart, socially if possible. Building a rapport (even better, a friendship) will help ease the inevitable tensions that crop up when the project is underway.
-
Divide all responsibilities: This is almost as important; responsibilities must be completely partitioned between the two PMs. This means:
-
all responsibilities are assigned to a PM – i.e. no unassigned responsibilities and,
-
no overlap – i.e. each responsibility assigned to one PM only (never both!).
Note that this point addresses the apparent violation of principle of the unity of command
-
-
Help each other: Yes, despite what I’ve said in point two, you will occasionally need to help each other. This could, for instance, be by helping out with hard tasks or covering for your counterpart while she’s away. Remember, you never know when you’ll need help yourself. So, offer assistance, if only for selfish reasons!
-
…but don’t tread on each other’s toes: After all is said and done, you and your counterpart are individuals. Respect that by not barging into each others territory. There’s a difference between offering help and interfering – though, some people seem to find it hard to make this distinction. As an example, don’t offer unsolicited advice (unlike me!), unless you’re sure it will be taken in the right spirit.
-
Make joint presentations at sponsor meetings: You and your counterpart are a leadership team. Giving joint presentations to sponsors reinforces the notion that both of you are jointly responsible for the project.
Running a project with another person can be an enjoyable experience. Yes, each of you will have to adjust to the other’s management style and quirks. However, you’ll both find that this effort is repaid many times over through the support and assistance you receive from each other.
Solutions in search of problems
History repeats itself; first as tragedy, then as farce – Karl Marx.
Although Mr. Marx didn’t say anything about repetitions beyond the second, one can safely assume he would have considered them beyond farcical. Yet, in the world of corporate IT, we’re continually faced with the following repeat offender: the solution in search of a problem (or SSP). I should define the term before I go on – a SSP is a project that has been sanctioned without any regard to the actual value or utility of the deliverables. This post is aimed at assisting project managers in identifying a SSP, so that they can take appropriate action when confronted with one. This basically amounts to of the following: sidestep it (i.e. duck it somehow), step down (i.e. resign) or suffer (i.e. accept the responsibility of managing the project and, well, suffer).
So, here we go then, seven deadly signs of SSPs:
-
No one knows what the project is about. Everyone talks about it, but no one seems to know why it is being done.
-
It’s all about technology or standards (SOA anyone?), not the business. The justifications on offer for the project are seasoned with phrases like “best practice” or “state of the art technology”; terms that have more to do with technology than business need.
-
There’s a committee responsible for implementation (often with a global reach). You’ve got to love global committees with their 10,000 metre view of ground level realities. Most recommendations that emerge from these are either so general as to be unusable, or worse – patently incorrect.
-
Since no one knows what it’s about, the project is more about the means than the end. Put another way, project management processes or process improvement methodologies in their full bureaucratic glory will reign supreme. Be sure that you’ve filled in all the right forms and have all the right signatures, else all hell will break loose.
-
No one is aware of a successful implementation: The global committee has little to show for their three years of the project, barring the pilot they did two years and nine months ago, involving 1.5 users.
-
The project will replace a perfectly good existing solution: You have a good system in place? Don’t worry, the SSP will replace your tried and tested solution with one that will give your staff many hours of debugging fun, and the gray hairs to prove it.
-
And finally: these projects often originate in the upper reaches of the corporate hierarchy, where the connection with ground level reality is somewhat tenuous. Corporate mandated projects have a fair chance of being SSPs.
So, it isn’t hard to spot an SSP. What do you do if confronted with one? Well, that’s up to you. As mentioned earlier, you have three options: sidestep, step down or suffer. The choice is yours.
Eight to Late 