Archive for the ‘Project Management’ Category
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.
Certifiably mistaken: two wrong reasons for pursuing project management certification
Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified. There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.
My motivation for writing this post is a recent conversation I had with a colleague. It went like this:
“Do you think a PM certification is worth the effort?”
“Depends on what you want out of it,” I replied.
“Well I reckon it will make me a better project manager and help me stand out from the crowd .”
Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:
-
To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes as decreed by a particular certifying authority. These processes are easy to learn by reading a book or two. The “hard bits” of project management – negotiation, people skills, crisis management, conflict resolution, prioritisation, stakeholder management (I could go on and on but I’m sure you get my point) – are not, and cannot be, learnt through certification.
-
To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day.
Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology. The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognise jargon-laden bulldust when I hear it (which, unfortunately, is quite often).
In the end, formal knowledge is always useful. So, gaining a cert won’t hurt, but be sure you aren’t doing it for the wrong reasons.
Eight to Late 