A friend pointed out that my last post seems to paint the picture of PM as simply effectively communicating project status. This isn't the picture I was going after. I know that there isn't just one thing a PM needs to do in order to be successful. A few things I can think of off the top of my head:
- Establish a network of people in the company, for support and information
- Understand the goals and objectives of the customer(s)
- Establish trust with key stakeholders (customers,bosses, project workers,...)
- Do the mandatory tasks (Sit in meetings, schedules, plans, statuses, meeting minutes...)
- Mediate disputes and drive people to make a decision
- Manage risk and issues
- Monitor budget and other key metrics that the customer(s) care about
- Sheild the workers from unnecessary busy work and political gyrations
- Understand the true state of the project and communicate it effecticely to all key stakeholders
In my opinion, this last one is the most important. Of course you have to do all the other things, but if you fail in the last one your job will be frustrating and probably unsuccessful. If I was reading this my first thought would be so what do you mean by the "true state of the project" and "communicate it effecticely to all key stakeholders". These seem awfully vague. Let me try to elaborate.
Lets assume for a bit that we had a crystal ball that knew all and would answer any question about our project we wanted to know. Stop salivating...assuming we were intelligent to ask the right questions we could determine the a good understanding of the current state of the project. In fact if we had enough time I bet we could get a complete picture of all work on the project. This is what I mean by true state of the project. Of course we don't have any crystal balls...try telling that to your customer. So what do we do. Well I think the answer is different for everyone. I like to make a mental map around which I put various bits of information from various sources. As time goes on and I find out the reliability of various sources I adjust my mental map to get a better understanding of what is going on. I never rely on just one source. There are tools I have seen that let you map information with links...I forget their name...but then I doubt I would ever use it. Others seem to have success using them though.
Now on to communicating it effecticely to all key stakeholders. Communication is an interesting thing. Different mediums work better in different situations. When you want to tell folks you are buying the first round I find email works just fine. When you want to tell some one they aren't meeting expectations I would never use email. In between it all depends. Email is great for simple questions and simple answers. It is great for reporting status to a group of people and making sure everyone that needs the basics gets them on a regualr basis. It isn't the best communciation tool for ALL communication though. Alistair Cockburn has written about the modes of communication (http://www.agilemodeling.com/essays/communication.htm). It is important to use communication effectively and efficiently. Relying on just one mode (i.e. email or meetings) is bound to result in less information than is necessary to do the job. Then again I don't know everything...so I might just be wrong.
Saturday, September 17, 2005
Sunday, September 4, 2005
What is a project manager's true responsibility?
The PMBOK states this: "Project Management is the application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stockholder needs and expectations from a project."So I guess coding is project management (PM) as well as design, analysis, architecting and a host of other non-management jobs. What isn't PM by this definition?
As you can tell I don't like it, but it is too easy to criticize and often difficult to be constructive. I like a good challenge. In my 14 years in the "software industry" (meaning jobs that involved writing software...I am not sure what other people mean by it) I have seen a wide variety of management. One type of PM, lets call him A, bossed around all the people on the project and acted in a way that everyone hated/feared him and the job got done...not well, but got done. Another type of PM, lets call him Z, provides status, updates the schedule, hold meetings and keeps the minutes, fills out forms, and other menial tasks. Of course these are two extremes and most PMs fall in between A and Z.
What makes PMing interesting to me is that the culture under which the PM operates has direct influence and control on how best to do the job. Take a type A PM and place him in an environment in which he has no political power and he will be frustrated and probably will quit. Take a type Z and place them in a position with ultimate authority and control and the same will probably happen to them. So the question is, does the environment/culture of an organization select in a Darwinian way the PMs that last? Now take into account the churn in today's job market, in which people leave jobs all the time and never stick around for long. One environment won't have any one group of PMs long enough to do natural selection...so what determines a PM success?
I don't have any answer to that question...not yet at least ;-) I do have an opinion on how a PM might be successful in all but the most oppressive environments. To me the key is information. A PM that knows little about what is really going on in their project is going to struggle no matter what tools/techniques they learn in PM camp. A PM that knows the most about the true state of their project, knows the tools (i.e. EVM, Schedule, TOC) and can use the tools in ways that show the state of the project with proper understanding their audience will be successful.
Some of you may be wondering what I mean by "show the state of the project with proper understanding their audience." I like using examples to illustrate my points. Lets take a situation in which the PM finds out that a mandated date will not be met and scope must be moved. Wrong ways to deal with this are: to hide it for fear of looking bad, to make the project immediately red and shoot an email up the chain. A proper way is to have a all forms of communication in synch that show the dates may be in jeopardy (like raising a risk, tightening the schedule so the date has only a few days of slack, bringing up the issue in meeting with people of authority...) Hopefully you get the point. What makes this difficult is finding out ASAP that dates will be slipping and putting that information in a sensible way in all project documentation. Enough for now....
As you can tell I don't like it, but it is too easy to criticize and often difficult to be constructive. I like a good challenge. In my 14 years in the "software industry" (meaning jobs that involved writing software...I am not sure what other people mean by it) I have seen a wide variety of management. One type of PM, lets call him A, bossed around all the people on the project and acted in a way that everyone hated/feared him and the job got done...not well, but got done. Another type of PM, lets call him Z, provides status, updates the schedule, hold meetings and keeps the minutes, fills out forms, and other menial tasks. Of course these are two extremes and most PMs fall in between A and Z.
What makes PMing interesting to me is that the culture under which the PM operates has direct influence and control on how best to do the job. Take a type A PM and place him in an environment in which he has no political power and he will be frustrated and probably will quit. Take a type Z and place them in a position with ultimate authority and control and the same will probably happen to them. So the question is, does the environment/culture of an organization select in a Darwinian way the PMs that last? Now take into account the churn in today's job market, in which people leave jobs all the time and never stick around for long. One environment won't have any one group of PMs long enough to do natural selection...so what determines a PM success?
I don't have any answer to that question...not yet at least ;-) I do have an opinion on how a PM might be successful in all but the most oppressive environments. To me the key is information. A PM that knows little about what is really going on in their project is going to struggle no matter what tools/techniques they learn in PM camp. A PM that knows the most about the true state of their project, knows the tools (i.e. EVM, Schedule, TOC) and can use the tools in ways that show the state of the project with proper understanding their audience will be successful.
Some of you may be wondering what I mean by "show the state of the project with proper understanding their audience." I like using examples to illustrate my points. Lets take a situation in which the PM finds out that a mandated date will not be met and scope must be moved. Wrong ways to deal with this are: to hide it for fear of looking bad, to make the project immediately red and shoot an email up the chain. A proper way is to have a all forms of communication in synch that show the dates may be in jeopardy (like raising a risk, tightening the schedule so the date has only a few days of slack, bringing up the issue in meeting with people of authority...) Hopefully you get the point. What makes this difficult is finding out ASAP that dates will be slipping and putting that information in a sensible way in all project documentation. Enough for now....
Subscribe to:
Posts (Atom)