In our first three installments, we discussed Project Initiation, Project Planning, and Project Execution—the first three phases of the methodology promoted by the Project Management Institute. There are many other methodologies, but they all include, at a minimum, a set of processes for initiating, planning, executing, monitoring and controlling, and closing a project. We find the greatest differences among methodologies in the execution phase of the project, mainly due to differences in project purpose. For example, a project to construct a building will of necessity be managed differently from one whose goal is to develop a new computer operating system, integrating artificial intelligence and untested and untried technologies.With that said, the PMI methodology,which we are using for this series of articles, is well known andhas stood the test of time. It is also very customizable to a wide variety of projects. Still, it’s good to keep in mind that there are other very useful methodologies you may use to manage your next project. Even if you decide that Agile, Extreme Programming (XP), PRINCE2, or another methodology is the most appropriate for your project and business environment, all projects can be broken down into the five basic processes listed above.
Understanding that our discussion in this series is general and relevant to all projects, let’s continue with the next major process group, Project Monitoring and Controlling. The first three groups were sequential phases—ideally, one finishes before the next one begins. This next group, though, is not so much a phase as it is a group of tasks that help keep the project on schedule and on budget. It is performed during and in parallel with the Project Execution Phase.
Much of the activity in the Project Monitoring and Controlling group can be thought of as an audit of the other process groups—scheduled tasks and deliverables, scope and requests for changes, cost, quality, communication, risk, and procurement. The project manager leads the work required to track, review, and regulate the execution of the project. The reason we have a separate process group just for monitoring and controlling is to ensure that the performance of the project is measured on a regular basis. By doing this, variances to the plan and budget are noted and handled immediately, rather than sneaking up on the project manager at the worst possible time. And the worst possible time is any time you’re not expecting it. By consciously including continuous project audits, the project manager can control changes, anticipate problems, and actively manage performance and costs. Areas requiring attention can be tended to before they reach the crisis stage. The PM can steer and adjust project activities so that they fulfill the objectives stated in the Project Management Plan.
The purpose of this process sub-group is to ensure that the work being performed meets the performance objectives of the project as defined by the Project Management Plan. Monitoring not only includes keeping track of what’s going on within the project, but measuring its progress to verify that it meets the schedule and cost goals, and taking corrective action or making modifications to the plan as necessary. This area also includes reviewing and re-assessing risks and monitoring the implementation of approved changes.This process sub-group also includes reporting to stakeholders the general project status and project performance with regard to scope, schedule, cost, resources, quality, and risk.
Changes will derail any project if not managed well. For example, you might be running a project to upgrade a billing system, one of whose parts is an externally provided database management system (DBMS). If the DBMS vendor were to introduce a new software version during the course of the project, the project team would have to evaluate the change and recommend whether the upgrade should be adopted by the project. Some considerations might be: What other systems within the enterprise use the DBMS? Is it possible to maintain one release level for use by the billing system if other parts of the enterprise decide to upgrade? If the project decides to upgrade, what testing will be required of the new DBMS? How will this change affect the schedule and resource requirements? If there is a cost to the upgrade, will it affect the project’s budget? In fact, how will the simple fact of considering all the questions that need to be answered affect the schedule and budget?
This process sub-group ensures that all change requests are reviewed, that decisions regarding their implementation are well-documented, and approved changes are correctly integrated into the project, with proper accounting for impacts to schedule, cost, scope, and quality.
For a large project, many organizations will establish both a Change Control Board and a Configuration Control Board in order to provide consistent and timely oversight of change requests. Change control is concerned with identifying, documenting, and controlling changes to the deliverables of the project. Configuration control is concerned with the specifications of the current deliverables and project processes.
Scope creep is the enemy of every project; it’s like that fly buzzing around your head that will not go away. Since you can’t get rid of it, better to accept and deal with it. We do this by first, verifying yet again that the scope of the project is what the enterprise requires. Projects are, by definition, limited in scope. No project can include upgrading, improving, or changing every related product, process, and system touched by it, although from the horror stories every experienced project manager can tell, this is indeed what seems to be the case. We hear, “As long as we’re upgrading the billing system, why don’t we go ahead and upgrade the database it uses at the same time?” Or, “While you’re upgrading the billing system, let’s go ahead and migrate to a different document vendor.” Or, “Since we’re talking about billing, wouldn’t this be a good time to introduce a paperless system?”
These might all be good ideas, but if they were not included in the original project scope, there was a reason. Each change, however minor in appearance, is a possible can of worms and cannot be opened without considering the consequences. In the planning phase, the project manager made sure there was a change request procedure as part of the Project Plan. Now is the time to drag that thing out, dust it off, and use it. In general, the change management process ensures that any change request takes into consideration impacts on the project’s budget and schedule and how the proposed change will affect other deliverables of the project. More, the Change Management Process includes criteria for whether the change proposal will even be considered. All this is designed to keep the project manageable and ensure scope creep does not create a multi-headed monster that consumes the soul of the project. If this happens, it can cause the failure of the entire project, ensuring that not only does the additional scope not get implemented, but that the goals of the original project themselves at best are delayed and at worst, disappear into the dustbin of company history.
In Project Execution the project manager assigns work according to the schedule of tasks. In this sub-group, the PM evaluates how well the team is maintaining schedule. Are time and resource estimates from the planning phase being adhered to? If not, why not and what will that do to other scheduled activities further down the line? If the project is ahead of schedule, how will that affect procurements? If behind schedule, will it be possible to make up time somewhere? Can we perform some activities in parallel that were originally planned in series? Can we shorten scheduled work time by sacrificing quality? All these questions and countless more go through the PM’s head when monitoring the schedule.
From the broader perspective of costs management, which includes estimating and budgeting, we’ll focus in the sub-process on controlling. We’ll monitor the status of the project from a cost standpoint, paying particular attention to changes to the original cost baseline. Cost variances result from two sources: either more work is being done than was planned, or the work being done is costing more than had been expected. In the Control Costs sub-process, the project manager is concerned with ensuring that costs are contained within budget. If they are not, he or she must find the cause and correct the problem. If more work is being done than planned, the project manager will invoke the Change Control process to rein in costs. The extra work may have to be canceled or backed out. Or if the change is deemed necessary, the budget will have to be adjusted to account for the changes that were made.
On the other hand, if work is simply costing more than was planned, the PM will have to seek out the precise cause of the variance and decide whether the budget needs to be re-evaluated for the rest of the project, or if changes to work methods or other variables can bring actual costs in line with budgeted costs.
Both schedule and cost control commonly use a technique known as Earned Value Management (EVM) to calculate and compare planned, earned, and actual costs in hours and money (whichever units are being used) at any point in the schedule. The results of the comparison will give the project manager and stakeholders a quantitative view of the project’s performance. EVM can be used in any type of project, in any type of industry, but requires a well-planned, baselined time and cost schedule as a basis for calculations and comparisons throughout the project.
The ratio calculations and details of EVM are outside of the scope of this article, but the salient points to note are that the results of the calculations give the project management team vital information about the current schedule and costs compared with where they were planned to be at any point, and a basis for estimating a project completion date and final cost with increasing accuracy as the project progresses.
This process group assures that Quality Control(QC) activities performed in the execution phase are monitored and that results are recorded. The purpose of the quality audit process is to ensure that project activities are in accordance with the organization’s standard policies, processes, and procedures. The audit team will not only identify problems and deficiencies in project practices, but will engage in root cause analysis and help to find solutions or,at a minimum, help the team take corrective action to improve the project’s performance. On the other side of the coin, best practices and outstanding performance will also be identified. The QC team should note both positive and negative aspects of the project and record them in a “lessons learned” repository for the benefit of future projects.
This example may not seem like it has anything to do with project management, but indulge me: It’s pretty well known that the Vikings had settlements on the North American continent lo-o-o-ng before Christopher Columbus was even a gleam in his father’s eye. This is to say nothing of the fact that the Vikings knew for a fact that they were nowhere near India when the landed in Nova Scotia. But the sad fact is, the Vikings didn’t report back to their stakeholders and publish their project report, as did our esteemed Mr. Columbus.
So, as the old saying goes, “If it’s not in writing, it never happened.” Way back in a previous article we emphasized the need for communication, and here it is again. In this sub-process group, we collect data, put it into intelligible information, and distribute it to stakeholders.
The reporting requirements were designed in the planning phase and written into the Project Management Plan. Using this as a guide, the project manager will create and distribute performance and status reports on individuals, project work packages, deliverables, and any other project activity. Other reporting requirements may include updated budget and schedule forecasts and updates to any requests for changes to the project plan or deliverables.
All oral reports and meeting discussions should be documented in a storable medium for future reference.And it’s important to note that the information reported should be appropriate for the audience. A five-minute status report to the board of directors will be altogether different from a report to the project sponsor. A high-level, summary presentation may only include “red/yellow/green” graphics on scope, schedule, cost, and quality, while the report to the project sponsor would more likely include a list of current issues, schedule and cost variance percentages and ratios, change request log, work scheduled for the next period, and more.
In earlier phases of the project we listed any risks that anyone on the team could think of and made contingency plans for them. Lest we have a purely negative attitude, we need to remember that risks are any unknowns that can affect the project negatively or positively. So our risk strategy is not only how to minimize the damage to the project from something bad that might happen, but also how to maximize the benefit should something good happen. A risk, if it occurs, will affect costs, schedule, quality, and/or project scope.
In this sub-process group we focus on the Risk Register with the intent of implementing risk response plans if necessary.We also do this simply to keep all identified risks on the radar screen, updating their location, as it were, and continue brainstorming to identify new risks as the business environment changes throughout the project. Through regularly scheduled risk audits, we’ll re-evaluate and update our risk response plan,noting new risks, closing those no-longer needed, and updating contingency plans.
Useful tools are variance and trend analyses of the schedule and costs that might lead us to identifying new risks or give us more information about a previously identified risk that might be on the horizon. Keep in mind that risks, by definition, are future possibilities. Once a risk has occurred, it becomes an issue to be managed according to the contingency plan. If a risk event occurs or is no longer deemed a risk for any reason it should be removed from the register.
As we mentioned in the last installment, purchasing new equipment, software, or services can be a difficult area in a project, with disaster lurking at every turn. This is primarily because the project is normally dealing with outside vendors, over whom the PM has no direct authority. That is exactly why this sub-process group is so important to the success of the project. In this group, we manage relationships, monitor contract performance, and make timely corrections when needed. Subject matter experts on the project team audit the obligations and commitments of the procurement contract to ensure that the project is getting what it paid for and, just as importantly, that the project is fulfilling its obligations under the contract.
Members of the project team, normally from the Contracts and Legal departments of the organization, will use the contract change control system, procurement performance reviews, inspections and audits, payments systems, and other tools and processes to maintain the vendor relationship and oversee contract obligations.
Through this process, the project will document for future reference how well the vendor meets obligations and responds to requests for corrective action. This information may be necessary if a vendor is not meeting contractual requirements; the documentation may be used for legal or other corrective actions taken against them.
This group of processes and activities that comprise Project Monitoring and Controlling, ensure that the project manager, the sponsor, the project team, and all stakeholders at every level of the organization have an on-going, accurate view into the workings and the health of the project. By continuously tracking, reviewing, and regulating the activities of the project, the project manager is able to maintain a view of the project all the way from the 30,000-foot level to the “down and dirty” work in the trenches. By faithfully exercising these processes, surprises, while still happening, will be kept to a minimum, and those that do happen will more likely be minor and infrequent.
by