CHAPTER 1

Introduction to Processes

In this chapter, a meta-model is introduced that serves to better understand HybridP3M as a novel methodology. Every element of this meta-model is important. Next, process aspects are explained as to better position HybridP3M processes with some meta-data (data about processes). Then, HybridP3M’s fourteen unique processes are introduced. A graphical depiction of the combined processes is missing as the processes are difficult to relate with one another (based on complex relationships, independent execution, or an extra dimension such as time in life cycle management). It is better to present a model of project enterprise functions that lays the foundation for functional processes (see Figure 1.1).

Figure 1.1 Project Enterprise Functions (adapted from Rosinski, 2019, p. 41)

Meta-model

Meta-models are important in the process of method engineering, a niche scientific discipline. The meta-model behind HybridP3M follows a generic best practice structure. The backbone of this structure consists of process, activity, role, and product. According to this structure, processes consist of one or more activities. Activities are performed by roles, and each engaging role has a specific relation to an activity. This means that if multiple roles engage in the same activity, their role in terms of action differs. Activities transform products. Products are used as input, part of the output, or being updated (implying that they have states in the context of a larger process). Roles are the first factor of activity and are based on enterprise functions, staging formal and informal positions within a (temporary) organization. The first factor refers to the fact that activities are a function of engaging roles in the context of larger processes grouping these activities when defined formally. Every distinct role has a unique approach in the context of a process, and this is evidenced by the type or way activity is performed. Then there exists a second factor, which is per definition weaker. The second factor places activities in context. Contextual understanding of activity remains a factor because it helps to define activities in the first place. Note that definition of activities is relevant in not only method engineering but also project planning, namely prior to schedule formation. The most notable candidates for the second factor are enterprise functions, perspectives or aspects, and legal ramifications (driven by project contracts). The final element of the meta-model is independent aspect characterized by indirect relationship with the other elements. So an element that does not relate to the process model itself but provides broader context for the development of a body of knowledge. And the best candidate is arguably principle. All principles combined reflect the philosophy behind a methodology. See Figure 1.2 for a graphical depiction of the meta-model based on the explained structure. Note that the concept associations have “multiplicity” (based on unified modeling language [UML] conventions).

HybridP3M consists of fourteen processes that provide the foundation of the process model. A process model is a detailed mapping of process-related elements. In case of HybridP3M, the process model relates to the core structure of the meta-model, including the second factor and, to a lesser extent, the independent aspect (indirect factor). Essentially, the process model consists of process descriptions, which can be captured as text, represented by figures, or embedded in web-based tools. The process model is basically the meta-model at work. It covers real examples, instances of specific meta-model elements. For example, a process description of planning may explain the relationship with specific roles engaged or define subprocesses as part of planning. On Insight Intranet, you can find examples of web-based process models, including PRINCE2 and ProwLO. Note that these two methodologies have a similar meta-model to HybridP3M (which should be the standard). The Praxis framework, on the other hand, has a different meta-model due to the fact of its larger scope (e.g., covering competence and capability maturity). But if you focus on the latter method in terms of process model, a weakness becomes apparent: it does not (yet) have well-defined roles or principles, admitted by the owner. In conclusion, HybridP3M’s process model is shaped by its meta-model.

Figure 1.2 HybridP3M meta-model

Process Aspects

HybridP3M’s processes, which will be introduced in the following section, differentiate from competition from a closer analysis by process aspects. An analysis of processes based on process aspects helps to differentiate them among each other and to position them better (as compared to competing processes from other frameworks or from a higher point of view). It is meta-data about the processes. The five chosen conceivable process aspects are: (1) knowledge nature, (2) manageability, (3) specialization, (4) IT support, and (5) complexity. Maybe surprisingly, agility is not chosen. Agility is simply perceived as the outcome of a process or combination of processes. Obviously, process characteristics contribute to agility, but it is difficult to define a process in terms of agility due to the limited scope of processes (bound by process goals) and complex meaning of agile. By reading this guide, a better understanding of agile will gradually develop.

Knowledge nature is a tacit-explicit knowledge continuum. Processes that depend on explicit knowledge can be taught from books and other explicit sources, while processes that depend on tacit knowledge require personal experience to master them. Manageability refers to a step-by-step process versus skilled activity continuum. A step-by-step process can be easily followed and mastered by internalization, whereas a skilled activity requires practical experience and is not necessarily a linear sequence. A step-by-step process is manageable because it is easier to institutionalize with the help of explicit artifacts (like guides or web-based material). Also training material is easier to develop. Promoting skilled activity, on the other hand, requires other, more complex interventions such as learning on the job. Inspired by the distinction of management versus specialist products in PRINCE2, the third process aspect is specialization. But unlike PRINCE2’s interpretation (where specialists have technical roles), even within the domain of management there are specializations. So project management is a management-specialist continuum. The fourth process aspect, IT support, is a scale of available IT support in the context of a process. Some processes more than others can benefit from the use of tools. Automation, with the advent of AI, has also become increasingly more realistic, at least in theory. Finally, complexity is a task complexity scale. Complexity depends on a multitude of activities, activity process flows, the number of roles and actors involved, and task difficulty. While an assessment of processes using scales and continuums is rather an arbitrary assignment open to debate, the assessments in this book are compensated by additional explanations.

HybridP3M’s Processes

HybridP3M consists of the following processes, in any particular order:

For each process there is a devoted chapter. In these chapters, the processes are elaborated in great detail. This section only provides a basic understanding of each process.

Defining the Project or Program

Defining the project or program is the process that gives projects and programs existence and shape. Thanks to definition, projects and programs can be differentiated from business as usual and managed as unique undertakings. Definition covers written text, including various statements but also informal communication. In terms of content, definition also pays attention to the management environment that needs to be created to facilitate the technical challenges.

Integrating Knowledge Management

Integrating knowledge management is the process that merges the discipline of knowledge management with project processes. Knowledge management solves many problems at various levels. At the project level, for example, it helps to close knowledge and experience gaps. At the portfolio level, for example, it helps to close the gap between project-based learning and organizational learning, which implies that learning is shared beyond project boundaries and across teams. Knowledge management is a distinct process, supporting other project processes, including project management. Thanks to this kind of acknowledgment and one devoted process, HybridP3M is the only project and program methodology that respects knowledge management properly. While the Praxis framework addresses knowledge management, it provides very limited guidance. HybridP3M is closely aligned with the “Projects with Learning Outcomes” (ProwLO) methodology, through the third matrix (mapping between HybridP3M’s and PRINCE2’s processes), as will become apparent in the next chapter.

Planning

Planning is the process that anticipates (project or program) outcomes and defines a path to accomplish goals, taking into account constraints such as budget, time, and resources. Planning depends on the delivery model. In case of predictive or waterfall models, planning defines most project activity and, based on estimates, may provide realistic schedules. In such cases, project execution is usually governed by different levels of plans, including a project plan, stage plans, and optionally team plans (see PRINCE2). The project plan is first created at the beginning of a project, an upfront investment, and provides a baseline in the process of project evaluation. A predictive environment with a baseline plan enables management-by-exception, a PRINCE2 principle, characteristic of traditional project management. In case of Agile delivery methods, upfront planning is elusive due to the incremental and iterative nature of delivery. In such cases, a baseline project plan has little guiding and evaluation value. In turn, the live project plan (continuously updated based on progress) would become too dynamic and thus become a historical record of dynamic change instead of a container with predictive capability. So instead of using project plans, planning in the context of Agile delivery is mainly limited to prediction of small increments (also known as sprints in software development) and the equivalent concept of team plans (detailed plans at a very granular level). But irrespective of the delivery model, the Stage Gate paradigm must be enforced allowing management-by-stages, another PRINCE2 principle. This principle is essential for traditional project management and ProwLO’s approach to project knowledge management (see Chapter 3). So HybridP3M must somehow combine the organization of projects and programs in stages with the planning of small increments. To the question of: is there a need for planning small increments at all? The answer is yes, for the coordination of teams.

Mitigating Risks

Mitigating risks is the process that identifies threats based on probability and impact resulting in risk (defined as potential damage due to vulnerability). It is also the process that, proactively, provides countermeasures to prevent risks from materializing, or preparations minimizing damage in the event risks materialize. When risks are residual, that is, cannot be prevented from occurring in the first place, only the second type of measure helps (anticipated reactive intervention). This process enables rational decision-making dealing with uncertainty. Thanks to risk identification, external and internal factors that can jeopardize project outcomes can be anticipated. However, in practice, there are always emergent factors that are unforeseen events. Emergent factors ultimately decide on risk and project behavior, limiting the effectiveness of risk management. While risk management is a useful tool, it should not become another mystique, a recipe for success (founded on manageability). From a traditional point of view, mitigating risks is partly dictated by risk tolerance. Depending on risk tolerances specific to certain risks, the priority of countermeasures can be established. Overall risk tolerance influences the business case as risks are an essential element of a business case. So the conclusion of business case viability and, thus, project or program beginning and continuation is partly shaped by risk tolerance.

Business Case Development

Business case development is the process that assesses project or program viability. A business case is a formal, dynamic document (as in, e.g., PRINCE2) that provides justification for carrying out projects or programs. It is a decision-making tool to start the project or program, or to stop it prematurely, saving costs. In other words, as a project unfolds, the business case provides justification for its continuation. Thus, it has to be revisited periodically or in a more ad hoc fashion as new data becomes available. There are many potential triggers for the evaluation of a business case, including changes in the environment, discovery of wrong assumptions, or the start of a new stage with additional planning data. The key element of the business case is the cost–benefits analysis.

Realizing Benefits

Realizing benefits is the process that links project or program goals with business strategy and takes advantage of arising opportunities as projects or programs unfold. Taking advantage means exploitation. Projects and programs are not stand-alone ventures; they are linked with permanent organizations with a long-term strategy. Realizing benefits transcends project processes and is rooted in portfolio management, which in turn is highly influenced by corporate management. This shows that the management of project and programs is a P3M or even corporate challenge (calling for cross-functional alignment), supporting the belief that project management and program management should evolve into a P3M-integrated discipline (first started with the Praxis framework). Realizing benefits motivates Agile behavior. As new opportunities may arise over the course of time, any project, program, or portfolio should have enough flexible capability to incorporate specific changes, to the benefit of the wider organization. Adjusting to these opportunities may alter project and program goals and consequently induce change in the delivery process. Alternatively, depending on the type of opportunity, portfolio management may trigger new projects and programs. Linking project or program goals with business strategy calls for alignment. While business strategy drives projects and programs (based on their anticipated added value), it may also evolve based on their actual outcome (by reflecting on their realized value). A well-defined, comprehensive P3M process of realizing benefits contributes to Agile performance. After project or program completion, when technical solutions are still in service (as part of the product’s life cycle), realizing benefits may still trigger new increments for modification of the solution based on new opportunities (calling for new features) or a product improvement policy.

Monitoring and Control

Monitoring and control (M&C) is the process that ensures project or program goals are adhered to and correctly implemented based on the blueprint of planning. To this end the M&C process must maintain a stable management environment and prevent discrepancy between plans and actual progress. So project or program definition and planning provide the foundation for M&C. M&C is essentially a traditional process striving for predictive project behavior helped by accurate planning. M&C differs depending on the delivery model. In case of predictive or waterfall, M&C focuses on a successful execution of plans. Progress is managed based on a set of tolerances, corresponding to the principle of management-by-exception. In case of Agile delivery, M&C is reduced to people control as there are no comprehensive and detailed plans to guide progress. Without specified and agreed tolerances (due to a lack of baseline plans) management-by-exception is not an option. People control, a form of social control based on culture (foremost shared values) and molded by leadership (a distinct HybridP3M process), helps to establish predictive behavior aligned with project or program goals. But thanks to the Stage Gate paradigm, the project board, or other decision-making authority, any project or program has a controlled start, middle, and end (as also propagated by PRINCE2). By defining stages, decision moments can be planned to decide on the continuation of projects and programs, an essential form of control according to traditional philosophy that works with different delivery models (as reflected by, e.g., PRINCE2 Agile).

Managing Stakeholder Expectations

Managing stakeholder expectations is the process that informs stakeholders of progress in reality and, at the same time, tries to manipulate project behavior so that progress more closely follows stakeholder expectations. The latter can be achieved based on changing the conditions of the management environment (e.g., tweaking the process model or project organization) or various management interventions, centered on project acceleration (the time dimension), cost control (the cost dimension), quality improvement (the quality dimension), risk management (the risk dimension), or increasing benefits (the benefits dimension). Ultimately, stakeholders seek project success, a rather personal perception, which can be quantified based on objective measures. In Chapter 12, an attempt is made to rationalize project success (in the context of project and program evaluation). Basically, managing stakeholder expectations is to ensure the project or program is perceived as a success by all stakeholders, with a high rate of customer satisfaction—related to the overall process as well as end-result—as an important criterion. Adequate communication is an important prerequisite in the process.

Managing Requirements

Managing requirements is the process that uses feedback to develop required solutions, from project inception to handover moments, as far as in the maintenance phase, until product end of use (so the complete product life cycle), and that integrates requests for change with minimal delay and cost in the delivery process. Note that in software development, with the advent of DevOps, the transition from a project to business as usual, marked by the end of a project, is blurred as product development organized as a project (a traditional assumption) merges with operations and quality assurance. In a way, DevOps is the antithesis of conventional project and program management with a limiting life cycle and predetermined time band. HybridP3M’s P3M approach, linking interdependent functions by exposing interfaces between them, may block the DevOps trend by providing a more traditional alternative. Management of requirements involves the translation of customer demand into a set of non-conflicting requirements that can provide the foundation for feasible solutions. In software development, it is common that when you combine elements the “solution” is limited due to inherent restrictions and design choices. So the capture of requirements automatically leads to the discovery of restrictions and possibly new requirements imposed by these restrictions. In other words, an intricate net of requirements will develop subject to rules and conventions inherent to technology. In practice, specifications lacking detail (high-level requirements) enable creativity and developer initiative, a trade-off with implications for risk. Generally, agility depends on a flexible adaptation of requirements (maintaining a feasible product that can be easily adjusted) and effective and efficient implementation of new features as required.

Evaluating the Project or Program

Evaluating the project or program is the process that reflects on project performance, answers to project success, and provides learning opportunities. Relatively speaking, it is not so popular in practice, despite its importance. This is related to the fact that learning organizations are not quite common. Empirical data shows that there are hardly, if any, optimized organizations with high maturity levels. Systematic learning, such as enabled by repeated evaluation, is typical for organizations with the highest level of maturity. Only systematic learning enables optimization, and both are still lacking in P3M environments. So is, generally speaking, a culture of learning, a precondition for learning. The role of knowledge management, increasingly recognized as a project success factor, plays a pivotal role in changing this situation. Evaluating the project or program is an ambiguous project management and knowledge management process. Since facilitating learning and increasing the learning capability of project members is a specialization, the project knowledge manager plays a critical role in this evaluation process. The project manager, on the other hand, should focus on the analysis of project performance using any available baselines: a clear role division.

Leading the Project or Program

Leading the project or program is the process that relates to the people side of management in P3M environments, building relationships and dividing labor at the same time. Leadership is all about leading processes, less about the people who are in charge, a rather unconventional proposition (but not novel). This proposition is founded on the belief that both leaders and followers are equally important in creating behavior serving common interests aligned with process goals or higher-level common goals (based on shared values). In other words, also followers are shaping processes. They are leaders in their own right. In the context of projects and programs, leadership means different things at different levels. At a high level, leadership is (general) conduct according to a project or program vision, facing uncertainty and risk common to P3M. For example, having the courage to deal with a technical challenge. At a lower level, leadership is managing teams in the context of product delivery (i.e., people management). Leadership is by no means an isolated process but relates to other HybridP3M processes by various acts. For example, selecting the right people for the project, as part of project establishment, is an act of leadership. Yet it is treated as a distinct process because it has great significance and impact on project behavior. Without leadership, management interventions are just decisions made on paper, not embodied by real people. Qualities like the ability to convince people of the necessity of certain actions are quite essential. Building on the earlier proposition, such qualities could be developed by both leaders and followers. If that is the case, leadership becomes dynamic with potentially shifting roles, in which followers take on the role of leader, and vice versa. This alternative approach to leadership not necessarily contradicts with clear lines of authority and undermines decision-making (very traditional principles). Process leadership, as to label this approach, may result in greater tolerance to changes (corresponding to an agile mindset) and foster a greater support base for decisions made (or yet to be made), primarily thanks to better understanding (indicating effective leadership).

Project/Program Establishment

Project/program establishment is the process that assigns people to roles based on responsibilities, reinforces any hierarchical lines of authority based on organizational design, and, through representation, creates an image of a group of people. Projects and programs are represented by their members and stakeholders. Altogether, they form the establishment. Members want to identify with successful projects as successful actors or teams (for the sake of career, status, etc.) and external opinion—based on image and exposure of project data—may lead to goodwill. So, practically, project establishment involves filling in leadership positions and clever resource management according to an organizational model, but also has a (cognitive) psychological dimension, with implications for leadership, public relations, and team building. From a management point of view, organizational design is a key subprocess as it provides an important foundation for the management environment, with implications for hierarchy and processes, calling for overall methodological alignment. The management environment is generally formed by people and culture (a key organizational dimension), protocols, conventions, and adopted models. Organizational design is followed by job assignments, that is to say, the allocation of people. Assigning people is a rational, matchmaking (capacity-related), or political (more random) process—in reality a spectrum, depending on leadership (i.e., the decision-makers), and type of position (management or technical). In conclusion, project/program establishment is a matter of organization but also representation.

Providing Assurance

Providing assurance is the process that aligns project processes to organizational standards and procedures based on monitoring and intervention. Intervention may imply enforcement of organizational standards. Providing assurance is highly influenced by the corporate quality assurance (QA) function, but it is not their responsibility. In the context of projects and programs, QA is limited to auditing (with similar process goals), a regular feature but not a repeated process. Instead, providing assurance is the responsibility of project board members (OGC 2009), people who decide on the viability of the project or program. The project board or equivalent groups of people are senior members with a great understanding of the value of corporate standards. So thanks to their continuous involvement in projects or program, the benefits of providing assurance can be guaranteed. The main benefit is arguably process consistency across projects. Depending on the application area, standards are co-developed, including the adoption and adaptation of standards derived from external sources, by quality analysts and the project management office. So the project board relies on their work.

Agile Product Delivery

Agile product delivery is the process that accelerates the development of technical solutions adjusted to dynamic changes in requirements, focused on the delivery of working parts, which can be evaluated, and just-intime modified without compromising project or program objectives. This implies a close cooperation with customers for their essential input in the delivery process, calling for feedback processes. Accelerated development is achieved based on shorter rework cycles, thanks to a timely intervention by change authorities. Agile product delivery in HybridP3M is a structured process supported by formal change procedure, not unpredictable behavior with a disregard for earlier agreed project goals and objectives. Accordingly, this process is not conflicting with the traditional notion of a controlled environment. But Agile product delivery does limit upfront planning. Consequently, M&C is no longer guided by planning due to the lack of baselines (a traditional control mechanism). Traditionally, plans were used as a tool to predict and identify the exceeding of tolerances (at various levels depending on the level of plan), aligned with the principle of management-by-exception. In an Agile setting, tolerances are made independent from planning deliverables and adjusted to flexible stages with more uncertain length and cost. In practice, this means that exceptions are limited to project-level tolerances (i.e., overall budget, duration requirements). In other words, contractual agreement should take into account the limitations of detailed planning. Agile product delivery is also a mindset: to deliver value to customers as quick as possible. Improvement of the product based on additional increments, iterative or not, has become the new standard. Depending on the industry and project type, this kind of approach makes the delivery of a stable, final product within project or program boundaries (characterized by limited time and budget) more and more elusive. Agile product delivery, although very popularized, is not something radically new. Its significance is rooted in contradiction with a waterfall delivery model. HybridP3M acknowledges that the choice for a specific delivery model involves a trade-off between predictability and flexibility, as long as the industry permits, and favors in this respect Agile delivery.