Controlling

Once a Project Manager has built a plan, as elements inevitably change over the course of the project, they have to control the variables involved in order to stay within the Triple Constraint of time, cost, and quality.

In my experience, the focus of control is usually centered around the project's scope and risk because these two essential elements have the greatest impact on time, cost, and quality, which are the key concerns of all project managers. If the scope increases, the time required will normally increase, and there is a risk of diminished quality.

Scope creep is often cited as the root cause of many project delays and failures. This is when the remit of what the project must deliver changes over the course of the project, often without the necessary adjustments to time, cost, and quality constraints and expectations.

Scope creep itself is often caused by an unrealistic expectation of having all of the knowledge and business requirements upfront. Since this is very difficult to achieve, it's natural that the scope is changed throughout the project life cycle, causing rework at various stages, which requires more effort and time.

The role of a Project Manager is to control this as much as possible. It would be equally unrealistic to expect a Project Manager to prevent any scope creep, as there will be legitimate reasons for scope changes. The key is to keep this to a manageable level, with the agreement of the customer.

It's important to appreciate that the customer is also learning throughout the process. Therefore, it is natural and to be expected that, as the project progresses, requirements evolve due to the clarity of understanding, or a genuine external business change such as pricing updates or even company mergers and acquisitions.

There may also be legitimate technology-led reasons for scope changes. For example, if the project is to replatform an application and soon after starting the project, a new version of the database management system is released that contains functionality and fixes that you would otherwise have to patch manually, then it would be a valid discussion and decision point to increase the scope of the project to include a database upgrade.

When the scope increases, the amount of development and testing work almost always increases as well. In this example, additional regression, performance, and stress testing are likely to be required to make sure the new version of the database is fit for use.

Risk is something that requires active management. Being risk-aware at all times is a sign of a good Project Manager, whose role is not to prevent or mitigate all risks, but to meticulously record, track, and ensure they are pursued by the appropriate project team members until their conclusion.

This is most typically done via a detailed risks, assumptions, issues, and dependencies (RAID) log. As the name suggests, this is a detailed log of risks, actions, issues, and decisions (sometimes dependencies), which we discussed in Chapter 2, What Are the Key Skills I Need?. The RAID log should be a published document that everyone on the project team contributes to.

Risks should be identified, assessed, and prioritized in a consistently manner as part of its entry into the RAID log.

There's a huge variety of risk types and classifications adapted for software projects, but I particularly like the simple yet effective model by technology and project management writer, Balaji Viswanathan, who lists only four types of risks: