CHAPTER 9

Monitoring and Control

Monitoring and control (M&C) is a HybridP3M process derived from the enterprise function bearing the same name (see Figure 9.1). As a function and enterprise dimension, M&C has an old tradition rooted in efficiency thinking. In the context of project-based organizations, M&C traditionally focused on control of project anomaly based on planning deliverables. This was in the time when waterfall thinking was dominant and delivery predictive. In the current era, in which agile methods changed the project management landscape, the purpose of M&C needs to be reconsidered as project planning strongly depends on the delivery model and as a reaction to shorter planning horizons, a trend that started with agile delivery. Observation shows that agile methods collectively fail to address the project management implications of M&C, similar to support of other essential project management functions like planning. It is not without a reason that HybridP3M, like many other experts, stresses that agile approaches are not project management methodologies. They are simply not comprehensive enough, either too implicit or lacking guidance entirely. And as compared to any available method in the realm of project management, HybridP3M takes the quality of being a holistic body of knowledge to a whole new level, thanks to the combination of functional achievement and P3M interfaces in particular, but also coverage of the topic of leadership, principles, and so on. Taking all of this into account, HybridP3M has expanded the scope of the M&C process to address benefits, planning (becoming less dominant), delivery (to ensure productivity, quality, and safeguard agility), stakeholder commitment, and change (promoting change management and a controlled change procedure). Every activity in this process is the responsibility of the controller, a distinct, complementary project role that needs to be promoted in today’s business (just like the project knowledge manager).

Figure 9.1 M&C PDD

Define M&C Strategy

According to Wim Scheper, basing his insight on work of Merchant and Van Der Stede (2003), there are essentially three forms of control, namely result control, people control, and action control, which may complement each other. Result control is performance based. It is the type of control set by targets (enabled by systems that measure performance) and maintained by incentives (e.g., reward for performance). A characteristic of result control is that organizational members enjoy a large degree of individual freedom. The focus is on meeting targets, not how they are met. The pitfall of result control is to not address gamesmanship, which contradicts fair play. People control is culture based. Every organization uses people control, aware of it or not. People control is primarily formed by socialization processes, rooted in value-driven behavior (or lack of values in amoral cases) and cultural expression in general. A key management mechanism for people control is the recruitment process in combination with a recruitment policy, for attracting the “right” people. Another mechanism are training concepts. Action control limits the freedom of individuals by limiting their actions or enforcing certain actions based on various control systems (sometimes IT based). Monitoring of behavior is a dominant theme in action control. A useful metaphor for action control is looking over one’s shoulder.

The three main forms of control should provide the foundation for the M&C strategy of a project or program, the output of the first M&C activity (as depicted in Figure 9.1). In this strategy deliverable, as formal capture is preferred over informal communication, it is explained how each form of control applies to the project or program in question. Usually, the strategy depends on corporate policy and systems, so tailoring an approach is limited and possibly directed top-down (a potential P3M interface).

M&C Benefits

After definition of the M&C strategy early in a project’s or program’s life cycle, various parallel processes of M&C unfold. One of them addresses the area of benefits. M&C of benefits complements the realizing benefits process and review of benefits activity in particular, and it is not considered as redundant. It is namely performed by the controller, an extra responsibility complementing the work of the project manager, project board, financial specialist, and corporate management, who deal with benefits management according to realizing benefits. The controller monitors benefits by monitoring enabling capabilities that rely on project outcomes, but also conditions (market or organization wise) affecting the latter outcomes or long-term benefit realization. Since benefits need to be managed during a project or program, enabling steering (and thus a degree of agility), this often requires foresight and prediction of outcomes. Conditions, on the other hand, are always actual but may change, and thus any change needs to be anticipated. Based on his or her analysis, the controller may conclude that benefits are under threat. If that is the case, he or she needs to alert the project manager who will trigger the activity of “review benefits,” a process interface escalating the issue in the context of realizing benefits. So the controller himself or herself does not take any further control measures.

M&C Planning

A traditional interpretation of project success in terms of project performance is delivery on time, on budget, and on scope. These three aspects also correspond to the three variables of the triple constraints model (a well-known PM concept): time, cost, and scope, in which manipulation of one variable affects the other two and quality in the middle. While the triple constraint model reflects the interdependencies logically, it is not a useful management tool as decision making regarding time, budget, and scope is not a simple process, and not a project manager’s task. It is an oversimplification of stakeholder decision rationale. That said, the three variables are embedded in planning and need to be measured, for example, against baselines in case of predictive delivery. Measurement of these project level variables enables a record of performance useful for project evaluation and establishment of project success. Much more common than performance measurement in this context of M&C is the adjustment of planning, also for the sake of having up-to-date schedules, essential to progress tracking and task coordination. In case of predictive delivery (only), performance measurement and schedule information are sometimes combined to gain advanced insight as follows from earned value management (EVM). EVM is a technique for the measurement of performance based on objective analysis of progress. The three key metrics of EVM are actual costs, planned value, and earned value. Actual cost is the budget that has been consumed up to a specific point in time. Planned value is the amount of allocated budget for a specific point in time according to original planning. And earned value is the amount of work that has been completed in reference to the original project budget. Generally, one can say that EVM is a rather rigid approach and strongly relies on accurate baselines. In dynamic, uncertain environments, demanding an agile approach, EVM is never an option.

M&C Delivery Process

The controller role is also responsible for M&C of the delivery process. This responsibility complements the role of the team manager with regard to delivery. While the team manager leads a team of specialists and mainly supervises work, the controller holds a record of actual working hours and cost related to specific tasks actually performed. He or she uses this data for updating actual schedules (used for coordination purposes) and the “project history plan” (for evaluation purposes), consolidated based on the former. So the controller has a better picture of performance in terms of numbers and should report or discuss progress with the team manager. The controller should also pay attention to control of quality by examining whether completed work satisfies quality requirements or explicit or implicit quality standards. It is either the controller or team manager who is responsible for updating the Quality Log (or Register), a PRINCE2 product and activity. Generally, the team manager is more concerned with day-to-day business, directing team members and making sure things are getting done. The controller, on the other hand, observes delivery more from a distance and lacks authority to direct team members, such as the assignment of work. This unique position of the controller enables him or her to make observations from a tactical point of view. In particular, the controller should monitor how agile the overall delivery process is practiced and communicate his or her findings to the team manager. Agility will depend on the incremental and iterative character of delivery and on satisfaction of customer requirements, taking into account priority levels.

M&C Stakeholder Commitment

Stakeholder commitment depends on effective stakeholder management, including the popular notion of stakeholder engagement. However, commitment can only be influenced to a certain degree. It is also a function of stakeholder interests and focus, which in a dynamic world, just like attention, shifts. So managers should be aware of another potential mystique: overestimating the effect of stakeholder management. That said, stakeholder commitment is a critical success factor and therefore needs to be monitored. As commitment is difficult to measure by traditional means of data collection (except some clever use of survey), it needs to be observed and assessed informally. Therefore, the controller role needs to be present during key meetings and discussions between the project board and the project manager. Additionally, the controller should study made decisions and the decision-making process behind them. The controller also needs to have a conception of commitment and understanding of cultural differences and various attitudes. A key indicator of commitment is arguably buy-in. Buy-in refers to the degree stakeholders support the overall business case based on their stake in the project or program, sometimes a separate business case (in case of a commercial customer/supplier environment). But there are many more possible indicators. Examples are devotion to the adopted process model, application of project assurance (as part of project direction), cooperation with the business analyst for requirements gathering, feedback on new system releases, public relations via corporate media channels (promoting the project/program), quality control indicating interest in project output, and so on.

M&C Change

The final parallel M&C activity relates to change. Change may apply to (desired) project outcomes, project output (the deliverables, end product) depending on requirements and actual results (irreversible or not), the management environment (e.g., modification of a process), benefits, contractual agreement with third parties, the project organization (and resource management), project or program assumptions, regulation, risk, and other areas. The controller should monitor change based on observation, enquiry, and data collection (in particular the output of the change control procedure). In his or her analysis, the controller should do a couple of checks. First of all, determine whether the change affects the business case, in either a positive or negative way. Second, the controller should check whether the change affects planning. Third, the controller should check whether the change affects the process model as part of the management environment. Other checks are imaginable. Based on the findings, the controller should report to the project manager and provide feedback on the data collected thanks to application of the change control procedure. It should be stressed that the change control procedure, if properly applied, enables a consistent, coordinated approach to change management. And a double check by the controller certainly helps to (1) better map the impact of change and (2) validate responsive measures and taken decisions.

Analyze Anomalies

The parallel M&C activities described above enable responsive management of expectations. In any management environment, there exist expectations. These expectations combined may well provide the justification of a project or program. Thanks to M&C, one can determine whether expectations are realistic, need to be adjusted, or corrective actions are needed to keep the same expectations maintained as realistic. In other words, M&C relies on data collection and control measures in order to anticipate expectations. Expectations in all key control areas are essential in developing understanding of any specific project and program. Accordingly, as fundamental assumptions, expectations minimize uncertainty based on understanding. Having expectations provides key project members an important frame of reference for using management principles, the type of management characterized by control and exception management.

Unexpected project behavior, which often can be traced back to people’s actions or wrong assumptions in the first place, may result in project anomalies in one or more of key control areas. While M&C should initiate corrective measures, the complexity of an anomaly may demand closer examination, in retrospect (more specifically, at a later reflection moment during a life cycle), for effective resolution, understanding, or learning purposes. In contrast, “immediate anomaly resolution” (based on any means of control) is simply part of M&C. Hence, the activity of “analyze project anomalies,” performed by the controller, follows an initial M&C response to an anomaly. When M&C of an anomaly initially proves ineffective, this may provide the foundation for the development of a case (problem+solution scenario) and iterative decision making (Rosinski, 2019). Here, we are dealing with “contemplated anomaly resolution” or “rationalization of anomaly.” So the notion of potential iterations complicates the activity flow of M&C. The activity of “analyze project anomalies” requires additional time and resources for reflection and an opportunity to reflect, such as Gate reviews.

Analyze M&C Processes

M&C mainly relies on data collection, data analysis, and observation. It makes sense to implement systems and IT tools that generate insights from data and collect data in the first place. Digital transformation applied to projects and programs, or project analytics, may play a large part in this respect, although it is still in its infancy. Second, it makes sense to learn from project anomalies as to better anticipate project outcomes and behaviors in the future. As project anomalies may explain project failure, it is critical to understand them thoroughly in terms of cause and effect. Lessons Learned may reveal that M&C activities were ineffective or inappropriate and lead to follow on recommendations for process improvement.

Review M&C Strategy

The final M&C activity in the activity flow is “review the M&C strategy.” In the context of this activity, the controller reflects on the M&C strategy adopted in the beginning. It takes place at the very end of a project, when all Lessons Learned are reviewed (tested for validity), aggregated, and consolidated. The review should consider all three types of management control (recall that these are result control, people control, and action control), how they were embedded into the project or program, and whether changes are required according to new understanding or Lessons Learned with Follow-On Action Recommendations.

Periodically Create Highlight Report

The final activity addressed by M&C, which is independent from the depicted activity flow in Figure 9.1, is to periodically create a highlight report. This activity, which is triggered mainly by time, is adopted from the PRINCE2 methodology. In PRINCE2, the highlight report serves to keep project board members informed of progress (with traditional planning deliverables as the main baselines). In HybridP3M, this purpose is extended to inform all stakeholders and corporate leaders (with a particular interest in the project or program) on progress and other relevant information, tailored to satisfy information requirements.

Process Aspects

Figure 9.2 captures the manageability of M&C.

Figure 9.2 Tacit–explicit continuum of M&C

M&C relies on a combination of tacit and explicit knowledge. There is no predominance of one type.

Figure 9.3 captures the manageability of M&C.

Figure 9.3 Step-by-step process versus skilled activity continuum of M&C

M&C is a skilled activity, and it is not a step-by-step process. It takes experience to learn M&C methods and techniques and to apply them in the right context. Therefore, a distinct controller role should be part of the management team.

Figure 9.4 captures the specialization level of M&C.

Figure 9.4 Management–specialist continuum of M&C

M&C is neither a typical project management responsibility nor specialization. It is somewhere in the middle. So the project manager can evolve into a proficient controller.

Figure 9.5 captures IT support in relation to M&C.

Figure 9.5 Available IT support for M&C

M&C according to HybridP3M’s interpretation is a diverse process. There is no software on the market that deals with all of its aspects. But there are tools that support specific niche areas. For example, work flow software is a form of action control.

Figure 9.6 captures the complexity of M&C.

Figure 9.6 Task complexity scale of M&C

M&C is a complex process considering all the aspects involved. M&C involves a number of key parallel processes consisting of complex activity. This complex activity is difficult to organize according to a step-by-step process. Rather, M&C relies on best practices (applied in the right situation or context).

MAIDEO Requirements

Table 9.1 presents MAIDEO requirements related to “monitoring and control.”

Table 9.1 MAIDEO requirements related to M&C