Monitoring and controlling is an ongoing process that should occur in tandem with execution. Supporting this assertion about the integral relationship between monitoring and controlling and execution is Carnegie Mellon University’s Planning and Project Management Office, which provides the following description of project execution:
The Execution Phase is critical to a project’s success and while the PM or Project Lead works with the team to perform the work of the project as planned, the progress of the team must also be monitored and controlled.
In my experience, the unfortunate reality is that project execution is monitored in less founded manners that result in reactive activity such as workarounds. Additionally, insufficient monitoring has entangled me in face-to-face interactions that were strained by uncomfortable exchanges. For software development, monitoring and controlling execution is built into the develop and test cycle. For example, you write code (execute); then, you test the code (monitoring). The control aspect is when you or someone else checks your code’s output against specified constraints. When all is good, you move on to the next coding module. This execute-monitor-control process quickly becomes second nature and an expectation. Consequently, when I work on a project outside of software development, I still expect to work within the execute-monitor-control framework. This expectation, however, has been the root of more than one unpleasant situation when my expectancies clashed with actuality.
Back in the mid-90s, I was brought into a project as a technical writer that was in its latter stages of execution. In fact, product release was about a month away. The principle technical writer left the country abruptly due to an HB1 visa requirement, and I was quickly hired to complete her work on a user’s guide. The product was a major release of the company’s flagship software, which I will call IDE. I had been working on the IDE user’s guide for several days, and I ran into much difficulty in getting the IDE to work properly, which hindered my ability to complete the user’s guide. At the first project team meeting I attended, I found myself in a very awkward situation, which I attribute to deficient project monitoring. The team members were ask to report on their status and progress, and everyone before me reported favorable status or progress. When my turn came up, I mentioned that I could not get the product to work successfully, and that it ‘crashed’ frequently. This news caused a discernible vexation with the project manager and other team members. One team member immediately addressed the lead software engineer with the question, “How can we be so close to release and still have unstable code?” The project manager quickly curbed discussion on this “bombshell” and moved on to the next team member.
Later that day, I was approached by my manager and was given a reprimand for making negative comments about the product in an open forum. Apparently, my comments reached the VP of Engineering who was not pleased with the news that the IDE was unstable. I also discovered that the project manager, who was not a member of the software engineering group, was also unaware of the software’s issues. Besides the adverse effect poor monitoring causes a project’s deliverable, this incident also demonstrates how risk events can cascade into undermining moral and confidence. The breakdown in communication management placed me, the project manager, and the lead software engineer in very uncomfortable situations. The lead software engineer was ordered to resolve the problems I was experiencing with the IDE, but he was not successful, and he instructed me to suspend work on the user’s guide until further notice. I was sure that the company planned terminate my contract. Fortunately, the company chose to keep me on, but I was reassigned to a different project. It’s important to remember that risk events occurring during execution affect more than the product, service, or schedule; people are affected too.
I want to wrap up with discussing an activity that is so common place that I’ve always considered it to be normal practice: workarounds. Until taking IS 445, I have never thought to consider workarounds as a deviation from best practice. Admittedly, workarounds have been my go to solution to deal with unexpected events that impact a project. After becoming more aware of risk management and going through the exercise of planning for risks, however, my perspective about workarounds has reversed. The workaround is usually seen as some creative or ingenious solution to an unexpected event. Dependence on workarounds is in fact a high impact risk because having that creative or ingenious individual available when needed is not guaranteed. Consequently, having a risk management plan in place to mitigate negative risk events eliminates the uncertainty of finding someone that can come up with an ad hoc solution. Moving forward, I plan to have less dependence on workarounds in favor of risk management procedures that can be reliably monitored and controlled.