By the end of project execution, Elm went from being a hero to zero. His team didn’t want to work with him, and many actually left the organization. The client stuck around till the project closed, but then ran away faster than Road Runner. Here’s a tragic story.
It all started off well and as expected Elm had carefully created the plans and a team eager to get the job done. The client satisfaction was rating was at an all time high of 5/5. His reputation as a project manager could not have been better. Project Execution kicked off and here’s how it panned out.
Problem 1: Crazy Client Stakeholder Demands
It was horrible. Within the second week, the client suddenly went on a two-week vacation. The communication plan did not have a backup and the fortnightly check point was missed. Meanwhile, when he got back apparently multiple requirements crept in. It was fascinating how the client claimed these requirements weren’t new and were actually documented. His proof, if that’s what you want to call it, was a vague sentence that could have meant anything. The sentence was:
Improve system performance
Now, you tell me. Based on this, do you really think it’s fair asking for 30% improvement during project execution? Nazareth tried his best to negotiate it down. But, the client stuck to his demand, after all it was documented. Ultimately, Nazereth had to accept this. Unfortunately, he now had to find a way to achieve it with the resources and budget that had been approved. Life was suddenly not very rosy.
Anyways, to avoid such issues further, Nazareth sat with the client and rephrased all vague requirements. Turns out Nazareth used the SMART framework to document them.
Image Credit: SXC
Problem 2: Even More Crazy Client Stakeholder Changing Requirements
The volatility of the client requirements did not stop. In every other check point, there were new requirements that were apparently new discoveries. In one instance, a couple of new and fairly complex features were introduced. Each feature had a number smaller features. To add to the complexity, there was a fair degree of interdependency between the features. The project management methodology adopted by Nazareth was just not suited for such a high degree of dynamic development. It was too late in the project to experiment with Agile methodologies, such as Feature Driven Development. He could have also benefited from prioritizing scope based on risk and value. Even though the client was paying for these additions, the deadline was fixed. Nazerath battled to get new resources on board. The ones he got, needed time for ramping up. This was turning out to be a nightmare on Elm’s street.
With the limited resources working into the wee hours, there was bound to be some friction and impatience creeping within the team.
Problem 3: Crazy Team Conflicts and Attrition
One of the worst things about project management problems is that the team gets to bear the brunt. And, this was no exception. The Project Execution phase was all about people working late and not maintaining a work–life balance. Personal growth and coaching activities only existed on paper. The team just worked and worked, trying to play catch-up. Everyone seemed to have a short fuse and it was common for team members to use Elm as a truce broker. More often than not, Elm favored the Compromise approach to resolving conflicts. With the entire team compromising, the team’s happiness was taking a knock and morale was at an all time low. Many team members chose to jump ship. When the project is in the Project Execution phase, retaining talent is a challenge; hiring talent is a greater challenge.
On retrospect, Nazareth was better of using a different approach to conflict resolution, such as problem-solving. He might have also focused on developing intrinsic and extrinsic motivation in the team.
Image Credit: SXC
Problem 4: Crazy Critical Path
With the project brimming with scope changes and scope creep, the critical path defined at the start of project execution kept changing. Pretty soon, Nazareth was too busy with stakeholder and scope management to worry about activities in the critical path. Apparently, in such a crisis situation he deemed all activities to have equal importance. It was a fire fighting situation and the fire was winning! Nazerath learned never to lose track of the activities in the critical path. Otherwise, schedule delays are bound to happen and you will face project management problems in the Project Execution phase.
With a little support from senior management, things did get better in the project and it was completed. However, with the trouble experienced in the Project Execution phase, it is not surprising the client ran away faster than Road Runner….beep! beep!