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....
No comments:
Post a Comment