I have been in the role of project manager for about 5 months now. One phrase I find myself repeating is "So, do you have a date when that will be done..." I used to hate to have to provide dates for things I barely understood. I felt that anyone who asked was obviously clueless. Now I find myself on the other side of this question...what has changed? One thing I have found is that if no date is asked for then the chance of it getting done is usually extremely low...close to ZERO. It seems most people aren't very organized and their job stretches them too thin. They get done what they think is most important. When someone reminds them of a date that is coming up or has just passed and and a task they promised to have done they typically up the priority of the given task. Why is this mindlessness needed?
For one thing we don't trust one another. My wife asks me to feed the kids. 15 minutes later she asks "Have you fed the kids?" This is with someone who trusts you. Take this to the office and know one trusts anyone. Everyone knows all of us are playing games of trying to look good to those that matter so we can get that promotion, that raise, that praise...you name it. The game isn't about how do WE win, but how do I win. This type of culture makes getting things done very difficult. You wind up having one meeting to get them to agree to a task and a date. Another meeting to get status (sometimes this even occurs weekly) then a final meeting to go over what they did. It isn't rare that in a given week I spend more time in meetings than getting any work done. The project I am currently on, we have more people in an oversight role that in a doer role. I wonder if we could calculate a performer to oversight ratio for projects. Then map that to success....hmm...it might be interesting.
One thing Agile projects try to do is limit no-win situations of date promising. The date is either the end of this sprint or it isn't. The focus then becomes what can the team deliver this sprint. We don't have a number of meetings with various stakeholders, each with their priorities and action items and dates. We have ONE backlog and ONE team. The team works the backlog and NOTHING ELSE. A stakeholder wants something...it goes on the backlog and gets prioritized along with ALL the other requests. None of this back room dealing junk where Bob gets his stuff this week, because we didn't promise Tim his stuff till next week and poor Jim didn't ask for a date so he can just wait. Besides Bob is always calling me and I want him off my back.
With Agile, we put all the cards on the table with all the stakeholders. Let the customer decide what the relevant priority is between Bob, Tim and Jim. Let the developers do the work and stop playing politics. Agile practices allow progress to be made because the rules are simple and well communicated. Anyone who wants work is told the same story. It isn't different because of who the asker is or the relationship to the answerer. It is always: Come to the planning meeting and we'll see where the work lands. The development team is only responsible for delivering what the owners have prioritized. When the simple rules are followed it works well. When the rules are tinkered with to soft peddle the approach. It works less and less well. In some cases it works worse that before. All I want to know is when will you be done?
Monday, December 12, 2005
Saturday, September 17, 2005
Typical Oversimplification
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.
- 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.
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....
Saturday, July 16, 2005
Project management
I just quit my job at the Consortium and I start a new job Monday as a project manager. Coincidentally I had just bought "The Art of Project Management" by Scott Berkun based on a review by the SD newsletter, SD People and Projects. I'm almost half way and I disappointed so far. Mr. Berkun seems to have some good ideas, but I don't think he is truly aware of what I would call current best ideas in project management (namely TOC and Agile). He has mentioned Agile a few times, but he seems not to truly get it. Of course I may be judging him early, I still have 270 pages to go.
I think software has unique qualities that other mediums (i.e. concrete & steel) do not. The major difference is flexibility to change it's behavior in short order. Therefore software project management needs to take that uniqueness into account. Secondly, lean thinking has shown us that rapid time to market with best in class quality is achievable by rethinking the nature of production. I think lean thinking and agile can make this happen for software, we are just waiting for the Toyota of the software industry to show us how.
I think software has unique qualities that other mediums (i.e. concrete & steel) do not. The major difference is flexibility to change it's behavior in short order. Therefore software project management needs to take that uniqueness into account. Secondly, lean thinking has shown us that rapid time to market with best in class quality is achievable by rethinking the nature of production. I think lean thinking and agile can make this happen for software, we are just waiting for the Toyota of the software industry to show us how.
Wednesday, May 11, 2005
Software quality
Software quality is a tricky thing. There are many schools of thought. The formal methods camp says the only way to get quality software is to formally spec it and test against the spec using some formal testing method such as model-based testing. The agile camp says that the developers have to build quality in on a day by day basis based on feedback from the customer. There are problems with both approaches.
The formal methods approach assumes you can specify things formally for all systems. There are some systems where formal specs are impossible and there are a large number of systems in which formal specs are too expensive (most all IT applications come to mind).
The agile approach assumes the customer can tell when they get something they want. In some agile methods it is encouraged that the customer write the acceptance tests. This will work for some systems, but there are a large number of systems where this will not do (banking and pacemakers come to mind)
Is there a middle ground? I think there are ways to combine some of the formal methods approaches with the agile approaches for the subset that require it. Lets face it quality is in the mind of the buyer, not some objective thing (although there are people who think defects/LOC is meaningful. Just to dismiss this think of two fictional word processors. Both have the same LOC count and have 1 defect each. The first word processor's bug is that it crashes just before it saves. The second just after. Which has higher quality. Only an idiot or zealot, is there a difference, would say neither.
I say where it is warranted (two examples are when the cost of a bug is more than system development, the past has shown that the system needs better testing) you can make the acceptance tests in an agile approach use model-based testing. I haven't seen it work, so I am skeptical, but hopeful.
The formal methods approach assumes you can specify things formally for all systems. There are some systems where formal specs are impossible and there are a large number of systems in which formal specs are too expensive (most all IT applications come to mind).
The agile approach assumes the customer can tell when they get something they want. In some agile methods it is encouraged that the customer write the acceptance tests. This will work for some systems, but there are a large number of systems where this will not do (banking and pacemakers come to mind)
Is there a middle ground? I think there are ways to combine some of the formal methods approaches with the agile approaches for the subset that require it. Lets face it quality is in the mind of the buyer, not some objective thing (although there are people who think defects/LOC is meaningful. Just to dismiss this think of two fictional word processors. Both have the same LOC count and have 1 defect each. The first word processor's bug is that it crashes just before it saves. The second just after. Which has higher quality. Only an idiot or zealot, is there a difference, would say neither.
I say where it is warranted (two examples are when the cost of a bug is more than system development, the past has shown that the system needs better testing) you can make the acceptance tests in an agile approach use model-based testing. I haven't seen it work, so I am skeptical, but hopeful.
Subscribe to:
Posts (Atom)