CHAPTER 15

Providing Assurance

Project/program assurance is based on the need to provide confidence in the face of uncertainty (see Figure 15.1). In the context of projects, it has been made more popular by, for example, PRINCE2. In PRINCE2, project assurance is a subfunction of project direction, a project board responsibility sometimes delegated as a distinct role. In reality, project/ program assurance is a very broad concept, as noted by Onna and Koning (2004). According to these authors, assurance covers most if not all stakeholders’ needs, a rather vague assumption. The specific examples they provide, following the PRINCE2 standard, include monitoring the business case, correct use of standards, customer satisfaction, correct use of resources, and noticing scope creep. Based on the meaning of assurance and such examples one can imagine the importance of an assurance process, but it must be more specific. Assurance should also interfaces with change management, which enables improvements according to a long-term enterprise perspective. HybridP3M’s approach is partly based on the unpublished work of Jim Livesey, a consultant who once posted key reasons for using independent assurance. Three of these reasons are adopted or adapted as part of the HybridP3M assurance process. Providing assurance is closely related to project evaluation, but it has clearly different process goals and a different activity flow, as depicted in Figure 14.1. As a process, providing assurance is quite straightforward, and thus the explanation of individual activities in this context is rather short.

Assessing Process Consistency Against Corporate Standards

The first activity of providing assurance introduced here is to assess process consistency against corporate standards. It is a continuous activity, in principle not bound by life cycle dynamics. But like any other form of evaluation, it requires time to run and, hence, most likely occurs at the end of stages, other decision moments, or handover of key deliverables, which according to Livesey correspond to key times to run independent assurance. It should be noted that this activity is inspired by PRINCE2 guidance. One practical approach is to focus on missing activity, as prescribed according to the process model, with or without lifecycle management extension (i.e., mapping with PRINCE2). A noteworthy best practice in the interest of project assurance is to motivate project management team members to define process goals when adopting the HybridP3M process model.

Figure 15.1 Providing assurance PDD

Capturing Current Areas of Concern

Capturing current areas of concern is adapted from Livesey who used the word validated in this context. The issue with validating is that project assurance may be the first function to discover an area of concern. Areas of concern are instrumental in ad hoc guidance, a key project board responsibility.

Identifying Areas That Are Going Well

Identifying areas that are going well is typical for holistic evaluation, looking at the negative as well as positive things. The insights and lessons learned in this context provide useful input for project evaluation. This activity is adopted from the work by Livesey.

Identifying Improvement Areas

Identifying improvement areas follows the activity to capture current areas of concern and is adopted from the work by Livesey as well. The former activity involves a systematic analysis of issues that tend to repeat. Issues that are systematic should be on a priority list for necessary changes. The development of such a list is the next, follow-up activity.

Prioritizing Improvement Areas

Based on systematic issues, a priority list for necessary changes is developed. As part of this process, improvement areas are prioritized.

Defining Change Initiatives

Based on the analysis of improvement areas, project assurance next defines change initiatives at the corporate level. The definition of such change activity is then passed on to the corporate change management function for feedback and transfer of ownership (of the change issue).

Organizing Change Initiatives as Change Programs

Organizing change initiatives as change programs follows the definition of change initiatives and only applies if the desired change needs to be organized as a change program. That is only the case when dealing with complex changes. This final activity of project assurance is performed by the change management function as the start of new change management initiatives. The change management function relies on the project assurance function for a program mandate, provided in the context of a project or program.

Process Aspects

Figure 15.2 captures the knowledge nature of providing assurance.

Figure 15.2 Tacit–explicit continuum of providing assurance

Assurance tends to focus on explicit knowledge, but the tacit dimension cannot be ignored totally. Externalization, however, is a dominant theme.

Figure 15.3 captures the manageability of providing assurance.

Figure 15.3 Step-by-step process versus skilled activity continuum of providing assurance

Assurance advocates process consistency. Hence, assurance should be incorporated into corporate standards.

Figure 15.4 captures the specialization level of providing assurance.

Figure 15.4 Management–specialist continuum of providing assurance

Assurance is rather a generic management skill, not so much a specialization.

Figure 15.5 captures IT support in relation to providing assurance.

Figure 15.5 Available IT support for providing assurance

IT support mainly plays a role in ensuring process consistency. This is achieved thanks to the promotion of corporate standards and knowledge integration of process knowledge.

Figure 15.6 captures the complexity of providing assurance.

Figure 15.6 Task complexity scale of providing assurance

Once internalized, assurance is not a complex process.

MAIDEO Requirements

Table 15.1 presents MAIDEO requirements related to “providing assurance.”

Table 15.1 MAIDEO requirements related to providing assurance