50 most recent topics according to Tags

Matrix 3: Extending HybridP3M processes with PRINCE2's life cycle management

A key strenght of PRINCE2 is how it identifies various stages of a project life cycle. Following PRINCE2's process model, the lifecycle dictates project processes. But PRINCE2 is mistaken by the prescriptive quality of its key processes in terms of activities. So, at the process level there are indeed distinguishable processes, but at the activity level, as a project unfolds, projects are not characterized by uniform process. So the detailed process model of PRINCE2, its key characteristic, is also the weakness of PRINCE2. HybridP3M's processes better reflect actual project behaviour, as it should be (to-be). So the best solution is to place HybridP3M's processes into perspective of life cycle management. In otherwords, to map HybridP3M processes with high level PRINCE2 processes. However, it should be stressed that in practice, whilst useful this mapping has limited prescriptive power. The reality of project behaviour is much more complex and divergent. Exceptions in terms of processes are commonplace, and thus process models have limited generic validity (i.e. applicability in different situations).

The development of Matrix 3: HybridP3M-PRINCE2 Mapping, consists of two steps. The goal is to adopt a custom made matrix given organizational focus and organizational life cycle management. The first step is to identify the relevance of a HybridP3M process in the context of a PRINCE2 process (link HybridP3M to life cycle management), which implies putting a cross in table indicating relevance (essentially a vague reference). Based on this initial mapping the second step is to be more specific and explain how a specific HybridP3M process takes shape in the context of life cycle management. The latter is essentially a matter of annotation for more specific guidance. Note that Adopting Matrix 3 is an act of life cycle management and a part of project or programme definition. Table 2.4 below illustrates step 1, while Table 2.5 illustrates step 2. One conclusion that can be drawn from Table 2.4 is that specific HybridP3M processes are quite continuous, not isolated to specific life cycle processes.

Table 2.4: Matrix 3 based on cross-references

Table 2.5: Example of Matrix 3 with annotations (Continued)

Table 2.6: Example of Matrix 3 with annotations (Continued)

Table 2.7: Example of Matrix 3 with annotations (Continued)

Table 2.8: Example of Matrix 3 with annotations (Continued)

Table 2.9: Example of Matrix 3 with annotations (Continued)

Table 2.10: Example of Matrix 3 with annotations (Continued)

Table 2.11: Example of Matrix 3 with annotations (Continued)

What makes HybridP3M Agile and Traditional at the same time?

HybridP3M is characterized by team dynamics in the project management team, a matrix organization, complemented with the project board, with often joint responsibility for processes. Teams are more adaptable to change as compared to single actors with personal bias. Coordination, alignment, team work, multilateral communication all play a part in team dynamics. The leader paradigm, a single champion, is no longer sufficient to deal with complex and dynamic situations. Only groups of people with their own unique skillsets are able to cope with the complex demands as requested by projects and programmes. The knowledge intensive aspect of most projects and programmes necessitates specialization in management as well as technical work. Specialization acknowledged and established in HybridP3M is the only possible answer to agility demands, such as adaptability, in a group effort.

Secondly, HybridP3M is an advocate of agile product delivery, a designated process with management implications, and which is supported by effective and continuous requirements management. Agile product delivery implies that delivery must be agile, a process outcome, as simple as that. The challenge here is to process-model a distinct agile process that differentiates from existing methods. The alternative is to adopt existing agile methods (i.e. agile delivery processes), like Scrum-based approaches. This happened with PRINCE2-Agile. But these existing methods are either not applicable across industry (usually focus on software development), or fabricate redundant roles and responsibilities such as e.g. Scrum Masters. HybridP3M also believes that the various notions introduced in agile methods can be omitted and that agile delivery should be extreme, always. Just like the agile approach in software development of Extreme Programming (XP). This extreme approach should be combined with a work package management process, typical to PRINCE2, for greater control. This combination represents an agile alternative to agile's interpretation of management control (popular Agile approaches). As a result, HybridP3M resembles PRINCE2-Agile but is more radical, eliminating the need to combine with existing agile methods. Ultimately, the defined project approach decides on the type of solution and / or method of delivering that solution. So basically HybridP3M has adopted a process-model that combines PRINCE2 with XP basics, but more generalized across industry (mainly for system engineering in general).

Agile project management, as opposed to mere delivery, is arguably a myth – it can be agile only to a certain extent. One means to make project management more agile is flexible processes with optional activities, lessening management overhead. Generally, project management has always been traditional and will remain that way. The foundations of the traditional school, originating from management literature, are difficult to question with. The key is to blend traditional project management and to adjust it with agile product delivery. Depending on the delivery model, either predictive or agile, there exist only implications for management, captured by the definition of the management environment. Predictive delivery is by nature less agile. Management is a control discipline, which makes sense as resources and knowledge are scarce or unevenly distributed. Therefore, traditional management is critical to make the right investments, or to abandon ship when things go wrong. Similarly, premature end of a project, a traditional notion, is not necessarily a bad thing, and minimizes sunk costs (costs that no longer can be recovered). The challenge is to develop an integrated P3M solution and HybridP3M answers this call thanks to an enterprise architecture orientation, also known as function orientation.

Given the fact that project and programmes organizations must be adaptible and flexible to change, traditional management must take into account agility. Essentially, traditional management remains the same process of control. Fortunately, well established traditional project management methods have cleared the path for practitioners. However, they all failed to properly understand the agile context. Either they neglect agile or combine the two somewhat artificially like PRINCE2 Agile. Fundamentally speaking, a methodology should incorporate both agile as well as traditional principles. HybridP3M's principles, reflecting this type of blending are introduced in the next section.

 Principles

HybridP3M comprises eleven unique and non-obvious principles, and three obvious – common sense - principles adopted from PRINCE2. The principles are grouped in categories for a better overview. The categories are: management intervention, knowledge management & organizational learning, project characteristics, and corporate ambition. Management interventions includes: 1) Management by Stages, 2) Management by Exception depending on delivery model, 3) Effective Change Management procedure. Knowledge management & organizational learning includes: 4) Learn from Experience, 5) Integrated Knowledge Management, 6) Increasing Learning Capability, and 7) Personal Knowledge Mastery. Project characteristics includes 8) Continued Business Justification, 9) Defined Roles and Responsibilties, 10) Stable, non-ambiguous management environment, and 11) Extensive Project Approach based on selected delivery model. And, finally,  corporate ambition includes: 12) Applied process, function and knowledge orientation, 13) Mature enterprise functions, and 14) Agile mindset complementing a culture of management control.

The obvious principles adopted from PRINCE2 include:

• Continued Business Justification
• Learn from Experience
• Defined Roles & Responsibilties

Management by Stages

Management by Stages is a principle adopted from PRINCE2. It is a traditional principle based on the stage-gate paradigm of projects and programmes. The benefit of this principle is that projects and programmes can be managed according to a life cycle approach, with controlled start, middle and end. Stages are defined by key decision moments, and armed with the dynamic Business Case, the viability of projects and programmes can evaluated based on predefined time bands. Every new stage leads to go-no go decisions, a perfect control mechanism.

Management by Exception depending on delivery model

Management by Exception is based on the assumption that the management level in projects and programmes should intervene only in case original planning is anticipated to be disrupted. Various tolerances determine if intervention is required. This approach frees the project management team and project board from constant involvement in daily project and programme processes. However, it only works well in case of a predictive delivery model where planning provides useful baselines, and thus, effective agreed tolerances. In case of agile delivery, the management by exception principle is compromised. But generally, it holds that exceptions with impact on project and programme outcomes should be managed anyway in terms of issue management, with or without extensive planning. This has to do with the diverse nature of exception, the variety of potential Issues as emergent factors. In other words, not every exception is rooted in planning. The ad hoc nature of management by exception is open to debate. Leadership processes may demand more active involvement of managers, especially in uncertain environments. Tacit knowledge will shape the practical implications of this principle, and thus, scaling can not be neglected.

Effective Change Management procedure

Effective Change Management procedure is essential management overhead required to handle change. Agile responsiveness to change needs to be complemented with formal change procedure for a controlled environment. To this end the PRINCE2 2009 change control procedure is adopted, a modified version of the OGC (2005) change control technique. Issues such as off-specifications, requests for change, and problems / concerns are properly analyzed by this procedure. See OGC (2009), page 95, for more information.

Learn from Experience

Learning from projects and programmes is a natural outcome. In practice, however, a knowledge management problem is that learning is not shared beyond teams, across the organization. To learn from experience is common sense, but in practice learning is limited due to poorly executed project evaluation and limited learning capability of project members. As pointed out by John Dewey: "we do not learn from experience... we learn from reflecting on experience." (Anirban Chatterjee on LinkedIn timeline, 2020). So while this principle is common sense, in practice there are problems with learning. The principle of integrated knowledge management facilitates learning from experience.

Integrated Knowledge Management

In todays Knowledge Economy, the majority of projects and programmes are knowledge intensive. This characteristic combined with organizational knowledge management problems calls for a knowledge management approach as part of the overall project approach. Thanks to the definition of the Projects with Learning Outcomes (ProwLO) methodology, knowledge management in project and programme environments becomes a feasible practice, optimizing knowledge processes within projects and programmes, and beyond.

Increasing Learning Capability

Learning Capability relates to the proficiency of gaining new knowledge from experience. This requires additional reflection, dialogue and discussion. Only with a knowledge management framework additional dedication of time and resources can be rationalized. Because thanks to adopting a formal knowledge management approach, learning becomes part of the project and programme goals.

Personal Knowledge Mastery

Project members should be aware of the power of personal knowledge mastery. With organizational and project and programme processes for knowledge management, effective knowledge application comes down to individual actors engaged in management and specialist processes. So there are multiple levels of knowledge management: at the organizational level, at the project or programme level, at the group or team level, and finally, at the individual level. Personal Knowledge Mastery deals with the individual level. Project members need to be familiar with the essence of knowledge, the diversity of various knowledge types, how knowledge types relate to exploitation of knowledge and creativity. Furthermore, by understanding the life cycle of knowledge they can better relate to the process implications of project knowledge management. For example, when project members gain new experience and thus new knowledge, they, for example, will understand that the organizational value of their knowledge will increase if shared across the organization, or that the applicability in other contexts (i.e. other projects or programmes) will increase if the knowledge is refined resulting to generalization, in the context of knowledge evaluation.

Continued Business Justification

It is common sense to only start viable project and programmes, depending on a Business Case. It is also common sense to premature end a project or programme when costs outweigh claimed benefits. The Business Case is dynamic and subject to internal and external factors affecting viability.

Defined Roles and Responsibilities

Division of labour demands defined roles and responsibilities. It is common sense to sign contracts or acknowledge social contracts related to project and programme work. In HybridP3M, the matrix organization provides a mechanism to establish roles and responsibilities, while project establishment allocates people taking on certain roles and responsibilities. In PRINCE2, the product of Job Descriptions is used for project establishment. In HybridP3M, in contrast, project members have organizational specializations and sign social contracts per process basis, which is less bureaucratic.

Stable, non-ambiguous management environment

The management environment is the total of social convention, common language and formal procedure across project and programme processes. Explicit project documentation, including contracts, reinforces the management environment. The management environment must be stable and non-ambiguous in order to prevent different interpretation of processes and to ensure process consistency. More mature organizations have clearly defined corporate standards that make it easier to adopt a proven management environment. Common understanding of process requirements is a key successfactor.

Extensive Project Approach based on selected delivery model

The Project Approach is a complex management product that shapes project and programme processes. It should at least acknowledge consensus on agile product delivery, specify the delivery model, describe the solution to be developed, and define or provide a reference to the adopted management methodology, like HybridP3M. The Project Approach provides the foundation for social contracts.

Applied process, function and knowledge orientation

HybridP3M advocates a combination of process, function and knowledge orientation. A process orientation on its own, the current status quo, is not enough to guarantee project and programme success. An additional function, or Enterprise Architecture, orientation optimizes information flows between all enterprise functions relevant in the context of project and programmes. It is a tool for As-is and To-be analysis, revealing the intricate complexities of Enterprise Project and Programme Management, and depicting the P3M landscape as the context of projects and programmes. But even a function orientation complementing process orientation has limitations, in particular with regard to knowledge management, which is essential for project excellence. Only an additional knowledge orientation provides the means to institutionalize optimization of processes. Optimization of processes requires state-of-the-art knowledge management in order to solve key KM problems. Systematic learning, characteristic for optimized organizations, can only be realized with sound knowledge management practice.

Mature enterprise functions

High organizational maturity leads to more proficient project and programme processes based on the premise of optimization. Maturity development should thus be part of the mission, vision and strategy of project-dependent and project-driven organizations. Maturity is a multi-dimensional concept consisting of five aspects: 1) Strategy & Policy, 2) Organization & Process, 3) Monitoring & Control, 4) People & Culture and 5) IT (adopted from Scheper, 2002). This implies that adopting processes thanks to definition of a Project Approach on its own is not enough. Other aspects should be taken care of as well, a holistic approach to maturity development is key.

Agile mindset complementing a culture of management control

While a popular concept, agile is prone to different interpretations. Although successful in software development, cross industry applicability is not yet proven (in Turner, Maylor, & Lee-Kelly, 2014). This could be caused by the lack of cross industry approaches. Also, agile approaches are not holistic, with limited reference to project management best practice. Accordingly, agile risks to be a management fad in the long term. To prevent this it is important to acknowledge the dynamic nature of project and programmes, the uncertainty element of change, and the impact of emergent factors, which never can be fully prevented. Awareness of such environment and context of projects and programmes will lead to realization that agility, defined as responsiveness to change and effective change management, can not be neglected. The next step is to make project and programme processes more flexible and adjusted to inevitable change, incorporating agile in a traditional project and programme management methodology. In any case an agile mindset is required. Only with an agile mindset, project members will acknowledge the value of agile processes in the context of a stable management environment, supported by a culture of management control. A culture of management control is a characteristic of mature enterprises. It is enabled by a well defined project approach, institutionalized by adoption of corporate standards, and reinforced by project and programme assurance.

 Knowledge based Project / Programme Management

Knowledge based orientation is a characteristic of organizations with the highest possible level of organizational maturity, generally accepted as level 5 across different maturity models. It is an evolution from process oriented project management, followed by the intermediate: function oriented project management. All three paradigms add up. So knowledge based orientation also includes process orientation and function orientation. Figure 2.1 below presents how these paradigms add up in more detail. The diagram is explained below. HybridP3M is associated with level 5, the optimal situation, but in practice, level 5 demands highest maturity levels across the dimensions of an organization: 1) Strategy & Policy, 2) Organization & Process, 3) Monitoring & Control, 4) People & Culture, and 5) IT. So adopting HybridP3M is just one step of organizational development and requires investment in other areas.

Figure 2.1: Levels of maturity and related concepts

Level 0 is characterized by random activity and lack of paradigmatic orientation. There is very limited understanding of what comprises effective project management, in all its complexity. Management of undertakings is based on a personal approach to management. The best example of level 0 are the projects in the UK Apprentice show, where one team member assumes the role of project manager. In this show projects are characterized by defined objectives and the project manager divides roles on sub-teams. The projects are in fact mini-undertakings with limited complexity, thanks to clear objectives, a small time span, and clear task division.

Level 1 corresponds to an Initial Process. There are signs of process awareness, partly thanks to market available best practice frameworks. Organizations at level 1 typically hire project management staff based on qualification, including specific certification. This is a form of people control. In practice, this approach leads to process diversity, depending on the knowledge and skills of project management staff. A single, uniform corporate approach is lacking. So there is nothing to adhere to, fuelling ad hoc processes. In order to start developing and promoting corporate standards the organization needs to mature further.

Level 2 corresponding to Repeated process is a game changer. There is a basic process orientation, which means that project performance can be rationalized, looking for weak spots in terms of specific processes. Typically, processes are analyzed by the Project Management Office, who is responsible for the development of corporate standards. Based on their work and increasing process awareness by project members project processes can be repeated across projects, but it is not necessarily the norm and relies of individual attitude and competence. Processes are generally immature, meaning not optimized. The effectiveness of managing identified processes is limited. Process improvement is neither structural nor coordinated, despite any possible good intentions of the PMO. The latter is caused by lack of project assurance and poor functional interfaces (communication with the PMO).

Level 3 corresponding to Defined Process is characterized by an advanced process orientation. Processes are well defined and captured in corporate standards. The definition of processes is taken care by a specialist Process Manager, assigned by the Project Management Office. Processes are also monitored by the PMO, and enforced thanks to project assurance by the project board. Promotion of corporate standards is recognized a key responsibility by the PMO who takes this responsibility seriously. The input for process improvement, hower, is limited due to lack of feedback processes from actual projects and programmes. So process improvement is not yet structural.

Level 4 marks a shift towards function orientation. Thanks to a better understanding of enterprise functions and their interfaces an advanced enterprise architecture emerges. Information flows between organizational functions provide valuable input for optimization of processes. Without adequate information flows an organization can never be fully aligned internally and externally. Based on an enterprise perspective driven by functional goals, processes can be managed and improved according to new insight and requirements. Level 4 is not the ideal situation however as there is limited integration of experiences in project processes, and the major pitfall is that the enterprise architecture becomes a static blue print not adaptable to change. It is recommended to delegate enterprise architecture to a specialist Enterprise Architect.

Level 5 corresponding to Optimized Process is characterized by knowledge orientation, that is to say, knowledge based project and programme management. At level 5, organizations are learning organizations that continuously improve conditions and processes. One condition for a successful learning organization is a culture of learning. Another condition are effective knowledge management processes, which are, for example, essential to integrate experience into project processes. Optimized Process implies a balance between exploration and exploitation. Exploration is like learning, while exploitation builds on corporate standards in the form of blue prints and other process artefacts, derived from the lower process and function orientation.