Relatively speaking, I think execution gets more credit and accolades than it deserves. Execution should be building something according to plan, and it should not be considered synonymous with The Project. For the majority of companies I have worked for, there is a perception that just getting that finished product or service indicates good execution. But considering that many companies go over budget, over time, or out of scope in creating that product or service, equating product completion with good execution, I think, is an illusion.
Execution is implementing your work breakdown structure or WBS and properly managing the resources required to get the project tasks done. When you examine the activities that produced your project’s deliverable, you should encounter one or more of the following execution processes: project integration management, project quality management, project human resources management, project communications management, project stakeholder management, and project procurement management. These are not periphery activities; these are execution tasks that you must actively perform for a project. If a generous subset the aforementioned activities are not part of your project’s execution, you will fail to notice risk events that negatively impact your project. Of the processes related to execution, I think poor communications and stakeholder management are at the root of the majority of project difficulties.
Weak communication and stakeholder management also hindered my execution efforts on the Milconn project. Because my e-mail requests for information or feedback were mostly ignored, costly site visits had to be added to the schedule. Also during execution, poor stakeholder engagement allowed a groupthink situation to impede my progress. Whether in a project team meeting or meeting with team members individually, team members expressed the belief that the goal of the project was not realistic or attainable. Their conclusion, I eventually learned, came about because many of the team members had in the past made attempts to “computerize” their data tracking and reporting process without success. Consequently, lengthy discussions resulted to explain and assure the team that the technology could achieve the project’s goal. I also discovered that the pessimism caused some individuals to withhold key information about their processes that impeded my progress in implementing the application. Ultimately, the project manager recognized this groupthink issue and resolved it, but still, this issue resulted in a measurable cost to the project in lost time.
It should now be apparent that the Milconn project wasn’t going to succeed, and it didn’t. Further delays caused the budget to fully deplete, and consequently, the project was terminated. Before moving on from the Milconn topic, I want to point out the final risk event that occurred because it further demonstrates how poor communication and stakeholder management impairs a project. About six weeks into execution and during a project team meeting, a new project manager was announced for the project. This was a surprise to me and to most of the project team. Without any discussion with any of the project team members, the new project manager made unilateral decisions that affected scope. The changes caused further delays that quickly absorbed the remaining budget.
To avoid the negative impact of mismanaged execution such as those negative events that affected Milconn, you need more than a well defined set of rules to carry out your plan; you require competent leadership to execute the plan and to monitor and control the project resources.
Next: Monitoring and Controlling