implementing rational unified process within a prince2 envir

Implementing Rational Unified Process Within A PRINCE2 Environment

Laurence Archer

31st October 2001

Copyright © 2001 Oak Management Services All Rights Reserved

www.oakms.com www.oakms.com.au

http://www.oakms.com/

http://www.oakms.com.au/

Implementing RUP within PRINCE2

Table of contents ABSTRACT ..................................................................................................3

ACKNOWLEDGEMENTS ................................................................................4

INTRODUCTION .............................................................................................4

PRINCE........................................................................................................5 RUP..............................................................................................................5 Why PRINCE and RUP ................................................................................6

THE BUSINESS CONTEXT.............................................................................7

Implementing change in the modern business environment ........................7 Three levels for managing business change ................................................8

THE ROLE OF METHODOLOGIES ................................................................9

Maximising team effectiveness.....................................................................9 Using multiple methodologies.....................................................................10 Achieving compatibility between methodologies ........................................11

COMBINING PRINCE AND RUP...................................................................14

Creating a match ........................................................................................14 Terminology................................................................................................15 Guiding principles.......................................................................................15 Roles & responsibilities ..............................................................................17 Processes, disciplines and workflows ........................................................19 Deliverables, products and artifacts ...........................................................20 Guidelines, tools and techniques................................................................22 Summary of changes required ...................................................................23

RECOMMENDED APPROACH FOR COMBINING PRINCE AND RUP .......26

Keeping PRINCE and RUP distinct ............................................................26 Company methodology first or project methodology first ?.........................26

PLANNING AND MANAGING THE IMPLEMENTATION...............................27

Assess the development organisation........................................................28 Create a methodology environment ...........................................................28 Develop the capabilities .............................................................................29 Implement project assurance, controls and measures ...............................29

WHAT NEXT ?...............................................................................................30

APPENDIX A: BRIEF INTRODUCTION TO PRINCE.................................................31

APPENDIX B: BRIEF INTRODUCTION TO THE RATIONAL UNIFIED PROCESS (RUP) ..36

APPENDIX C: INTRODUCTION TO ITERATIVE DEVELOPMENT ..................................42

BIBLIOGRAPHY ............................................................................................44

ABOUT THE AUTHOR ..................................................................................45


ABSTRACT This paper discusses the possibility of implementing the Rational Unified Process (RUP), a specialist software engineering methodology, within PRINCE, a generic project management environment. RUP and PRINCE have principally been chosen because they represent the best of breed methodologies for their respective areas of competence. We look at some of the concepts behind management of business change and the history of project management and software development. We describe the three distinct management levels at which business change is accomplished, namely: • Programme management • Project management • Specialist management (such as software engineering) We look at the role of methodologies in providing a framework and environment that maximises the effectiveness of project teams. We also note that there are no generally accepted methodologies that provide adequate support for all levels. It is therefore necessary to combine different methodologies to achieve the level of management control that is needed. We propose that the following criteria determine whether two methodologies can be combined • Terminology • Guiding Principles • Roles and Responsibilities • Processes and disciplines • Products, artifacts, deliverables • Guidelines, tools and techniques We compare PRINCE and RUP using these criteria, and conclude that the two methods afford a high degree of compatibility and can be used together at the project management level and the specialist management level, provided a number of changes are made in order to clarify the interface between the two levels. The following concepts can be added to the combined model to make it more effective.

• Introduction of a stage called “Design the Project”. This includes both project initiation and

environment preparation • Extend the approach recommended by Rational Software for implementing RUP to

implement RUP within PRINCE • Use Rational Software’s browser based tool kit to document and communicate both RUP

and PRINCE We look at a possible approach for implementing the two methodologies, keeping them distinct and with clear interfaces. We see that implementing RUP and PRINCE constitutes a programme of business change. The main outcomes are creating a road map for change, implementing the environment, generating the capabilities and establishing assurance and controls. Once PRINCE and RUP have been implemented and combined, the way is opened for adding a third method, such as MSP, at the programme management level. The appendices to this document contain a brief introduction to PRINCE and to the Rational Unified Process and a brief discussion of the advantages of iterative development.


ACKNOWLEDGEMENTS Although PRINCE is available freely in the public domain, PRINCE® is a registered trademark of the Office of Government Commerce (OGC). Further information on PRINCE2 is available on the OGC Website on http://www.ogc.gov.uk/prince/

This paper is based on PRINCE2, a revised version of PRINCE. Rational Unified Process (RUP) is a trademark of Rational Software Corporation. Further information about RUP is available from the Rational Software website on http://www.rational.com/products/rup/index.jsp This paper is based on RUP version 2001A.04.00 The author acknowledges Simon Drury, Paul Jones and Simon Turner, all of Oak Management Services, for their invaluable help in creating this work.

INTRODUCTION Background This paper comes about in response to the perceived need to deploy best of breed software engineering methods together with more generic but widely adopted project management approaches, so that software development initiatives can be integrated within overall programmes of business change. Iterative development, object oriented analysis and design, component based architectures, visual modelling, automated testing, change and configuration control are only some of the concepts that have contributed to making software engineering the effective and highly specialised discipline it is today. This degree of specialisation has also generated the need and opportunity for the development of a number of methods that are focused on the specialist nature of the task rather than on the generic nature of projects. These methods prescribe “how to develop software” rather than “how to conduct projects”. While the software engineering industry developed disciplines and methodologies that addressed the specific issues and challenges of software development, project management disciplines also evolved. New methods have been introduced for managing projects that are generic and flexible enough to be applicable to a wide range of projects, from building bridges to moving companies. These days organisations require business change to be implemented frequently and quickly via programmes of interdependent projects. These often include but are not limited to the development of computer software. Specialist software engineering disciplines and generic project management methods have to learn to coexist so that the different types of change initiatives can be coordinated effectively. This document considers a generic project management method, PRINCE, and a specialist software engineering method, the Rational Unified Process (RUP), and looks at how they can be combined in order to successfully manage software development projects within programmes of business change. We believe that this approach can also be used for combining other methodologies.

http://www.ogc.gov.uk/prince/

http://www.rational.com/products/rup/index.jsp


PRINCE PRINCE (PRojects IN Controlled Environments) is a generic structured method for effective project management. It was developed by the UK Government’s Central Computer and Telecommunications Agency (CCTA), which is now incorporated into the Office of Government Commerce (OGC). It is a de facto standard used extensively by the UK Government. It is also widely recognised and used in the private sector, both in the UK and internationally. PRINCE is applicable to a wide variety of projects, not just software projects. In fact the PRINCE documentation states that

“PRINCE covers the management of the project, and the management of the resources involved in carrying out the activities of the project. It does not cover the specialist techniques involved in the creation of the products. This is the job of other methods, although PRINCE must interface with them to enable information on such areas as estimating, for example, to be provided for project management.” PRINCE is based on the premise that: • Projects are finite, they have a defined beginning, middle (execution) and end • Projects have to be managed in order to be delivered successfully • Projects involve a number of different parties all of whom must have a clear

understanding and agreement on why the project is being carried out, what the desired outcomes are and who is responsible for what

The guiding principles of PRINCE are: • Focus on business justification • Using a defined organisation structure including a Project Board that represents the

interests of the sponsor, of the business users and of the supplier • Product based planning approach • Dividing a project into manageable and controllable stages, which always include a

project initiation stage • The Project Manager has a delegated level of authority, above the Project Manager the

Project Board manages by exception A more detailed description of PRINCE is given in Appendix A.

RUP The Rational Unified Process (RUP) is a proprietary methodology described as a “software engineering Process”. Rational Software’s suite of software engineering tools and techniques fully support RUP. The guiding principles of RUP are expressed in terms of the following best practices. • Iterative development • Requirements management • Quality verification and testing • Change and configuration control • Component based architectures • Visual modelling techniques and tools A more detailed description of RUP is given in Appendix B.


The most important guiding principle of RUP is iterative development. It is essential in combining PRINCE and RUP that the principle of iterative development is maintained. Appendix C contains a brief discussion of the concept of iterative development and how it helps to address some of the most important problems with software development.

Why PRINCE and RUP These two methodologies were chosen for this work for the following reasons: PRINCE is a generic project management methodology, it can be used for any type of

project and can therefore be the channel for coordinating different types of work within programmes of business change

PRINCE is specifically designed to be used in conjunction with “specialist methodologies” such as RUP. It does not have any “specialist” content

PRINCE is widely used in UK, where it has become a de-facto standard, and is rapidly being adopted overseas. This will maximise the benefits that can arise from applying the findings and recommendations of this paper

PRINCE is in the public domain, it is widely available for further development arising from this paper, and can easily be adopted by organisations wishing to do so

The Rational Unified Process (RUP) is a top-of-breed software engineering methodology RUP is one of the prime exponents of iterative development which, as explained in

Appendix C, can be instrumental in addressing some of the most important problems with contemporary software development

RUP provides access to Rational Software’s suite of tools and techniques and provides a framework for using them effectively. The benefits of using RUP therefore extend beyond those of the method itself

Although RUP is proprietary to Rational Software, it is sufficiently exemplary of the current trends in software engineering for the findings and recommendations of this paper to be applicable also for combining other specialist methodologies, such as DSDM, with PRINCE

This paper focuses on using two methodologies, for generic project management and specialist software engineering. PRINCE provides sufficient hooks for subsequent integration of a programme management methodology, such as MSP, also developed by the CCTA


THE BUSINESS CONTEXT There was a time when managing a business consisted of maintaining a reasonably steady course, with an occasional shift in direction to adjust to changes in the prevailing market conditions, in order to adapt to a new technology or absorb a new competitor. Making changes to the business was an exception rather than the rule. Nowadays organisations keep up with the ever-increasing pace of the competition by continually introducing new products and services, reviewing and improving their processes, re-organising and re-skilling their people. Change has become the rule, a business that does not change rapidly and effectively gets left behind.

Implementing change in the modern business environment Change is a response to market drivers. It is first identified and defined as a strategic business objective, which generally has the purpose of delivering tangible business benefits such as increasing profit, reducing business risk and maintaining alignment with regulatory requirements or business strategy. Two characteristics of strategic change are that there is usually a limited time available to implement the change so as not to be left behind (time to market) and the exact nature of the change is not fully understood at the time it is initiated; it takes shape and becomes clearer while it is being developed. A simplified model states that strategic business objectives are accomplished by re-aligning three components: people, processes (what people do) and tools (what people use). Implementing change is not simple. Projects are the vehicle via which change is accomplished. Projects consist of a set of organised and coordinated activities that are performed to produce a desired business outcome. In a business environment where change has become paramount to business survival, the ability to successfully manage and deliver projects is the key to success. Implementing strategic change is even more complex. Multiple interdependent projects are required in order to implement a change in business strategy. The people side of the equation alone could contain elements such as skills, culture, organisation, location, virtual organisation, hiring and firing, training, leadership etc. Different aspects of the business need to be changed in a coordinated fashion so as to contribute towards the accomplishment of a business strategic goal. There may be people projects, process projects and tools projects. The management discipline that manages multiple interdependent projects in order to achieve a strategic business objective is called “managing programmes of business change”, or “programme management”. Programme management focuses on accomplishment of strategic business objectives, realisation of tangible business benefits and coordination of multiple interdependent projects. The link between the strategic business objective, the programme of business change and the individual projects is the “blueprint for change”, a roadmap indicating all the changes that need to be accomplished, how they are related and how they are grouped into a set of “change initiatives”. Each change initiative within a programme of business change constitutes a project, which also requires a degree of specialisation and specialist management depending on its nature. Software development projects require specialist skills and specialist management known as software engineering.


Three levels for managing business change As can be seen in the previous section, there are three management levels at which strategic business objectives are accomplished via change. Programme management focuses on achieving the strategic business objectives. It

includes creating and maintaining a “blueprint for change” that defines the change initiatives and their inter-relatedness, creating and coordinating multiple interdependent projects and realising tangible business benefits.

Project management focuses on one specific project, producing agreed outcomes within

time and budget. There is a common approach for managing most projects, irrespective of their specialist nature. This consists of agreeing scope, objectives, timescale, budget and tolerance, defining the organisation and the project lifecycle, managing stakeholders, planning and controlling tasks and activities, managing risks, changes and quality.

Specialist management is related to the specialist skills required depending on the nature

of the project. Although this paper focuses on software engineering, or the specialist discipline of developing or modifying computer software, multiple types of specialist skills and specialist management may be required within a programme of business change.

The three levels of management take place concurrently, but may be initiated in sequence.

Multiple interdependent projects are required in order to implement a change in business strategy.

Project Organisation

Project Lifecycle Management

Stakeholder Management

Planning

Controls

Risk Management

Change Request Management

Quality Management

Project Management

Three levels of managing business change

Specialist Mgmt

Programme Management

software engineering includes disciplines such as:

•Requirements Management

•System Architecture

•Modelling and design

•Testing and verification

•Configuration Control

Define the blueprint for change

Benefits Realisation Management

Coordinating multiple interdependent projects

Managing business priorities




Planning

Controls

Risk Management


Quality Management

Project Management


Specialist Mgmt















Planning

Controls

Risk Management


Quality Management

Project Management


Specialist Mgmt













THE ROLE OF METHODOLOGIES “I keep six honest serving men They taught me all I know Their names are What? and Why? and When? And How? and Where? And Who?” Rudyard Kipling The Just So Poems

Maximising team effectiveness Projects can be likened to “cooperative games” (see bibliography for more on this). They are complex endeavours that are performed in coordinated fashion by one or more teams of individuals, one of whom is the Project Manager. Each individual performs a defined set of activities to produce a defined set of outcomes, or products. Each of these products either contributes to the performance and quality of another activity or is part of an aggregate product eventually leading to the overall project outcome. In order for the project to be completed successfully, it is necessary to define and communicate to all participants what its desired outcome is (the project’s scope and objectives), so that everyone is aligned towards a common goal. It is also necessary, however, to ensure that there is a clear and shared understanding of how the game will be played. This shared understanding is the project’s methodology. The project’s methodology describes the project lifecycle, processes and activities, products, roles, management controls, quality controls, risk management approaches, relevant techniques and any other aspect that is relevant towards ensuring that everyone contributes fully to the project’s success. In general, a project’s methodology is defined during the initial stages of the project, and is typically based on a more general methodology that may have been developed or adopted by the organisation. It is important to distinguish, however, between a generic methodology and the customised version of the methodology that is defined for a specific project. Another view of methodologies is that they provide the “rules of the game” in terms of: • Creating a common language or terminology • Providing a set of guiding principles • Defining organisation, roles and responsibilities • Describing a set of disciplines, or a repeatable process • Defining the deliverables or products • Providing a link to specialist tools and techniques Methodologies apply to each level of managing business change. A software development project within a programme of business change requires:


• A programme management methodology (how the overall programme will be managed to ensure business benefits are realised)

• A project management methodology (how the project will be planned, managed and controlled)

• A specialist management methodology (how the software will be developed)

Using multiple methodologies We have seen that there are three levels at which business change is implemented, we called them programme management, project management and specialist management (of which software engineering is an example). We have also seen that methodologies can be applied at each of these levels. Commercially available “out of the box” methodologies however tend to focus more or less on one specific level, depending on their genesis and purpose. Moreover, most methodologies are not designed to be combined with other methodologies, so they attempt to cover some aspects of other levels as well. For example, although RUP is a specialist methodology, it also includes some components of project management because otherwise it would not be applicable on its own. In the same way as projects are no longer conducted in isolation, but within programmes of business change, it can also be stated that most organisations cannot limit themselves to having one methodology, but need to establish a methodology for each of the three levels. In order to achieve this it becomes necessary to select an appropriate methodology for each level, compare them and resolve any difference and overlap so that they can be used effectively together. As the following diagram shows, there will inevitably be areas of overlap and unclear interfaces between methodologies that are not meant to be combined.

Prog

ram

me

Proj

ect

Spec

ialis

t

RUP

PRINCE

ProgrammeManagement

undefined interfaces

Prog

ram

me

Proj

ect

Spec

ialis

t

RUP

PRINCE

ProgrammeManagement


Prog

ram

me

Proj

ect

Spec

ialis

t

RUP

PRINCE

ProgrammeManagement



Achieving compatibility between methodologies Before different methodologies can be integrated, they must be compared in order to establish that they are compatible. It is likely that a number of changes are required to areas of overlap in order to clarify the interface, as in the following diagram.

y examining the attributes of methodologies we can identify the following set of criteria that

erminology

erminology defines the language used by communities of practice in order to communicate

community of practice is a group of people that have developed, typically via use, a each

he practitioners of a particular methodology constitute a community of practice. Sometimes

ey

hen different communities of practice come into contact, they each take their own context n

ince terminology cannot be changed or adapted, compatibility of terminology is of the utmost

Prog

ram

me

Proj

ect

Spec

ialis

t

defined interfaces

RUP

PRINCE

ProgrammeManagement

Prog

ram

me

Proj

ect

Spec

ialis

t

defined interfaces

RUP

PRINCE

ProgrammeManagement

Bcan be used to verify the compatibility between methodologies and identify changes required. T Tand exchange information easily and effectively within a shared and commonly understood context. Acommon knowledge, language and terminology. These people do not necessarily knowother, but the terminology enables them to communicate effectively as and when they need to. The terminology is part of the identity of the community of practice, it develops over the years and cannot be modified or re-defined easily. Torganisations adopt a specific methodology in order to gain access to the people, the skills and the experience that make up the community of practice. This would not be possible if thadopted a different terminology. Wand terminology with them. If the same term has a different meaning for each community thethere is a risk of misunderstanding. Nobody would be aware of this risk, since everyone knows the meaning of the term and assumes the same for everyone else. Simportance. Any problems and risks in this area would be very difficult to deal with effectively. An example of such a problem was when the Mars probe failed due to confusion between using metric and imperial units of measurement in its design.


Terminology is only really incompatible when different methodologies attach different meanings to the same term, thus contradicting each other. On the other hand different methodologies often use different names for similar concepts, such as in the case of “Product” in PRINCE and “Artifact” in RUP (also defined as “Deliverable” in other methodologies). Inconsistency does not make methodologies incompatible, and it can be resolved by adopting a common glossary. New terms can be learned without modifying the ones we already know. In fact this can constitute an opportunity for enriching our language.

Guiding principles Methodologies include “guiding principles”. These define “the important things” which have to be adhered to if the methodology is to retain its identity and usefulness. Compatibility of guiding principles is important because contradictions in this area are difficult to resolve. Usually methodologies would only prescribe guiding principles that are relevant for the appropriate level of management. For example RUP includes a number of guiding principles that are specific to software engineering. There are cases however where the guiding principles of different methodologies overlap and need to be compatible. For example the RUP guiding principle of iterative development refers to the type of lifecycle, and overlaps with the PRINCE guiding principle of dividing a project into manageable stages. Methodologies can be incompatible if a guiding principle prescribed by the one contradicts a guiding principle prescribed by the other. Roles and responsibilities Methodologies also prescribe a number of roles that have to be played out by the project team members, and what they are responsible for. Clearly defined and communicated roles and responsibilities are a key to obtaining the level of collaboration and responsibility from each team member that is required to successfully deliver the project. Again there can be incompatibility if two methodologies define a common role but with contradictory responsibilities. Most roles would normally sit within a specific level, be it programme management roles, project management roles or specialist roles. Some roles, such as that of the Project Manager may overlap with more than one level. Roles do not equate to individual people, they equate to “acts” that people “play” while working on the project. An individual can perform more than one role. Most roles (with the notable exception of the Project Manager) can be shared amongst different actors. It is not necessary, therefore, that different methodologies assign the same responsibilities to the same roles.


Disciplines, processes or workflows

Methodologies also prescribe a set of disciplines. These consist of descriptions of the main tasks or activities, the products (or artifacts) produced and the roles responsible for these products. These disciplines are also termed processes or workflows. With most methodologies it is expected that the disciplines be adapted and modified while implementing the methodology for a particular organisation or project. The level of compatibility “out of the box” is therefore less critical, disciplines can be made compatible by adaptation. Disciplines can be classified as programme management disciplines, project management disciplines or specialist disciplines.

Deliverables, products or artifacts

Products or artifacts can also be classified as programme management products, project management products and specialist (or technical) products. Most programme management and project management products are prescribed by the relevant methodologies, and are mandatory for each project. Examples of these are a document defining the scope, objectives and approach of the project (the P.I.D. in PRINCE, the development case in RUP), the project plan, the risk list, the issues list, the change management log and so on. The specialist (or technical) artifacts and products to be produced in a given project are subject to a high degree of customisation, any issue of compatibility between the specialist products prescribed by different methodologies can usually be resolved on a project by project basis. Guidelines, tools and techniques

Most methodologies include guidelines, tools and techniques. Again we can classify guidelines, tools and techniques as being relevant to programme management, project management or the specialist content. Generally speaking, the guidelines, tools and techniques that are most distinctive of a methodology are those that are also highly specialised. There is little likelihood of contradiction or incompatibility where guidelines, tools and techniques overlap. Where there is an overlap it is usually possible to resolve it by customising the guidelines, tools and techniques specific for the organisation or project.


COMBINING PRINCE AND RUP PRINCE and RUP are designed for project management and specialist management respectively. PRINCE provides the disciplines for managing activities and resources. It also overlaps with programme management via the process “Direct the Project”, which consists of providing a direction for the project based on business needs and the realisation of tangible business benefits, distinct from the task of managing the project. RUP provides the specialist disciplines, tools, techniques and roles for performing software engineering. However RUP also includes a project management discipline and project management roles, artifacts and the guiding principle of iterative development, which overlap with the project management level.

Creating a match The following sections apply the criteria for establishing compatibility and provide recommendations on any changes required in order to make it possible to use the two methodologies together effectively.

Proj

ect

Spec

ialis

t

PRINCE

RUP

Proj

ect

Spec

ialis

t

PRINCE

RUP

Proj

ect

Spec

ialis

t

PRINCE

RUP

Proj

ect

Proj

ect

Spec

ialis

tSp

ecia

list

PRINCEPRINCE

RUPRUP

Terminology

Guiding principles

Roles

Disciplines

Products

Tools and techniques

Terminology

Guiding principles

Roles

Disciplines

Products


Terminology

Guiding principles

Roles

Disciplines

Products



Terminology As described earlier, terminology is part of the identity of a methodology, it defines the language used by a community of practice. As far as we have been able to ascertain, there are no terms that are used in both methodologies associated with different and contradictory meanings. From this point of view the two terminologies are compatible. There are situations, however, where different terms have been used for the same or very similar concept. For example, PRINCE calls Product what RUP calls Artifact, and PRINCE calls Process what RUP now calls Discipline. There is sufficient difference between the two terminologies to make it advisable to keep each methodology distinct with its own terminology rather than attempt to create a combined terminology. This approach is also advisable for the following reasons: • Both terminologies are still evolving and are subject to change. For example, RUP now

calls “Discipline” the concept that it used to call “Core Workflow” and “Supporting Workflow”, while still identifying “workflows” within each discipline.

• Since both methodologies are established on the market, the terminology is in use within

a larger community of practice than any single organisation or project. Maintaining the distinct terminologies makes it possible to maintain communication and availability of resources and skills.

• There are limited roles that need to be able to communicate using both terminologies,

there is therefore limited impact of maintaining separate terminologies.

Guiding principles PRINCE has a set of guiding principles that link into and overlap partially with the programme management level, they are: • The process “Direct the Project”, linking the project to the business outcomes • The organisation includes a Project Board that manages by exception and represents the

interests of the investor, the users and the supplier • The Project Manager’s delegated authority (tolerance), beyond which an exception is

raised • The customer / supplier relationship There are no equivalent guiding principles within RUP.


At the project management level, the following guiding principles are prescribed by both PRINCE and RUP in ways that are compatible and complementary. • Product based (or component based) planning • Iterative planning (only plan as far as you can see) • Managing change • Managing risk • Managing quality The following guiding principles are defined in slightly different ways, and these differences need to be resolved during implementation: • Staged approach vs. iterative process

PRINCE prescribes breaking the project down into manageable and controllable stages. The Project Board commits resources and authority to spend only for one stage at a time. Within each stage there is a process for managing product delivery. This may or may not be an iterative process. The RUP process model prescribes 4 main phases (Inception, Elaboration, Construction and Transition), and at least one iteration of each phase, depending on the nature of the project. The best way to map PRINCE and RUP is to equate the RUP phases to the PRINCE stages, whereas the iterations constitute the process for managing product delivery. This mapping needs to completed and implemented as part of the project design.

• Project initiation and start-up

PRINCE prescribes a project start-up for defining the project’s scope and objectives and creating the project management organisation, and a distinct project initiation stage for defining the project and creating a “Project Initiation Document” (P.I.D.). The P.I.D. includes the business case, project plan and quality plan and acts as the main reference document for the remainder of the project. By having a distinct Project Initiation stage, the Project Board has the opportunity of authorising this stage prior to authorising any subsequent stage. RUP does not have a distinct project initiation, but incorporates various aspects of project initiation at “the beginning of the Inception phase”, which is the first part of the iterative process. There are two distinct components of project initiation within RUP. There is the Project Definition and Planning, performed by the Project Manager with contributions from the Business Process Analyst and the Systems Analyst, and Preparing the Project Environment, performed by the Process Engineer. Project Definition and Planning includes developing the Business Vision, the Project Vision and the Business Case. Environment Preparation includes selecting relevant tools, techniques and artifacts, defining workflows, guidelines and templates. Both approaches can be combined to create a new definition of the Project Initiation stage. We shall call this “Design the Project”. Designing the Project is distinct from the iterative process and precedes the Inception phase. It includes both the role of the Project Manager in defining, planning and organising the project (with contributions from the Business Process Analyst and the Systems Analyst), and the role of the Process Engineer in preparing the project environment.


• PRINCE also has a distinct stage for Closing the Project, thus creating the possibility for the Project Board to verify that the project has been completed successfully and to put in place any follow-up actions required in order to provide operational support and ensure delivery of business benefits. This is also distinct from the iterative process.

The combined approach could therefore be that of having six stages; Design the Project, Inception, Elaboration, Construction, Transition and Project Closure.

At the specialist management level, RUP prescribes the following guiding principles: • Model visually • Use component based architecture • Continuously verify quality • Manage requirements • Change and configuration control

Since PRINCE is not prescriptive at the specialist level, there are no contradictions between the two.

Roles & responsibilities The role definitions in PRINCE and RUP are largely compatible, since they have very little overlap. At the programme management level the roles are defined primarily within PRINCE, and they consist of the members of the Project Board: • The Executive, representing the interests of the investor • The Senior User, representing the interests of the users that deliver the business benefits • The Senior Supplier, representing the interests of the supplier At the project management level the main role defined by both PRINCE and RUP is that of the Project Manager. Moreover PRINCE states that this is the only role that cannot be delegated or shared. PRINCE also prescribes the roles of Project Support and Project Assurance, which can be equated to the role of Project Reviewer in RUP. There is an overlap between some of the responsibilities of the Project Manager in PRINCE and some of the specialist roles in RUP. For example: • Defining and designing the project workflows • Selecting relevant specialist products or artifacts • Defining guidelines, standards and templates Which are assigned as the responsibility of the Process Engineer. • Developing the Business Vision (Business Process Analyst) • Developing the Project Vision (Systems Analyst) This overlap is due to the fact that in software engineering these are specialist responsibilities. The recommended approach is to leave these as the responsibility of specialist roles. At the specialist management level, once the overlap between Process Engineer, Business Process Analyst, Systems Analyst and Project Manager are resolved there is full


compatibility. The role of Team Manager in PRINCE is an optional role that only acts as a placeholder for the specialist roles in RUP. The various products defined in PRINCE as responsibility of the Team Manager therefore can be assigned to one or more of the RUP specialist roles. The proposed combined set of roles is as follows. Management Level

PRINCE RUP


Project Board • Executive • Senior User • Senior Supplier Stakeholders

Stakeholders

Project Management

Project Manager Project Assurance Project Support

Project Manager Project Reviewer

Management Roles • Process Engineer • Configuration Manager • Change Control Manager • Deployment Manager Analyst Roles • Business Designer • Business Model Reviewer • Business Process Analyst • Reviewer • Specifier • Systems Analyst • User Interface Designer Developer Roles • Architecture Reviewer • Capsule Designer • Code Reviewer • Database Designer • Design Reviewer • Designer • Implementer • Integrator • Software Architect Test Roles • Test Designer • Tester

Specialist

Other Roles • Course Developer • Graphic Artist • Technical Writer • Tool Specialist • System Administrator

Shaded areas indicate roles included in the combined model.


Processes, disciplines and workflows At the programme management level, the only process defined is the “Direct the Project” process from PRINCE. At the project management level, PRINCE provides most of the processes required, including Control a Stage and Manage Stage Boundaries, where a RUP Phase can be equated to a PRINCE Stage. There are however two RUP processes that need to be added to this model. • The process Manage Product Delivery should be replaced by the RUP workflow Manage

an Iteration. This establishes the capability of managing an iterative process. • The PRINCE process Initiate the Project needs to be expanded to include the RUP

activities Prepare Project Environment, Develop a Business Vision and Develop a Project Vision. These are still positioned at the specialist management level, but are performed within an expanded PRINCE stage. As previously discussed we can call this Stage “Design the Project”.

• The RUP process Evaluate Project Scope and Risk is replaced by the equivalent tasks

within the PRINCE Initiate a Project process. The proposed combined set of processes is therefore as follows. Management Level

PRINCE RUP

Programme Management Direct the Project (DP)

Project Start-Up (SU) Conceive New Project

“Design the Project”

Prepare Project Environment Develop Vision Statements Initiate the Project (IP)

Evaluate Project Scope and Risk

Planning (PL)

Develop Software Development Plan Plan for Next Iteration

Controlling a Stage (CS) Monitor and Control Project Managing stage Boundaries (SB) Close-out Phase

Manage Product Delivery (MP) Manage Iteration

Project Management

Close Project (CP) Close-out Project Business Modelling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management

Specialist

Support Environment during an iteration

Shaded areas indicate processes included in the combined model.


In a combined model it is no longer necessary to include a project management discipline within the RUP Process Model. At the specialist management level all processes or disciplines are provided within RUP, and require no modification other than taking into account that the specialist tasks Prepare Project Environment, Develop a Business Vision and Develop a Project Vision are now contained within the Design the Project stage, rather than at the beginning of the Inception phase.

Deliverables, products and artifacts Mapping products and artifacts between PRINCE and RUP is very similar to mapping the processes. PRINCE provides a number of products to be used at the programme management level, these are: • Project Mandate • Project Brief • Project Organisation • Highlight Reports • Exception Reports • Exception Plans • Project Board Approval • Mid Stage Assessment • Project End Notification • Post-Project Review At the project management level there are a number of artifacts that are produced within the RUP project management discipline. Most of these can be replaced by the equivalent PRINCE products. However “Iteration Assessment” and “Iteration Plan” are to be retained for management of iterations, and the Business Vision and Project Vision from RUP are included in the Business Case, which is then part of the Project Initiation Document (P.I.D.) The artifacts “Measurement Plan” and “Project Measurements” are specialist artifacts, (they are specific to software engineering, not to generic project management). They should be retained at the specialist level but responsibility should be re-assigned to a specialist role, such as the Process Engineer. In the PRINCE approach, the Project Plan incorporates not only RUP’s Software Development Plan, but also the Problem Resolution Plan and the Risk Management Plan. Three RUP Artifacts are therefore replaced by a single PRINCE product.


The proposed combined set of products and artifacts is therefore as follows. Management Level

PRINCE RUP

Project Mandate Project Brief Project Organisation Exception Reports Highlight Reports Exception Plans Project Board Approval Mid Stage Assessment Project End Notification


Post-Project Review

Business Case

Business Vision Business Case

Project Vision

Software Development Plan

Problem Resolution Plan Project Plan

Risk Management Plan Risk Log Risk List

P.I.D

.

Project Quality Plan Quality Assurance Plan Issues Log Issues List Iteration Plan Iteration Assessment Acceptance Criteria Product Acceptance Plan Quality Log Review Record Checkpoint Report Status Assessment

Project Management

Work Package Work Order Environment Artifact Set Business Modelling Artifact Set Requirements Artifact Set Analysis and Design Artifact Set Implementation Artifact Set Test Artifact Set Deployment Artifact Set

Specialist

Configuration & Change Management Artifact Set

Shaded areas indicate products and artifacts included in the combined model. At the specialist management level all products required are defined as Artifact Sets within RUP, and can be used as defined with the following exceptions. The Business Vision and (Project) Vision artifacts are specialist artifacts produced by the Business Process Analyst and the Systems Analyst respectively. These artifacts are incorporated into the Project Initiation Document (P.I.D.), together with the Business Case, the Project Plan, the Project Quality plan and the Risk Log. The Development Case is a specialist artifact produced by the Process Engineer as part of the Environment Artifact Set. It is used to document the design of the project (artifacts,


processes, guidelines, templates). This continues to be a specialist artifact, but it is produced during the initial stage that we have called Design the Project.

Guidelines, tools and techniques PRINCE only provides three techniques. • Configuration management. This is a generic technique for recording information about

the status of the various products in the product breakdown structure. It can be entirely replaced by the techniques for change and configuration management provided within RUP.

• Project file structure. These are general guidelines on how to structure and maintain

project files, and can be applied as they are to the project management artifacts. • Product based planning. This is a generic technique for planning a project based on the

structure of what is to be produced. Although it is a perfectly valid technique, in most projects it would be more relevant to adopt the more specialised planning techniques prescribed by RUP.

RUP on the other hand provides a set of guidelines and techniques that although specific to software engineering are applicable at the project management level. They apply particularly to the “Design the Project” stage. These guidelines are described in the Guidelines Overview to the project management discipline. The ones that need to be considered at the “Design the Project” stage are the following: • Software Development Plan

This guideline looks at the following aspects of defining and planning a project:

o Determining the length of an iteration o Determining the number of iterations o Aligning the traditional waterfall review sequence with the iterative approach o Project organization

• Risk List

This guideline discusses risk management strategies, and distinguishes types of risk to be considered

• Business Case

This guideline distinguishes sources of cost that are typical of software engineering projects and need to be taken into account

• Important decisions in project management

This guideline discusses various points that are useful during project definition All remaining guidelines within RUP constitute specialist guidelines and can be used as they are.


Summary of changes required PRINCE and RUP can be combined effectively by implementing a number of changes that have been identified and are listed under the following headings: • Create a unified glossary of terms • Create a unified set of guiding principles • Create a unified process model • Changes required to PRINCE for the project management level • Changes required to RUP for the specialist management level Create a unified glossary of terms As discussed earlier, it is advisable to maintain the terminologies used by the two methods distinct and preserve the relationship with the relevant communities of practice. Nevertheless the creation of a single unified glossary of terms, listing both the terms from PRINCE and those from RUP, and identifying equivalent terms, would go a long way to avoid any potential confusion in the interface between the two communities of practice. Create a unified set of guiding principles Neither PRINCE nor RUP contain an explicit statement of their guiding principles, although RUP does go some way towards this in enunciating its “best practices”. It would be beneficial to create a single unified statement of guiding principles, spelling out for example the relationship between the PRINCE stages and iterative development, clarifying the purpose of the “Design the Project” stage and distinguishing between the three different levels of management. Create a combined process model The following is the PRINCE process model modified to take into account the changes and additions required in order to add the Design the Project stage and incorporate relevant components of RUP.

PlanningPlanning

Proj

ect

Spec

ialis

t

Close AProjectClose A

Project

Manage StageBoundariesManage Stage

Boundaries

Directing A ProjectDirecting A Project

Start-upA ProjectStart-up

A Project

ProjectMandateProject

Mandate

Initiate AProjectInitiate A

Project

ControlA StageControl

A Stage

RUP PhasesRUP PhasesPrepare Project

EnvironmentPrepare ProjectEnvironment

DevelopVision

Statements

DevelopVision

Statements

PlanningPlanning

Proj

ect

Spec

ialis

t

Close AProjectClose A

Project

Manage StageBoundariesManage Stage

Boundaries

Directing A ProjectDirecting A Project

Start-upA ProjectStart-up

A Project

ProjectMandateProject

Mandate

Initiate AProjectInitiate A

Project

ControlA StageControl

A Stage

RUP PhasesRUP PhasesPrepare Project

EnvironmentPrepare ProjectEnvironment

DevelopVision

Statements

DevelopVision

Statements

Design the ProjectDesign the Project


The following is the RUP process model for the specialist level. It has been modified to take into account the changes required in order to move relevant components to PRINCE at the project management level and also to include elements of Business Modelling and Requirements Analysis in the Design the Project stage.

DisciplinesBusiness Modelling

RequirementsAnalysis & Design

ImplementationTest

DeploymentConfiguration

& Change MgmtProject Management

Environment



ImplementationTest



Environment

Close A Project

Control A Stage / Manage Stage BoundariesDesignthe Project

Start-upA Project

Inception Elaboration Constructi on Transition

Initial Elab #1 Tran#2

Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations

Direct A Project

Planning



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment

Close A Project


Start-upA Project



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations

Direct A Project

Planning

Direct A Project

Planning

Direct A Project

Planning



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment

Close A Project


Start-upA Project



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations

Direct A Project

Planning

Direct A Project

Planning

Direct A Project

Planning



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment



ImplementationTest



Environment

Close A Project


Start-upA Project



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations



Tran#1

Const#n

Const#1

Const#2Elab #2

Phases

Iterations

Direct A Project

Planning

Direct A Project

Planning

Direct A Project

Planning

Direct A Project

Planning

hanges required to PRINCE for the project management Level

Incorporate the guiding principle of iterative development.

Define the Design the Project stage, which is the current PRINCE definition of the Initiate

o Prepare Project Environment

• istinguish between the responsibilities of the Project Manager and those of the Process

Incorporate the management products Iteration Plan and Iteration Assessment from the

Expand the template for the Project Initiation Document (P.I.D.) to include the Business

• Replace the process Manage Product Delivery with the appropriate activities for

Incorporate the relevant guidelines from the RUP project management discipline for

C • •

the Project Stage expanded to include the following RUP activities:

o Produce Business Vision o Produce Project Vision

DEngineer, the Business Process Analyst and the Systems Analyst

•RUP project management discipline

•Vision and the Project Vision

Managing an Iteration from the RUP project management discipline

•defining the project and producing the Business Case


Changes required to RUP for the specialist level • Modify the environment discipline to define that the Prepare the Environment workflow

and the Development Case artifact are moved to the Design the Project stage from the Inception phase

• Similarly modify the Business Modelling and the Requirements disciplines to move the

development of the Business Vision and the Project Vision to the Design the Project Stage from the Inception phase

• Move the following processes, artifacts and guidelines from the RUP model to the

PRINCE environment for project management

o Manage Iteration process o Iteration Plan artifact o Iteration Assessment artifact o Project Management guidelines

• Remove the project management discipline, it is replaced by PRINCE • Remove the following artifacts from the RUP model, they are replaced by the equivalent

PRINCE management products

o Business Case o Software Development Plan o Problem Resolution Plan o Risk Management Plan o Issues List o Risk List o Product Acceptance Plan o Quality Assurance Plan o Review Record o Status Assessment o Work Order


RECOMMENDED APPROACH FOR COMBINING PRINCE AND RUP

Keeping PRINCE and RUP distinct As we have seen in the compatibility analysis, it is possible to keep the two methodologies distinct, with clear and unambiguous interfaces between them. This is our recommended approach. PRINCE can be used to address the project management level, with some overlap and interfaces towards the programme management level. RUP can be used to address the specialist level of software engineering. We have also seen that some changes will be required to both methodologies in order to achieve the appropriate level of match compatibility. This approach presents the following advantages: • In most cases, organisations interested in combining the two are likely to be already using

one or the other. Adding a methodology to the one already in use is a lower risk approach since it requires less drastic changes to the existing environment and competencies, when compared to the implementation of a new methodology based on both

• The two methodologies present little overlap, and can therefore be used almost

independently, provided there is a clear interface between the two • Maintaining RUP distinct enables the development organisation to maintain its

relationship with the relevant community of practice. It will still be possible to recruit resources skilled in RUP without requiring them to be also skilled in PRINCE. It will also be possible to keep the organisation’s implementation of RUP aligned to new versions released by Rational Software

When applying subsequent versions of RUP and subject to a re-analysis of the levels of compatibility using the criteria listed earlier in this paper, it will only be necessary to update the components of RUP that have actually been implemented

• Maintaining PRINCE distinct enables an organisation to maintain its relationship with the

relevant community of practice, recruit skilled PRINCE resources without requiring RUP skills and stay aligned with further releases of PRINCE

It will also be possible to include additional specialist methodologies as and when appropriate. These could include, for example, methodologies for managing IT infrastructure or for performing business process re-engineering

Company methodology first or project methodology first ? It is normally advisable to establish a generalised company-wide methodology that can be referred to during the “Design the Project” stage for each new project in order to design and implement the methodology and environment for the specific project. This approach would have the advantage of mobility of resources between different projects that are based on the same methodology, establishing a common company culture, maximising the benefits of continuous improvement of a common methodology, simplifying the company’s internal communication processes, reducing the cost of training and reducing business risks.


There would therefore be two levels of methodology, the company-wide level and the project level. When approaching a first implementation, however, we believe that it is best to start at the project level and move upwards. There is less risk and more flexibility in first implementing a methodology for a single project, a pilot project, and then generalising it to the company as a whole applying the lessons learned. Methodology implementation lends itself to an iterative approach, whereby various components of the methodology are implemented via successive iterations or pilot projects, generalising the outcome of each iteration to create a new version of the company-wide methodology. For example, the first iteration could consist of implementing PRINCE with a generic process for iterative development, the second iteration could implement requirements management with Use-Cases, the third iteration could implement visual modelling with the Unified Modelling Language (UML), and so on.

PLANNING AND MANAGING THE IMPLEMENTATION Whatever the starting situation, implementing a new methodology or modifying an existing one implies making changes to people, processes and tools. It should therefore be carried out as a programme of business change, and managed at the three levels of management described in this paper. The specialist level consists of deploying the specialist skills of process engineering, methodology implementation, training and mentoring. The four main outcomes required in order to successfully implement a methodology are: 1. Assess the development organisation and develop a blueprint for change. This should

identify, for example, the step-by-step changes required and how they are grouped into individual projects within the programme

2. Create the methodology environment. This could consist either of a big-bang approach of

implementing a company-wide methodology first or an alternative approach of working through the project level first and then generalising to the company-wide level, as already described

3. Develop the capabilites. This would consist of assessing the available resources,

assigning them to current and target roles and responsibilities, identifying requirements for training, coaching and mentoring, and carrying out a programme of capability development

4. Implement project assurance, controls and measures. This is a key outcome that enables

the methodologies to be used effectively, identifying opportunities for improvement and embarking on a continuous improvement programme

We believe that methodology implementation programmes are particularly suitable for an iterative approach. Successive approximations are used to establish a basic framework and reduce risk early, taking advantage of early learning opportunities and keeping the door open to change. In particular it is advisable to embark on capability development via a succession of small incremental steps.


Assess the development organisation The first step should always be an assessment of the development organisation and its software development practice, in order to examine the business context, internal and external factors and characteristics of the software product that would have a bearing on the best approach. In particular it is important to analyse what methodologies, if any, are already in use, the extent to which these have already been tailored and identify the requirements for capability development. Different approaches will be appropriate depending on whether, for example, either one of PRINCE or RUP is already established within the organisation and the relevant capabilities already available. The simplest case is where PRINCE is already in use. In this case the best approach is to add RUP by following Rational Software’s standard approach for implementing RUP, albeit with the differences in configuration that have been discussed earlier in this paper. This approach is simplest for the following reasons: Very few changes would be required to the components and processes of PRINCE

already in use The methodology implementation project could be managed using the PRINCE

components and processes already in place, thus providing early exposure to the combined use

It is important however to avoid implementing new components of RUP’s project management or environment disciplines that would clash with any already established components and processes of PRINCE. Wrapping PRINCE around RUP would be more complicated, since the already established project management and environment disciplines of RUP would need to be used in order to manage the PRINCE implementation project, while they are also being effectively replaced with the equivalent components and processes of PRINCE. This is a more complicated and higher risk situation because it can destabilise an established practice and not immediately replace it with a new one. In cases where neither PRINCE nor RUP are already in use, the best approach would probably be that of implementing first a simplified version of PRINCE and stabilising it before implementing RUP.

Create a methodology environment The methodology environment consists of a set of clearly documented, easily accessible and usable components. These describe the guiding principles, disciplines, processes, activities, controls, document templates, guidelines, roles and responsibilities, tools and techniques. These components act as a point of reference, create a common understanding and guide a project team towards the successful delivery of the project. With most methodologies the environment consists of a set of manuals and relevant documentation. In some cases, such as in the case of RUP, more sophisticated web based delivery methods are used. Configuring means taking the components provided by each methodology “out of the box”, and modifying them so that they meet the needs of the specific organisation or project. In this instance it means making the changes that have been identified earlier in this paper.


In the case of RUP the environment is implemented by creating a customised version of the web site provided by Rational Software. PRINCE, on the other hand, is only provided in the form of documentation, both hard-copy and on-line. Configuring PRINCE would normally consist of producing new documentation, in similar format, where some components are modified and adapted to an organisation’s specific needs. Since the way both methodologies are expressed is largely similar, it is also possible to document PRINCE and configure it using the same web site provided by Rational Software. There are two levels of configuration or customisation required. One level is the company-wide set of methodologies, which provide a template and a

degree of standardisation and re-usability for the methodologies used for all projects, and for all software engineering projects in particular

The other level consists of the methodology for a specific project. This is the domain of

Preparing the Project Environment discussed earlier in this paper as the responsibility of the Process Engineer during the Design the Project stage

Earlier in this paper we discussed the possibility of implementing the company-wide methodology via a succession of project-level implementations, using an iterative approach.

Develop the capabilities In addition to configuring the environment for each methodology, it will be necessary to develop the relevant capabilities. These consist of the resources and skills required in order to perform the relevant roles and responsibilities. Achieving the changes in culture and developing the required skills is probably the most difficult aspect of implementing a methodology. In cases where one of the methodologies is already in place this task can be made easier by reducing to a minimum the changes that require re-training. There are a number of approaches to skill development recommended by RUP, which include training and mentoring. These can be utilised to good effect. Above all, it is important to plan and manage change in small incremental steps, in order to reduce resistance to change and provide frequent positive feed-back. This is a strong reason for adopting an iterative approach and implement the methodology via a succession of controllable and manageable stages.

Implement project assurance, controls and measures The greatest advantage of iterative development, even when applied to methodology implementation programmes, is that you can have multiple bites at the cherry in terms of making improvements over successive iterations. In order to be able to do this it is necessary, however, to obtain some measure of the effectiveness of the current implementation, and of the improvements being accomplished. Whereas in software engineering this is the domain of testing and quality metrics, in methodology implementation this is the domain of project assurance. A project assurance role should be established from the first pilot project. The first task of project assurance is to identify and implement the metrics required in order to monitor the successful implementation of the methodologies. The specific metrics required will depend to some extent on the strategic business objectives that the methodology implementation programme is trying to achieve, and may consist of measuring productivity, quality, costs, flexibility or time-to-market.


WHAT NEXT ? We have now seen that PRINCE and RUP can be combined, distinctly, to provide methodological support for the project management and specialist management levels of implementing business change. We have also identified the changes that are required to both in order to make it possible to use them together effectively. We have also seen that there are 3 key success factors towards implementing RUP within PRINCE. 1. The implementation constitutes a programme of business change, and implies making

changes to people, processes and tools 2. Methodology implementation lends itself to an iterative approach and can best be

accomplished via successive approximations 3. The main contributors to a successful implementation are: assessing the development

organisation, implementing the methodology environment, developing the capabilities and establishing project assurance, controls and measures

Once the two methodologies have been implemented successfully, this creates the need and opportunity to continue to evolve in three distinct directions, as follows: 1. Embark on a programme of continuous improvement

Based on the feed-back provided by project assurance and control, and also prompted by subsequent releases of both PRINCE and RUP, there will be need and opportunity to modify and improve the components that have been implemented There will also be need and opportunity to continue to develop capabilities via training, coaching and mentoring

2. Add a methodology at the programme management level

By adding a methodology for programme management, such as MSP, it will be possible to extend the benefits of combined methodologies to all management levels involved in accomplishing business strategic objectives

3. Implement additional specialist methodologies

Additional specialist disciplines can be integrated into the combined methodology, thus increasing the organisation’s effectiveness at managing programmes of business change. Examples of areas of specialisation that may be added are IT service management, business process re-engineering and data warehousing for business intelligence


Appendix A: Brief introduction to PRINCE PRINCE (PRojects IN Controlled Environments) is a structured method for effective project management. It was developed by the UK Government’s Central Computer and Telecommunications Agency (CCTA) and is a de facto standard used extensively by the UK Government. It is also widely recognised and used in the private sector, both in the UK and internationally. The CCTA is now incorporated into the Office of Government Commerce (OGC). PRINCE2 is a revised version of PRINCE. It is a generic project management method, applicable to a wide variety of projects, not just software projects. In fact the PRINCE documentation states that:

“PRINCE covers the management of the project, and the management of the resources involved in carrying out the activities of the project. It does not cover the specialist techniques involved in the creation of the products. This is the job of other methods, although PRINCE must interface with them to enable information on such areas as estimating, for example, to be provided for project management.” In this respect, PRINCE was specifically designed to be combined with other methodologies at the specialist level. This is not often realised by organisations, and they therefore find themselves with a gap in their methodology. In order to effectively interact with a specialist methodology, there are three types of interface required. 1. Exchange of information about work assignments and progress, at the appropriate level

of detail (plans and controls) 2. Exchange of information about the composition of what the project will deliver, so it can

be used for planning at the appropriate level of detail (product breakdown structure) 3. Exchange of information about the quality of the products, and how, when and by whom

the quality was verified, in accordance with the quality plan (quality tracking) PRINCE also provides a link to the programme management level, by providing a means for directing a project from a business perspective. The guiding principles of PRINCE The following are documented as the distinguishing features of PRINCE • Its focus on business justification (see more below) • A defined organisation structure for the project management team • Its product-based planning approach • Its emphasis on dividing the project into manageable and controllable stages • Its flexibility to be applied at a level appropriate to the project


There are however additional, more specific, features of PRINCE that we believe add to its guiding principles, without which it would lose its identity and effectiveness. These are: • Directing the project. The concept that there is a level of control above that of the

Project Manager. At this level, management by exception is combined with tolerance, (The Project Manager’s delegated authority) to provide an additional level of guidance and governance. This level of governance is at the programme management level. Stage boundaries are used to perform regular reviews of the business case and of the project’s outcomes, managing transition between stages and providing commitment of resources and authority to spend on a stage by stage basis.

• There are two distinct stages, one at the beginning and one at the end, that formalise the

process, products and controls for defining, authorising and completing a project. These act as a “wrapping” for the staged development that lies within. Defining the project prior to its execution and closing the project prior to its completion become two of the guiding principles.

• Managing quality, by proactively defining quality expectations, planning how the quality

of products will be verified during the course of the project and recording the outcomes of quality verifications.

• Product based planning is the principle whereby plans are based on an understanding

of what is to be produced (the products), its structure and dependencies. This is similar though more generic than the architecture-centric and component-based approach of RUP.

• Iterative planning. Project plans are not developed in full detail and frozen at the

beginning of the project, they are developed and updated continually during the course of the project, as requirements and designs become clearer. The initial project plan consists of a high level breakdown of the overall project (how many stages etc…) and a detailed plan and resource schedule for the next stage.

• PRINCE has not specifically been designed as a method for iterative development, its

stage based approach is however compatible with iterative development. • In order to manage risk and the impact of change, PRINCE prescribes as essential

components the guiding principles of Change Management and of Risk Management, which are facilitated by both iterative development and stage based project management.


Structure of PRINCE PRINCE is provided as a set of manuals. In its “out of the box” form, PRINCE is defined as a set of components and a set of processes.

The eight components prescribed by PRINCE are the following:

1. Organisation

Includes a Project Board to direct the project, with representation of the sponsor, the users and the supplier.

2. Plans

The concept of using plans in order to govern the project. Four levels of planning: programme plan, project plan, stage plan and team plan. Exception plans are used to manage exceptions. Product based planning.

3. Controls

Controls for the Project Board and for the Project Manager.

4. Stages

Breaking the project into at least two management stages. Management stages equate to commitment of resources and authority to spend. Stage boundaries provide management decision points.

5. Management of Risk

Types of risk: business risk and project risk (supplier, organisation, specialist). Risk analysis, risk management, risk log.

6. Management of Quality

Definition of quality expectations, link to specific organisation’s quality system, quality reviews and quality log (audit trail).

7. Configuration Management

Tracking all products through various stages of processing. Linking products to requirements.

8. Change Management

Controlling the impact of issues, tracking issues to completion. Controlling, facilitating and managing changes.


The eight processes prescribed by PRINCE are the following: 1. Direct the Project (DP)

The discipline via which the Project Board provides direction to the project and provides a link with programme management.

2. Project Start-up (SU)

Prior to the project, appoint the key roles, prepare a project brief, define project approach. Obtain authority to proceed to Project Initiation.

3. Initiating a Project (IP)

First and mandatory stage of the project itself. Produce quality plan, overall project plan, refined business case, risk analysis and risk management plan, project controls, project files. Obtain authority to proceed to next stage.

4. Controlling a Stage (CS)

Manage resources, activities and outcomes of each stage. Equivalent to managing a phase in RUP.

5. Manage Product Delivery (MP)

This constitutes the specialist level, it generically refers to the specialist activities that would be performed, for example, within RUP.

6. Manage Stage Boundaries (SB)

Stage boundaries are used to perform regular reviews of the business case and of the project’s outcomes, managing transition between stages and providing commitment of resources and authority to spend on a stage by stage basis.

7. Close Project (CP)

Ensure that the project has reached its objectives, plan any follow-up actions, ensure that user acceptance and operational acceptance have been accomplished. This principle behind this is that a project is not finished when it runs out of time and resources, but when it completes what it set out to do.

8. Planning (PL)

Planning is an iterative process that is executed through the duration of the project. There are four levels of planning:

• Programme planning • Project planning • Stage planning • Team planning (this is the planning of the specialist activities performed, for example,

within RUP)


The PRINCE process diagram

Relevant techniques prescribed by PRINCE PRINCE recommends three techniques: product based planning, quality reviews and project files organisation. Of these, product based planning is particularly relevant. Although it is a generic technique, it establishes the guiding principle that planning has to start from the identification and description of the products (or artifacts) that are to be produced, and how they are related. Product based planning also distinguishes between: • Management products (the products used in order to manage the project. Examples are

the Project Mandate, the Project Initiation Document, the Highlight Reports etc…) • Quality products (The products that are used in order to manage and ensure that the

outcomes of the project meet the customer’s quality expectations. Examples are the Quality Plan, the Quality Log, the Issue Log and the Product Descriptions)

• The specialist products, the actual products of the project (the implemented software). The initial steps in product based planning are: • Identify the products and the product breakdown structure • Prepare product descriptions • Produce product flow diagram This then leads into the next planning activity within the planning process (identify activities and dependencies).


Appendix B: Brief introduction to the Rational Unified Process (RUP) The Rational Unified Process (RUP) is described as a “software engineering process”. It fits into that layer of management that we have defined as “specialist management ”. RUP is provided both in the form of a set of documentation and in the form of a customisable web site. The web site includes a software representation of the process model, disciplines, roles, artifacts, guidelines, templates, tool mentors and other useful components. RUP is defined in terms of the following components: 1. Best practices 2. A process model that describes the iterative development approach 3. A set of disciplines 4. Roles 5. Artifacts 6. Tools and techniques 1. Best Practices: The six best practices in RUP have been identified and defined in response to an assessment of the most common problems in software engineering, and how to resolve them. The best practices prescribed by RUP can be equated to guiding principles, and are the following: 1.1 Develop iteratively Two of the main reasons for developing iteratively are discussed in the description of iterative development in Appendix C. They are reducing risk up-front while leaving a door open to change. In addition RUP describes three more benefits of iterative development: learning and applying what you learn earlier in the project, re-using some of the components developed early on and producing higher quality goods by getting more opportunities (iterations) to improve them. Using the example of the call centre used in Appendix C, we can see that by introducing a call centre early in the project and producing successively more complete releases we generate the possibility of learning lessons early on in the project and also get multiple bites at the cherry in terms of making improvements to the call centre. It is therefore apparent that by using an iterative approach we also improve our chances of delivering a quality product at the end of the project. Iterative development is the most important guiding principle in RUP. The process model (phases, iterations and the core workflows) evolves around this principle (see later for a description of the process model).

1.2 Manage requirements

Requirements management is a systematic approach to finding, documenting, organizing and tracking the requirements of a system as they evolve and change during the course of the project. It includes being able to determine how the requirements are met, even as they change.


1.3 Verify quality

Quality management in RUP is defined at a greater level of specialisation that in PRINCE. It includes approaches to verifying and assuring quality that are specific to the software engineering process, such as testing.

1.4 Control changes

Controlling changes within RUP is not limited to managing change requests, as described in PRINCE. It also mitigates the potential impact of components being changed by different people concurrently, by introducing a degree of control of how changes are made on evolving versions of components.

1.5 Use component architectures

Component based architecture is an approach to designing complex systems that:

• Makes complexity manageable by breaking it down into different views, while retaining its integrity

• Provides an effective basis for large-scale reuse of components • Provides a basis for effective project management, by enabling a top-down breakdown of

the structure of the system and facilitating “product based planning”

1.6 Model visually

Visual modelling is an approach to designing and defining a system in a way that is:

• Easy to understand and verify. It clearly corresponds to reality • Easy to modify. Changes in a particular phenomenon concern only the object that

represents that phenomenon

2. The RUP process model The RUP process model has three dimensions: • The horizontal axis represents time and shows the lifecycle aspects of the process as it

unfolds. It represents the dynamic aspect of the process as it is enacted, and it is expressed in terms of phases, iterations, and milestones

• The vertical axis represents disciplines, which group activities logically by nature. Each

and every discipline is enacted to a degree for each iteration of each phase of the project lifecycle

• The third dimension is the ability to drill-down into each discipline and access a

description of the activities and artifacts that define the discipline


The four phases are: 2.1 Inception

During this phase the project’s objectives are defined, together with the primary use cases and scenarios that will form the basis for design. A candidate (prototype) architecture is tried, potential risks identified and an estimate of the likely overall cost and schedule for the project are developed.

Using again the example of a project that includes a call centre and an application to provide a single view of the customer, a prototype of each of these would be produced and evaluated during the inception phase. This would most likely consist of a “proof of concept” prototype. More refined versions of the prototype would be produced at each iteration, and eventually it would become the final product.

2.2 Elaboration

During this phase most of the requirements are documented in the form of use-cases, the architecture is refined, the development infrastructure is established together with a development plan.

2.3 Construction

This phase focuses on developing (and testing) the software and creating useful versions as rapidly as possible, as well as completing any outstanding requirements analysis and design.

2.4 Transition

This is the phase that focuses on “shipping” the product. Major outcomes are achieving final product baseline, obtaining user acceptance and operational acceptance.

Generally speaking there would normally be only one iteration of the inception phase, followed by multiple iterations of the elaboration, construction and transition phases.


3. Disciplines: Each of the following nine disciplines is enacted at each and every iteration of every phase. There will however be a different emphasis on each based on the state of maturity of the project. 3.1 Business Modelling The Business Modelling discipline provides the organizational context for the system, its purpose is: • To understand the structure and the dynamics of the organization in which a system is to

be deployed (the target organization) • To understand current problems in the target organization and identify improvement

potentials • To ensure that customers, end users, and developers have a common understanding of

the target organization 3.2 Requirements The Requirements discipline produces the Software Requirements Specifications that consists of the use-case model and non-functional requirements. Its purpose is: • To establish and maintain agreement with the customers and other stakeholders on what

the system should do • To provide system developers with a better understanding of the system requirements • To define the boundaries of (delimit) the system • To provide a basis for planning the technical contents of iterations • To provide a basis for estimating cost and time to develop the system • To define a user-interface for the system, focusing on the needs and goals of the users 3.3 Analysis and Design The Analysis & Design discipline gets its primary input (the use-case model and the Glossary) from Requirements, its purpose is: • To transform the requirements realisation into a design of the system to-be • To evolve a robust architecture for the system • To adapt the design to match the implementation environment, designing it for

performance 3.4 Implementation The Implementation discipline produces successive builds of the system so that they can be tested. The purpose of the implementation workflow is: • To define the organization of the code, in terms of implementation subsystems organized

in layers • To implement classes and objects in terms of components (source files, binaries,

executables, and others) • To test the developed components as units • To integrate the results produced by individual implementers (or teams), into an

executable system that can be tested


3.5 Testing The purpose of testing is: • To verify the interaction between objects • To verify the proper integration of all components of the software • To verify that all requirements have been correctly implemented • To identify and ensure defects are addressed prior to the deployment of the software 3.6 Deployment The Deployment discipline describes the activities associated with ensuring that the software product is available for its end users. There are three modes of product deployment described in RUP: • The custom install • The "shrink wrap" product offering • Access to software over the internet 3.7 Configuration and Change Request Management An organization's Configuration and Change Request Management System (CM System) holds key information about its product development, promotion, deployment and maintenance processes, and retains the asset base of potentially re-usable artifacts resulting from the execution of these processes. A CM System is essential for controlling the numerous artifacts produced by the many people who work on a common project. Control helps avoid costly confusion, and ensures that resultant artifacts are not in conflict due to some of the following kinds of problems: • Simultaneous update • Limited notification • Multiple versions 3.8 Project Management The project management workflow presents an approach to managing the project that will markedly improve the odds of delivering successful software. Its purpose is: • To provide a framework for managing software-intensive projects • To provide practical guidelines for planning, staffing, executing, and monitoring projects • To provide a framework for managing risk This workflow focuses mainly on the important aspects of an iterative development process: • Risk management • Planning an iterative project, through the lifecycle and for a particular iteration • Monitoring progress of an iterative project, metrics 3.9 Environment The environment workflow focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team.


The development environment for a software development project is the term for all things the project needs to develop and deploy the system, such as tools, guidelines, process, templates, and infrastructure.

4. Tools and Techniques Rational Software’s suite of software engineering tools and techniques can be used within the framework provided by the Rational Unified Process. The RUP environment includes guidelines and “tool mentors” to support the effective use of these tools and techniques. The techniques address the following areas: • Requirements management - collecting, managing and communicating changing

software and system requirements • Visual modelling - creating a graphical blueprint of a software application, its

components, their interfaces, and their relationships, making it easier to understand and communicate

• Software quality and test automation - providing integrated programming and testing

tools to simplify the creation of components and to replace expensive, tedious, and error-prone manual testing, resulting in higher-quality applications in less time with lower risk

• Software configuration and change management - Controlling the day-to-day team

development of software, as it is created, modified, built, and delivered


Appendix C: Introduction to iterative development There is a traditional way in which software development projects have been conducted. This consists of breaking up projects into major phases as follows: • Requirements - define business requirements (and obtain commitment to these

requirements) • Design - analyse the requirements, design and specify a solution that will meet them • Development - develop the components of the solution, test or verify that they behave as

specified • Implementation - assemble the components and implement the solution This approach, also known as the “waterfall lifecycle”, is supported by the principle of “phase containment”. This requires that you define the project completely and in detail at the start and also that you do not pass to the next phase until the current phase is complete, and then you do not go back. For example, you do not proceed to the design phase until the requirements have been finalised and signed off, and then you do not modify the requirements again. This approach, when applied to software development in the current business context, leads to a number of drawbacks. Two of these are particularly relevant to this paper: • Resistance to change. Phase containment naturally resists change, it discourages the

business from returning to and changing requirements after they have been signed off.

If all design and specification is completed up-front, any change in requirements after that will imply re-work and have an impact on the project’s cost and schedule. Changes get significantly more expensive as you move through the project lifecycle.

• Late risk reduction. In the waterfall lifecycle the project outcomes are not visible and verifiable until the very end, when they are assembled and implemented. Any possible misunderstandings of requirements and errors in design cannot be identified until very late, and then the very principle of phase containment makes it difficult to go back and make the appropriate changes.

Business reality is that the needs of the business will evolve and change even while a single project is being conducted. The final outcome of a project will not be fully defined at the beginning, but it will gradually take shape as the project progresses. Successful projects do not resist change, they facilitate it. Iterative development is an alternative approach to the software development lifecycle that deals with these two drawbacks effectively. It can also be called “successive approximations” or “eating the elephant one byte at a time” In iterative development the project is conducted not as a single “waterfall”, but as a succession of “weirs”, each of which tackles one part of the overall problem. These are repeated cumulatively until the entire problem has been resolved. Iterative development “manages risk up-front while leaving the door open to change”. • It becomes possible to tackle during the first few cycles or iterations the parts of the

problem that carry the highest risk, verify the outcomes and take corrective action before the project has gone too far. Changes can be made to the basic design or architecture


before it becomes the basis for further design and development, thus correcting the most expensive mistakes as early as possible.

• It also becomes possible to have multiple bites at the cherry when dealing with the parts

of the problem that are most subject to business uncertainty, thus “leaving the door open” to finalising these requirements as late as possible in the overall project. This is particularly useful for new and innovative components and elements of the user interface that cannot be fully defined by the business until they can see a usable example.

• It becomes possible to introduce breakpoints in a project or programme, thus making it

easier to bail out but still have delivered something tangible. This keeps senior management and investors happier as they will always see a return on their investment rather than just another expensive failure.

Certain key components can go through a number of successive releases, each of which adds to the previous ones, until the final release contains all the features and functionality required. For example, a project may aim at implementing a customer call centre together with a number of changes to existing systems in order to provide an integrated set of information about the customers. With an iterative development approach one might choose to implement a simplified version of the call centre early in the project, even though the integrated customer data is not yet available. This way the overall architecture and the call centre procedures can be tested and improved early on, and successive versions released as more and more customer information becomes available. We can therefore see that by adopting an iterative approach to software development we can reduce the most important risks early on and manage projects in accordance with the current business environment where requirements are not fully known at the beginning of a project, but take shape during its execution.


BIBLIOGRAPHY Managing Successful Projects with PRINCE2 ISBN 0 11 330855 8 Published by Her Majesty’s Stationery Office Rational Unified Process Version 2001A.04.00 Software available from Rational Software Managing programmes of business change By John Bartlett ISBN 1 900391 03 X For a very good description of PRINCE, see http://www.uclan.ac.uk/facs/destech/compute/staff/casey/integ/prince.htm For a scientific description of methodology and of cyclical development and water sluice development as instances of iterative development, see http://www-db.stanford.edu/~burback/watersluice/node75.html For Alistair Cockburn’s refreshing view of software development as a cooperative game, see http://members.aol.com/humansandt/papers/asgame/asgame.htm

http://www.uclan.ac.uk/facs/destech/compute/staff/casey/integ/prince.htm

http://www-db.stanford.edu/~burback/watersluice/node75.html

http://members.aol.com/humansandt/papers/asgame/asgame.htm


ABOUT THE AUTHOR Laurence Archer entered the IT Industry in 1974 and has explored every facet of the industry. He has more than 20 years experience in project management, and has been exposed to the majority of generally accepted methodologies. Laurence has attained accreditation in implementing the Rational Unified Process and as a PRINCE2 Practitioner. Laurence spent a considerable portion of his career exploring how to derive tangible business benefits from innovative technology. He worked as software technology consultant with SPL International for 9 years, where he was involved in an initiative to develop expert systems products and services. He was also technical director of Artificial Intelligence Software S.p.A. in Milan, Italy, for 7 years. He has published articles on expert systems and how to develop expert systems. This was an area that was amongst the first to explore iterative development methodologies and declarative programming languages. For some time now he has focused his attention on programme and project management across many sectors. Laurence now works for Oak Management Services, a company specialising in programme and project management. This paper is his and Oak’s response to a perceived need for combining specialist software engineering methodologies such as RUP with generic project management methodologies such as PRINCE. He lives in Sydney, Australia, together with a lovely wife, Fiammetta, and two fantastic sons, Daniel and William.

implementing rational unified process within a prince2 envir

Documents

rup distinct

management of business

history of project management

project methodology

role of methodologies

rational unified process

distinct management

different methodologies