-PRINCE2 is arguably one of the most adopted process-based methods for project management. Currently, PRINCE2 is defined in a textual specification, which describes the principles, the themes, and the processes that project managers should apply in their management activities. Although the specification is well structured and mature, the specification does not provide a browsable digital representation that can be interactively used for learning and/or for the specification application during project management activities. This paper aims to overcome these limitations with the application of a modelbased systems engineering approach to represent the PRINCE2 specification in a model-based format. This can bring several benefits to the specification, including the availability of a graphical, comprehensive and digitally browsable visualization of the PRINCE2 processes, their inputs/outputs, and the constituting tasks. The modelbased format has been obtained by a top-down mapping of the PRINCE2 specifications, beginning with the process architecture in IDEF0 down to the individual tasks, roles, and tools in BPMN 2.0. Besides supporting PRINCE2 understanding and application, the model-based format can also serve as a baseline for further exploitations, such as consistency verification of the PRINCE2 specification and model-based process simulation for the governance of the PRINCE2 processes and of the project management activities.
Copyright © held by the author.
INTRODUCTION
Project management methodologies have been
increasingly adopted to structure, monitor, control, and
execute temporary and cross-functional organizational
activities in order to support managers with the
information, tools, and processes to increase
predictability in the delivery of the expected output.
These methodologies have also been shown to increase
the overall efficiency in terms of resource optimization,
risk management, and cost management [
Rome, Italy
dambro@uniroma2.it
performance indicators and the maturity level of the
adopted project management methodology [
PRINCE2 is arguably one of the most adopted standard project management methodologies in various systems engineering domains. PRINCE2 has been more and more adopted since 2009, for three reasons: 1. the overall trend of business to use a projectbased approach to develop products or transformations within increasingly collaborative contexts with multiple partners; 2. the overall trend of capitalizing on knowledge of best practices in project management; 3. the inherent PRINCE2 characteristics, such as the general approach (i.e. application/domain independent), the product-based planning or the product breakdown structuring.
However, PRINCE2 is still relatively complex to learn
and to apply as the specification sequentially presents all
the PRINCE2 elements (particularly the processes),
which are highly interleaved during a PRINCE2 project
execution. As a consequence, the project manager is
required to build a detailed mental map of the
interconnections to directly access the relevant parts of
the specifications. Expert project managers, who have
been using PRINCE2 for ten or more years, have likely
mastered all these interconnections. However, younger
and aspiring project managers may require more
assistance and time to become fully familiar with these
interconnections. In the wider systems engineering
community, model-based approaches have often been
introduced to represent document-based specifications
with the implicit objectives of providing an automated
processing, a direct (i.e. non linear access to the
individual parts), and an integration with other
supporting tools for decision making [
In this paper, we apply a model-based systems engineering approach to the representation of PRINCE2 in order to facilitate the communication, the understanding, and the application of the PRINCE2 method. Our model-based approach consists of: IDEF0 diagrams for the representation of the PRINCE2 process architecture; BPMN diagrams for the detailed description of the PRINCE2 processes; a set of supporting tables to further assist the project manager in reading the model and in following the development of the project in PRINCE2.
The paper is structured as follows. The background section provides the fundamental terminology used in PRINCE2 and in business process modeling. The related work section positions this paper’s contribution with respect to the state-of-art. The method section illustrates and motivates the model organization, from the architecture to the details of PRINCE2. Finally, the conclusion section provides closing remarks and directions for further developments.
II.
BACKGROUND
This section briefly recalls the main concepts introduced by project management methodologies (i.e., PRINCE2), modeling methodologies (i.e., IDEF0) and modeling languages (i.e., BPMN).
PRINCE2 has been introduced in 2006 by the UK’s
Department of Commerce, and is now developed by
AXELOS [
PRINCE2 consists of the following elements: seven principles—which define the fundamental rules satisfied by the following elements; seven themes—which define the areas of concerns in a project; and seven inter-linked processes—which define the activities to be performed during the project life-cycle, seven themes, and seven processes; nine roles (e.g. project manager, supplier, customer, executive, team, etc.)—which define the responsibilities in the project; and 26 internal project products (business case, project plan, risk register, etc.)—which inherently define the dependencies among the processes. Fig. 1 shows the seven processes along the four stages of a PRINCE2 process and the three levels of actions (directing, managing, executing).
The Pre-project phase regards the preliminary evaluation of the validity and the convenience of project. In this phase, the process SU develops two key documents: Project Brief and Plan for the Beginning of the Project. These documents are taken as input by the process DP, in which the project board assesses the plan to decide whether or not to authorize the project. In the positive case, the project execution moves to the Initiation stage phase, in which the processes IP and SB are implemented. The former produces several internal project documents, such as detailed business cases (from the initial project brief) and guidelines to assess the achievement of the expected benefits. Differently, the process SB produces a detailed planning for the execution of the following stage.
IDEF refers to a family of modeling methodologies
widely adopted in the field of systems and software
engineering [
However, IDEF0 also allows the use of supplementary material, also known as FEO (For Exposition Only) pages, which can be used to represent flow diagrams or technical design using any formalism.
Graphically, a diagram consists of a frame, and one or more boxes and arrows. Asides from delimiting the area for the drawing of boxes and arrows, the frame provides also a preassigned location for the diagram name. For the top-level (or context) diagram defining the overall process, the name must be “A-0”. This diagram “declares” the process and also indicates the parameters related to the model purpose and scope, which are needed to check the consistency and appropriateness of child diagrams. The first child diagram must be named “A0” and defines the composition of overall process. This diagram must contain between 3 and 6 activities, which boxes are to be located on the upper-left/lower-right diagonal of the diagram’s frame, following a temporal order in the development of the activities. Further child diagrams can be introduced by recursively detailing an activity already defined in one diagram. For each child diagram, a DRE (Detail Reference Expression) is to be used as part of a diagram name to link the diagrams. This expression corresponds to the unique and hierarchically-structured numeric identifier placed at the bottom-right corner of the box representing the activity. Concerning the arrows, these can be used to represent dependencies of input/output, on external conditions, or on resources. Graphically, these dependencies lead to the following type of arrows (Fig.2): • Input: incoming arrow into the left side of the box.
This arrow represents data or objects that are transformed by the activity; • Output: outgoing arrow from the right side. This arrow represents the output produced by the activity. • Controls (or Constraints): incoming arrow from the top of the box. This arrow represents external conditions (e.g. norms, procedures, regulations, etc.) that are required for the activity to be successfully developed. • Mechanisms (or Resources): incoming arrow from the bottom of the box. This arrow represents the means or resources (machinery, information systems, humar resources, etc.) needed to perform the activity. • Recall (o Call): outgoing arrow from the bottom of the box. This arrow represents that the activity relies on an activity already defined somewhere else in the model or in another model.
In an IDEF0 model, each arrow should also be associated to a label which indicates the nature of the dependency. Moreover, arrow lines are enforced either to maintain a straight horizontal line or to break into horizontal segments that are connected by perpendicular lines.
The BPMN notation has been defined to introduce a
modeling language that could be easily understood by
business users (e.g. managers, process owners, business
analysts, etc.), as well as by technical users (e.g. IT
analysts, IT developers, etc.) [
A BPD is a directed graph composed of flow objects and connecting objects. A flow object is the main describing elements within BPMN, and can be an event (something that happens), an activity (process step) or a gateway (the divergence and convergence of execution flows). A connecting object is a line that connects BPMN flow objects to specify the flow of activities in a process.
To organize activities in a process model, BPMN provides the swimlane primitive, which is used to represent roles, responsibilities and/or organizational structures by means of pools (organizations) and lanes (structures within an organization).
Finally, the BPMN notation also provides means to represent information. Artifacts represent information relevant to the model but not to individual elements within the process. Actually, they are used to augment and describe a BPMN process. There are three artifact types: annotations (to represent additional flow parts of the model), groups (to organize tasks or processes), and data objects (to specify input, output or stored data).
Fig. 3 summarizes the main elements of a BPD specified by use of BPMN.
Model-based systems engineering (MBSE)
approaches have been widely applied to various systems
engineering domains and activities as these approaches
have shown increasingly benefits with respect to the
conventional document-based approaches [
Communication improvement through a visual, shared, and unambiguous representation of the final system for the entire engineering team; Risk reduction in the development process through the progressive and continuous validation of requirements and of the verification of proposed solution (for example via integrated simulation or formal verification) Quality improvement through a rigorous and computer-managed traceability of the specification integrity and consistency over the entire development process • Productivity improvement, through a prompt availability of traceability and impact analysis scope, including also the increased reuse of software and system components from the model specification level already, and the automatic generation of code for software systems.
Leveraging on the above benefits, model-based
systems engineering approaches have been applied to
business processes engineering, which can be radical
(Business Process Reengineering, BPR) or incremental
(Business Process Improvement, BPI). Various works
can be found in literature about case studies, industrial
applications, technologies, and methodologies related to
model-based approaches. More rarely, these approaches
have been applied to support project management,
which has historically focused on the collection of
lessons learned and in the definition of tools for, e.g.,
planning, estimation and risk management. This paper
bridges the areas of model-based systems engineering
and project management with the application of a
model-based approach to the specification of a project
management method consisting of roles, principles,
project artefacts, and processes. Although the
application of MBSE is not new to support project
management (see, e.g., the model-based approach to
support the integration of aircraft systems described in
[
IV.
The model-based representation has been developed top-down in three steps: 1. Development of a process architecture in IDEF0, to identify the high-level processes and their interrelationships. 2. For each top-level process, one or more BPMN diagrams were developed to show the activities, the internal documents produced, and the communication and synchronization with other processes. 3. Development of tables and matrices for an immediate indexing of all the diagrams, to further ease the use of the model-based specification of PRINCE2.
IDEF0 was selected for the representation of the process architecture as this language allows the organic and systematic representation of models with an increasingly level of details. Moreover, this language inherently highlights the functional dependencies rather than the temporal dependencies, which can conversely be better represented in BPMN. Within this work, the objectives of the process architecture are to: • provide the users with a synthetic and conformant representation of PRINCE2 • highlight the various high-level activities performed in a PRINCE2 project • formalize the process interdependencies to provide an overarching framework that could provide a “starting point” for the detailed modeling and an “end point” for overall consistency verification. • define the responsibility areas uniquely • understand how resources are used • identify key controls
For completeness, we first represented the PRINCE2 function as the IDEF0 A-0 diagram, which is shown in Fig. 4.
Next, the process architecture has been developed in three steps and two levels of details (phases and processes). The first step deals with the functional breakdown of all the PRINCE2 phases and processes (see Fig. 5), the second with the representation of phases and the third step with the representation of processes.
Fig. 5 illustrates the diagram representing the following PRINCE2 project phases: Pre-project (A1),
Fig.6 instead represents the four PRINCE2 phases and their interrelations according to a temporal decomposition (i.e. each block groups the lower level processes by a temporal proximity rather than a functional similarity).
Although this approach is theoretically debatable, it offers the most intuitive representation for project managers, who are primarily concerned with a temporally sequential access to the model.
The IDEF0 diagram also highlights the required resources in each phase and the expected conditions needed for their successful implementation. Consequently, with only one figure, the project manager can quickly acquire a more comprehensive view on the respective part of the PRINCE2 specification.
Fig. 7. IDEF0 Second Level – Expansion of A2 Process (Initiation Stage) Each A0 activity block is then detailed into a more refined IDEF0 diagram. For the sake of conciseness, only activity A2 (Fig.7) and A3 (Fig.8) are detailed in this paper. These diagrams represent the interrelationships among the PRINCE2 processes activated in the initiation and subsequent delivery stages. As both stages involve the invocation of the process “Directing a Project”, the respective block activity is included in both diagrams. Inherently, this double presence also explains the complexity in managing the lower level BPMN diagram: the same PRINCE2 process is activated in various points by different events. The supporting tables will ensure that the project manager is provided with full guidance for the identification of the lower level diagrams. With a basic understanding of the IDEF0 formalism, all the above diagrams can be immediately read also by a novice IDEF0 user, and therefore their accurate narration is left to the interest reader.
The seven PRINCE2 processes are represented by a
set of BPDs in BPMN. The BPD allows for a higher
accuracy in the semantics of the activities to be
performed, as well as of the interdependencies.
Moreover, BPMN also provides symbols to represents
events and data, both essential for the definition of
process interdependencies. BPD diagrams have been
specified according to the modeling guidelines
introduced in [
BPMN intrinsically ensures the traceability by use of
hyperlinks provided by modeling tools (ADONIS in this
paper case [
Eventually, the whole BPMN model resulted into a hundred diagrams. Fig. 9 and Fig. 10 show the BPDs of the processes “Initiating a Project” (A21) and “Directing a Project” (A12, A22, A34, A44), respectively. These processes are synchronized through the event “Request to Run a Project”, which is triggered by the former process and catched by the latter one. This key integration aspect can be immediately inferred in both diagrams by noticing the respective relationships between the process pools and the triggering/catching event symbols.
The above IDEF0 and BPMN diagrams completely represent the whole PRINCE2 specification. As these diagrams are in a machine readable format, they can be opened with the relevant modeling tools and be directly navigated through the hyperlinks inherently associated to the model elements. Currently, most of the project management tools focus on the definition of project plans or on the KPI-based monitoring/tracking of project performance. Differently, the project execution requires a pervasive human intervention in the implementation of the tasks, and therefore it has received less attention for automation opportunities. Consequently, when using the paper-based version of the model, a project manager can further benefit from indexing means to identify which diagram(s) are to be retrieved. The indexing is particularly needed for two reasons. The first reason is that the IDEF diagrams provide a functional breakdown that is to be linked to the lower level time-oriented BPMN diagrams. The second reason is that the BPMN diagrams are numerous and are not accessed sequentially. For example, the project manager may want to know which project actors are to be involved in a process, or which processes should be started as a consequence of an event occurring, or which process(es) produces or consumes an internal product of the project activity. In particular, the following types of tables and matrices are made available along with the PRINCE2’s IDEF0 and BPMN diagrams: • an Overview Table, which describes the key features of the process, including the purpose, the triggering event, the involved actors, the list of the activities, the triggered processes, and the produced/consumed internal project output. The project manager may refer to this table for consultation when preparing a process execution. • an Event Traceability Matrix, which identifies the processes that can trigger an event and the processes that should be activated when that event. The project manager can consult this matrix to identify which process should be executed when an event occurs. • a Product-Process/Activity Traceability Matrix, which identifies the process(es) that creates, confirms, updates, or reviews an internal project product. This matrix also provides references to the actors performing the activity, offering therefore a comprehensive view on all the actions performed on the internal products. For example, the business case is created in the process “Starting a Project”, updated in the processes “Begin the Project” and “Manage Stage Boundary”, and finally it is confirmed in the process “Directing a Project”. • an Activity Summary Table, which shows the list of input and output items for each activity.
Fig. 9. BPD of the process “Initiating a Project” Fig. 10. BPD of the process “Directing a Project”
PRINCE2 is a widely used standard and structured project management methodology that can be applied to various systems engineering application domains. However, the PRINCE2 specifications can be complex to learn and to apply as it defines a large number of interleaved processes and activities that must be orchestrated to implement the project execution. With the objective of easing the learning and the application of the PRINCE2 methodology, we have introduced a model-based specification for the PRINCE2 specification. The specification consists in a process architecture, a set of detailed process diagrams, and a set of indexing tables to directly access the diagrams.
The process architecture has been represented with IDEF0 as the architecture is inherently structured hierarchically in phases, processes, and their interdependencies (inputs/outputs, resources, and enabling conditions). The architecture consists of eight diagrams: one diagram to represent the hierarchical functional breakdown and seven diagrams to represent the PRINCE2 specification from the context to the individual PRINCE2 processes. Each of these processes is mapped onto a detailed BPMN diagram, which is further decomposed to reach the same granularity/detail level to PRINCE2 specification. Overall, about one hundred BPMN diagrams have been developed to cover all the details of the PRINCE2 specification. These diagrams can be immediately and directly accessed by use of a modeling tool, and therefore they offer to the project manager a web-like browsing tool for the entire PRINCE2 specification.
However, only the project management activities related to monitoring & control or to project planning are currently supported by automated tools. Project execution activities are specifically carried out without any tool support, as these activities often require sound judgement and specialist knowledge that are difficult to automate by use of a software tool. Consequently, we have also introduced a set of tables and matrices (overview table, event traceability matrix, productprocess matrix, activity summary table) to ease the manual access of the diagrams. These tables and matrices provide synthesized information on the diagrams and a reference to the relevant diagrams. As an example, an overview table summarizes the key features of each process and activity, providing also a reference to the respective diagrams. Similarly, the event traceability matrix provides the project manager with the information on which events can be triggered by which process and which process is triggered by the events.
Asides from the above motivations and advantages, the model-based approach can contribute to provide a wide number of additional benefits, such as communication improvement, quality improvement, risk reduction, etc., which are commonly experienced when applying model-based systems engineering to the analysis and design of complex socio-technical systems.
Moreover, once the PRINCE2 specification is in a
machine-readable format, further exploitations can be
easily obtained also with current tools and technologies.
In line with the current capabilities of model-based
systems and simulation engineering [