Scope: Clearly defined scope and risk avoidance mechanism is also very important. Project scope approval by client and sponsor is required and any change in the scope should be taken as a change request.
The first part of the post is a replication of a post at http://PMToolsThatWork.com/project-management-crisis-hurry-but-do-nothing/ . I will then offer my analysis in the second part.
Project Management Crisis? Hurry, But Do Nothing
[The original is at http://PMToolsThatWork.com/project-management-crisis-hurry-but-do-nothing/]
We had a crisis. Another project had an emergency so we were losing a significant portion of our engineering staff to go work on that project. We had to act now!
We were told to replan our project and to present a new project management tool schedule. No problem, we already had an alternate schedule ready. It was the schedule that had been rejected previously for the shorter one that was accepted. We adopted the previously rejected schedule and went on to deliver our product on time. One of our biggest customers told us that it was the first time in their memory that we had delivered a new product in the time frame we had promised it.
It was really fortunate we had a well developed schedule all ready to go. Actually, it was not fortunate, it was routine. Well, the part that was routine was that just about every project eventually had to respond to an emergency in another project trying to finish that caused newer projects to lose staff. The fortunate part was that we had tried to propose a schedule – one based upon objective data from just completed projects – but that schedule was rejected as too long. The humorous part was when we said we would use the previously rejected schedule, we also said it was ready to go and did not need to be updated. How could that be as we were months into the project? It was possible because that schedule already took into account the inevitable loss of staffing because it was based upon past actual project performance. (For more on performance based schedules see Get The Project Management Schedule Right!)
If we had used the initially rejected schedule then when the crisis occurred, and we lost staff, we would not have had a crisis. We could have just stayed on the same schedule and pressed on. Actually, we didn’t have a true crisis in any event. Since we didn’t truly need to replan, just use what was essentially the same schedule with adjusted milestones, there was little or no impact to any team. We just continued on course with the staff we had remaining.
The one big difference was that our project never had a crisis that then pulled staffing from the projects coming after ours. That probably helped explain why these later projects went on to receive recognition and awards for “flawless launches.” Prior to this, we never had any project anyone would have call a flawless product launch.
Objective and performance based planning can take the sting out of our typical crisis. When faced with an emergency we should be hearing ourselves say “no problem, we anticipated this possibility and have it covered.” This may ultimately help other projects to succeed as well.
MY Experience:
I have worked on projects that were delivered on time and also on projected that were not delivered on time or on budget. This has always been in my mind why some projects manage to meet the schedule while others don’t. This article made me to think and I came out with my own analysis. Some things that can create difference are
<!--[if !supportLists]-->1) <!--[endif]-->Planning & scheduling: The projects on which I have worked and which failed to meet the deadlines, were not because the team was not motivated or the requirements kept on changing but because the time required to complete the project (schedule) was flawed. The project estimates were given by a project lead who was working on another project and will not be working on this project. So the incentive to come up with the exact estimates was missing. So, who is estimating the project is very important. It is also important to involve the developers and testers in this process.
<!--[if !supportLists]-->2) <!--[endif]-->Communication: The client had no idea what was going on in the project and if there was any problem. The project managers were reluctant to talk to the client and explain the problems that the team was facing and when the client knew about it, it was too late. So communication is very important.
<!--[if !supportLists]-->3) <!--[endif]-->Planning the resources require: It is also very important to estimate the resources and skillset that are required to get the work done. In most of the projects, the main resources are moved to other new projects once the major functionalities are implemented. This means new resources getting added to the project, which leads to chaos.
Posts
