This document discusses implementing the Rational Unified Process (RUP) software engineering methodology within the PRINCE project management framework. It provides background on PRINCE and RUP, explaining they were chosen because PRINCE is a widely adopted generic project management method and RUP represents best practices in software engineering. The document examines how the three levels of managing business change - programme management, project management, and specialist management - relate to each other. It analyzes the criteria for combining methodologies and determines PRINCE and RUP are highly compatible. Guidelines are provided for integrating the two approaches to maximize effectiveness when managing software development projects within broader programmes of change.
2. 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
Page 2
3. Implementing RUP within PRINCE2
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.
Page 3
4. Implementing RUP within PRINCE2
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.
Page 4
5. Implementing RUP within PRINCE2
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.
Page 5
6. Implementing RUP within PRINCE2
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
Page 6
7. Implementing RUP within PRINCE2
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.
Page 7
8. Implementing RUP within PRINCE2
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.
Three levels of managing business change
Programme Management
Define the blueprint for change
Project Management
Benefits Realisation
Management
Project Organisation
Coordinating multiple
Project Lifecycle Management
interdependent projects
Stakeholder Management Specialist Mgmt
Managing business priorities
Planning
software engineering
includes disciplines such as:
Controls
•Requirements Management
Risk Management
•System Architecture
Change Request Management
•Modelling and design
Quality Management
•Testing and verification
•Configuration Control
Page 8
9. Implementing RUP within PRINCE2
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:
Page 9
10. Implementing RUP within PRINCE2
• 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.
Programme
Programme
Management
undefined
Project
PRINCE
interfaces
Specialist
RUP
Page 10
11. Implementing RUP within PRINCE2
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.
Programme
Programme
Management
defined
Project
PRINCE interfaces
Specialist
RUP
By examining the attributes of methodologies we can identify the following set of criteria that
can be used to verify the compatibility between methodologies and identify changes required.
Terminology
Terminology defines the language used by communities of practice in order to communicate
and exchange information easily and effectively within a shared and commonly understood
context.
A community of practice is a group of people that have developed, typically via use, a
common knowledge, language and terminology. These people do not necessarily know each
other, 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.
The practitioners of a particular methodology constitute a community of practice. Sometimes
organisations 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 they
adopted a different terminology.
When different communities of practice come into contact, they each take their own context
and terminology with them. If the same term has a different meaning for each community then
there 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.
Since terminology cannot be changed or adapted, compatibility of terminology is of the utmost
importance. 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.
Page 11
12. Implementing RUP within PRINCE2
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.
Page 12
13. Implementing RUP within PRINCE2
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.
Page 13
14. Implementing RUP within PRINCE2
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.
PRINCE
Project
Terminology Disciplines
Guiding principles Tools and techniques
Roles Products
Specialist
RUP
Page 14
15. Implementing RUP within PRINCE2
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.
Page 15
16. Implementing RUP within PRINCE2
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.
Page 16
17. Implementing RUP within PRINCE2
• 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
Page 17
18. Implementing RUP within PRINCE2
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 PRINCE RUP
Level
Programme Project Board Stakeholders
Management • Executive
• Senior User
• Senior Supplier
Stakeholders
Project Project Manager Project Manager
Management Project Assurance Project Reviewer
Project Support
Specialist 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
Other Roles
• Course Developer
• Graphic Artist
• Technical Writer
• Tool Specialist
• System Administrator
Shaded areas indicate roles included in the combined model.
Page 18
19. Implementing RUP within PRINCE2
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 PRINCE RUP
Level
Programme
Management Direct the Project (DP)
Project Project Start-Up (SU) Conceive New Project
Management
“Design the Project”
Prepare Project Environment
Initiate the Project (IP) Develop Vision Statements
Evaluate Project Scope and Risk
Develop Software Development
Plan
Planning (PL)
Plan for Next Iteration
Controlling a Stage (CS) Monitor and Control Project
Managing stage Boundaries
Close-out Phase
(SB)
Manage Product Delivery (MP) Manage Iteration
Close Project (CP) Close-out Project
Specialist Business Modelling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change
Management
Support Environment during an
iteration
Shaded areas indicate processes included in the combined model.
Page 19
20. Implementing RUP within PRINCE2
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.
Page 20
21. Implementing RUP within PRINCE2
The proposed combined set of products and artifacts is therefore as follows.
Management PRINCE RUP
Level
Programme Project Mandate
Management Project Brief
Project Organisation
Exception Reports
Highlight Reports
Exception Plans
Project Board Approval
Mid Stage Assessment
Project End Notification
Post-Project Review
Project Business Case
Management
Business Case Business Vision
Project Vision
Software Development Plan
P.I.D.
Project Plan Problem Resolution Plan
Risk Management Plan
Risk Log Risk List
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
Work Package Work Order
Specialist Environment Artifact Set
Business Modelling Artifact Set
Requirements Artifact Set
Analysis and Design Artifact Set
Implementation Artifact Set
Test Artifact Set
Deployment Artifact Set
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,
Page 21
22. Implementing RUP within PRINCE2
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.
Page 22
23. Implementing RUP within PRINCE2
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.
Project
Project
Mandate
Mandate Directing A Project
Directing A Project
Project
Start-up Initiate A Control Manage Stage Close A
Start-up Initiate A Control Manage Stage Close A
A Project Project A Stage Boundaries Project
A Project Project A Stage Boundaries Project
Design the Project
Develop
Specialist
Prepare Project Develop
Prepare Project Vision RUP Phases
Environment Vision RUP Phases
Environment Statements
Statements
Planning
Planning
Page 23
24. Implementing RUP within PRINCE2
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.
Direct A Project
Start-up Design Control A Stage / Manage Stage Boundaries Close
A Project the Project Phases A Project
Inception Elaboration Constructi on Transition
Disciplines Disciplines
Business Modelling Business Modelling
Requirements Requirements
Analysis & Design Analysis & Design
Implementation Implementation
Test Test
Deployment Deployment
Configuration Configuration
& Change Mgmt & Change Mgmt
Project Management Project Management
Environment Environment
Const Const Const T ran T ran
Initial Elab #1 Elab #2
#1 #2 #n #1 #2
Iterations
Planning
Changes 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
the Project Stage expanded to include the following RUP activities:
o Prepare Project Environment
o Produce Business Vision
o Produce Project Vision
• Distinguish between the responsibilities of the Project Manager and those of the Process
Engineer, the Business Process Analyst and the Systems Analyst
• Incorporate the management products Iteration Plan and Iteration Assessment from the
RUP project management discipline
• Expand the template for the Project Initiation Document (P.I.D.) to include the Business
Vision and the Project Vision
• Replace the process Manage Product Delivery with the appropriate activities for
Managing an Iteration from the RUP project management discipline
• Incorporate the relevant guidelines from the RUP project management discipline for
defining the project and producing the Business Case
Page 24
25. Implementing RUP within PRINCE2
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
Page 25
26. Implementing RUP within PRINCE2
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.
Page 26
27. Implementing RUP within PRINCE2
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.
Page 27
28. Implementing RUP within PRINCE2
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.
Page 28
29. Implementing RUP within PRINCE2
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.
Page 29
30. Implementing RUP within PRINCE2
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
Page 30
31. Implementing RUP within PRINCE2
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
Page 31
32. Implementing RUP within PRINCE2
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.
Page 32
33. Implementing RUP within PRINCE2
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.
Page 33
34. Implementing RUP within PRINCE2
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)
Page 34
35. Implementing RUP within PRINCE2
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).
Page 35
36. Implementing RUP within PRINCE2
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.
Page 36
37. Implementing RUP within PRINCE2
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
Page 37
38. Implementing RUP within PRINCE2
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.
Page 38
39. Implementing RUP within PRINCE2
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
Page 39