Project Manager has become a valuable title and as with all such things lots of people want that title whether they are qualified or not. Credentials are definitely one way to tell if a person is qualified to be a Project Manager. There are now degree programs at major universities and there is the Project Management Institute certification (PMP) that can help identify the committed professionals.
However you as I have known great Project Managers who don't have any of these credentials and we have perhaps run across a number of persons with the credentials who are ineffective project managers.
So what makes a project manager good?
One point of view is provided here: http://www.ithealthcareblog.com/archives/12#comments by Susan McClafferty.
What do you think?
Monday, December 24, 2007
Friday, December 21, 2007
Smart Tips to keep your project on track
Baseline magazine has an interesting article on effective project management called "8 Ways To Save Your Next Project" by Elizabeth Bennett. The article is worth a complete read and can be found here: http://www.baselinemag.com/article2/0,1540,2235679,00.asp
The summary is Project Management is an exercise in active and proactive management. What do you think?
The summary is Project Management is an exercise in active and proactive management. What do you think?
Thursday, December 20, 2007
Is there such a thing as too much staffing?
Many of us learn early in our lives all things, even good things, must be taken in moderation. Staffing for projects is one such good thing. I am sure we have all experienced projects that are run with too little resources. We know the normal symptoms of a project that is resource starved -- delays, quality and morale issues and perhaps failure.
However what would happen with a project that has too many resources? Would Brooks's law, which says that adding manpower to a software project that is behind schedule will delay it further, apply? Lets further complicate the issue by asking what would happen if the project begins with too many people to begin with, i.e. people are not being added late.
There are two common explanations for Brooks's law (http://wen.wikipedia.org/wiki/Brooks%27s_law) :
1. New staff take time and resources to ramp-up and are therefore not immediately productive and distract the experienced resources.
2. Communication overhead increases as we add more people. The number of different communication channels go up a square of the number of people.
However when the project is new problem #1 (ramp up time) is not a large contributor. However problem #2 -- communication overhead is a killer.
There is a 3rd problem that arises in the most extreme cases over-staffing; when the number of resources available exceeds the amount of work that can be performed at that time. When this happens in a manufacturing process we have idle machines. Machines are not aware of being idle and do not react to their idleness. People tend to be very aware of being idle. Idle machines might be ignored or eventually redeployed, Idle people usually become unemployed. So people start manufacturing work to stop being idle.
Work manufacturing can happen in two broad categories: scope creep and process creep. Scope creep usually refers to uncontrolled changes to a project's scope, but I am using it to mean changes that are not necessary to deliver the business case for this project.
Process creep is like scope creep except the changes are not made in deliverables of the project but the steps used to create the deliverables and manage the project. Of the two process creep is the more insidious because it is much harder to detect and control.
However what would happen with a project that has too many resources? Would Brooks's law, which says that adding manpower to a software project that is behind schedule will delay it further, apply? Lets further complicate the issue by asking what would happen if the project begins with too many people to begin with, i.e. people are not being added late.
There are two common explanations for Brooks's law (http://wen.wikipedia.org/wiki/Brooks%27s_law) :
1. New staff take time and resources to ramp-up and are therefore not immediately productive and distract the experienced resources.
2. Communication overhead increases as we add more people. The number of different communication channels go up a square of the number of people.
However when the project is new problem #1 (ramp up time) is not a large contributor. However problem #2 -- communication overhead is a killer.
There is a 3rd problem that arises in the most extreme cases over-staffing; when the number of resources available exceeds the amount of work that can be performed at that time. When this happens in a manufacturing process we have idle machines. Machines are not aware of being idle and do not react to their idleness. People tend to be very aware of being idle. Idle machines might be ignored or eventually redeployed, Idle people usually become unemployed. So people start manufacturing work to stop being idle.
Work manufacturing can happen in two broad categories: scope creep and process creep. Scope creep usually refers to uncontrolled changes to a project's scope, but I am using it to mean changes that are not necessary to deliver the business case for this project.
Process creep is like scope creep except the changes are not made in deliverables of the project but the steps used to create the deliverables and manage the project. Of the two process creep is the more insidious because it is much harder to detect and control.
Friday, August 04, 2006
Good project gone bad
So you have a project plan, you have contingency plans, you have a methodology, you have a PMO and your project still goes to hell in a hand basket. What do you do?
There are simple options that are not really the purview of Project Management but need to be acknowledged first. Option 1 is ignore it. There are a lot of variants of "ignore it" which include "assign blame", "I am a victim" and "this is the way all projects of this kind go" etc.
The other simple option is to disengage. Disengagement can occur in a number of different ways which can range from people leaving the team to people withdrawing ideas and effort short of leaving the team.
If you are the PM or responsible leader for this project and cannot personally follow a simple option, it will still be important to remember that others have simple options.
If you are responsible for a turn-around strategy for a project:
Step 1: Recognize the situation requires a turn-around
Step 2: Assess the current state
Step 3: Define the goal state and how the current state deviates from goal state.
Step 4: Define a turn-around plan. Check if the project is still worth saving.
Step 5: Get buy-in
Step 6: Start the new project.
There are simple options that are not really the purview of Project Management but need to be acknowledged first. Option 1 is ignore it. There are a lot of variants of "ignore it" which include "assign blame", "I am a victim" and "this is the way all projects of this kind go" etc.
The other simple option is to disengage. Disengagement can occur in a number of different ways which can range from people leaving the team to people withdrawing ideas and effort short of leaving the team.
If you are the PM or responsible leader for this project and cannot personally follow a simple option, it will still be important to remember that others have simple options.
If you are responsible for a turn-around strategy for a project:
Step 1: Recognize the situation requires a turn-around
Step 2: Assess the current state
Step 3: Define the goal state and how the current state deviates from goal state.
Step 4: Define a turn-around plan. Check if the project is still worth saving.
Step 5: Get buy-in
Step 6: Start the new project.
Labels:
Project Management,
troubled projects,
turnarounds
Thursday, July 14, 2005
Contingency Planning
Contingency Planning is like getting enough exercise and eating right. Most of us know we should do it; most of us don't do enough of it. I recently had an experience that reminded us the truth in the old proverb about the best laid plans of men and mice. We moved across the USA. In 2005 this should not be an adventure. We are good project managers. We created a realistic plan. We picked (or appeared to) a good team. We communicated the plan to the team and got agreement. We setup monitoring metrics and worked out a tracking/status reporting system...
Luckily we also setup contingency plans. We did it tongue in cheek. We did not believe people like us would need contingency plans. Contigency plans are for poor plans. We are not mediocre planners, we are excellent planners. Our plans were realistic, bought-in, well staffed, properly monitored. Well bucko we learned a valuable lesson. Our excellent plan failed quickly. Two very different critical partners failed and could not deliver on time. We had to scramble to quickly replace them. Some of the delayed tasks almost impacted the critical path and could have caused significant financial issues.
We were again reminded of two verities about project management. Whether you have a success or a disaster depends on the quality of your people, especially your leadership. Pay attention to your contingency plans, they may save your ass.
Well the story has an happy ending. We learned some critical lessons and our critical path was not impacted. There was a lot of inconvenience, some anxious days and many many phone calls. But we also learnt some great things about our support organization, while we would not want to go through this experience again, we walked away much more confident in our capabilities as project managers.
The take home value:
* Investing in developing good contingency plans is very important
* Once you have developed your contingency plans make sure they are well understoond and bought-in. Every one involved needs to know when they will be invoked and what they will be called to do.
When a contingency plan is invoked it means that there is going to be pain, but done correctly it should be much less pain compared to a project failure.
Luckily we also setup contingency plans. We did it tongue in cheek. We did not believe people like us would need contingency plans. Contigency plans are for poor plans. We are not mediocre planners, we are excellent planners. Our plans were realistic, bought-in, well staffed, properly monitored. Well bucko we learned a valuable lesson. Our excellent plan failed quickly. Two very different critical partners failed and could not deliver on time. We had to scramble to quickly replace them. Some of the delayed tasks almost impacted the critical path and could have caused significant financial issues.
We were again reminded of two verities about project management. Whether you have a success or a disaster depends on the quality of your people, especially your leadership. Pay attention to your contingency plans, they may save your ass.
Well the story has an happy ending. We learned some critical lessons and our critical path was not impacted. There was a lot of inconvenience, some anxious days and many many phone calls. But we also learnt some great things about our support organization, while we would not want to go through this experience again, we walked away much more confident in our capabilities as project managers.
The take home value:
* Investing in developing good contingency plans is very important
* Once you have developed your contingency plans make sure they are well understoond and bought-in. Every one involved needs to know when they will be invoked and what they will be called to do.
When a contingency plan is invoked it means that there is going to be pain, but done correctly it should be much less pain compared to a project failure.
Thursday, June 02, 2005
What is a project?
Before we get too far with our discussions about project management we need to come to a common useful definition of a project. A quick Google search for the definition of the word project brought back a number of useful definitions and some interesting ones...
Look at the wonderful range of definitions and also the number of different organizations that have felt the need to document a definition.
Almost every university teaches something about projects...no surprise. It appears in an encyclopedia...big duh! But check it out people in the Cathedral building business are talking about it. So is the US Government. There were definitions from public schools, service organizations, state governments. This is important stuff...check it out.
- a planned undertaking from www.cogsci.princeton.edu/cgi-bin/webwn2.1
- A project is a temporary endeavor undertaken to create a unique product or service. Temporary means that the project has an end date. Unique means that the project's end result is different than the results of other functions of the organization. From en.wikipedia.org/wiki/Project {EDITOR'S NOTE: What a wonderful definition}
- A complex assignment involving more than one type of activity and production. Projects can take a variety of forms, some examples are a mural construction, a shared service project, or other collaborative or individual effort. From www.angelfire.com/wa2/buildingcathedrals/measuringsuccess.html
- A structured undertaking (often involving considerable money, personnel and equipment) of limited duration that is developed through various bureaucratic, analytical, and approval processes in order to achieve a tangible objective (eg, a school construction project, an adult literacy project). A project should be considered as one of several types of activities that contribute to a given result or set of results. (See Activity.)
www.usaid.gov/policy/budget/cbj2004/glossary.html
Look at the wonderful range of definitions and also the number of different organizations that have felt the need to document a definition.
Almost every university teaches something about projects...no surprise. It appears in an encyclopedia...big duh! But check it out people in the Cathedral building business are talking about it. So is the US Government. There were definitions from public schools, service organizations, state governments. This is important stuff...check it out.
Wednesday, June 01, 2005
A
Good evening. I have started this blog to begin a discussion regarding project management. Specifically project management on the large scale.
Project Management is important not just because every one does it all the time. It is important because when done well it adds a lot of value to people, organizations, society and mankind. Done poorly it provides interesting news headlines.
So what makes Project Management hard? After all every one does it. Just like that other thing every one does. Moms do it. Dads do it too...but only grudgingly. Business people do it. Bosses do it and so do the subordinates. Hospitals do it. Churches do it. Insurance companies do it. Manufacturing companies do it. Hollywood does it. Politicians are masters at it. They get a lot of practice doing it.
However who can remember a large (multi - million, disciplinary, year, system) project that came in on budget and on schedule. How about two in a row?
Project Management is important not just because every one does it all the time. It is important because when done well it adds a lot of value to people, organizations, society and mankind. Done poorly it provides interesting news headlines.
So what makes Project Management hard? After all every one does it. Just like that other thing every one does. Moms do it. Dads do it too...but only grudgingly. Business people do it. Bosses do it and so do the subordinates. Hospitals do it. Churches do it. Insurance companies do it. Manufacturing companies do it. Hollywood does it. Politicians are masters at it. They get a lot of practice doing it.
However who can remember a large (multi - million, disciplinary, year, system) project that came in on budget and on schedule. How about two in a row?
Subscribe to:
Posts (Atom)