Implementing Rational Unified Process
   Within A PRINCE2 Environment

              Laurence Archer

                31st...
Implementing RUP within PRINCE2



                                       Table of contents

ABSTRACT             ...........
Implementing RUP within PRINCE2




ABSTRACT
This paper discusses the possibility of implementing the Rational Unified Pro...
Implementing RUP within PRINCE2




ACKNOWLEDGEMENTS
Although PRINCE is available freely in the public domain, PRINCE® is ...
Implementing RUP within PRINCE2



PRINCE
PRINCE (PRojects IN Controlled Environments) is a generic structured method for ...
Implementing RUP within PRINCE2




The most important guiding principle of RUP is iterative development. It is essential ...
Implementing RUP within PRINCE2




THE BUSINESS CONTEXT
There was a time when managing a business consisted of maintainin...
Implementing RUP within PRINCE2




Three levels for managing business change
As can be seen in the previous section, ther...
Implementing RUP within PRINCE2




THE ROLE OF METHODOLOGIES
“I keep six honest serving men

        They taught me all I...
Implementing RUP within PRINCE2



•            A programme management methodology (how the overall programme will be mana...
Implementing RUP within PRINCE2



Achieving compatibility between methodologies
Before different methodologies can be int...
Implementing RUP within PRINCE2



Terminology is only really incompatible when different methodologies attach different
m...
Implementing RUP within PRINCE2



Disciplines, processes or workflows
Methodologies also prescribe a set of disciplines. ...
Implementing RUP within PRINCE2




COMBINING PRINCE AND RUP
PRINCE and RUP are designed for project management and specia...
Implementing RUP within PRINCE2




Terminology

As described earlier, terminology is part of the identity of a methodolog...
Implementing RUP within PRINCE2



At the project management level, the following guiding principles are prescribed by bot...
Implementing RUP within PRINCE2



•   PRINCE also has a distinct stage for Closing the Project, thus creating the possibi...
Implementing RUP within PRINCE2



compatibility. The role of Team Manager in PRINCE is an optional role that only acts as...
Implementing RUP within PRINCE2




Processes, disciplines and workflows
At the programme management level, the only proce...
Implementing RUP within PRINCE2




In a combined model it is no longer necessary to include a project management discipli...
Implementing RUP within PRINCE2



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

Managemen...
Implementing RUP within PRINCE2



processes, guidelines, templates). This continues to be a specialist artifact, but it i...
Implementing RUP within PRINCE2




Summary of changes required

PRINCE and RUP can be combined effectively by implementin...
Implementing RUP within PRINCE2



The following is the RUP process model for the specialist level. It has been modified t...
Implementing RUP within PRINCE2



Changes required to RUP for the specialist level

•   Modify the environment discipline...
Implementing RUP within PRINCE2




RECOMMENDED APPROACH FOR COMBINING
PRINCE AND RUP

Keeping PRINCE and RUP distinct
As ...
Implementing RUP within PRINCE2




There would therefore be two levels of methodology, the company-wide level and the pro...
Implementing RUP within PRINCE2




Assess the development organisation
The first step should always be an assessment of t...
Implementing RUP within PRINCE2



In the case of RUP the environment is implemented by creating a customised version of t...
Implementing RUP within PRINCE2



WHAT NEXT ?

We have now seen that PRINCE and RUP can be combined, distinctly, to provi...
Implementing RUP within PRINCE2




Appendix A: Brief introduction to PRINCE
PRINCE (PRojects IN Controlled Environments) ...
Implementing RUP within PRINCE2



There are however additional, more specific, features of PRINCE that we believe add to ...
Implementing RUP within PRINCE2



Structure of PRINCE

PRINCE is provided as a set of manuals.
In its “out of the box” fo...
Implementing RUP within PRINCE2



The eight processes prescribed by PRINCE are the following:

1. Direct the Project (DP)...
Implementing RUP within PRINCE2



The PRINCE process diagram




Relevant techniques prescribed by PRINCE

PRINCE recomme...
Implementing RUP within PRINCE2




Appendix B: Brief introduction to the Rational Unified
Process (RUP)
The Rational Unif...
Implementing RUP within PRINCE2



1.3 Verify quality

Quality management in RUP is defined at a greater level of speciali...
Implementing RUP within PRINCE2




The four phases are:

2.1 Inception

During this phase the project’s objectives are de...
Implementing RUP within PRINCE2



3. Disciplines:
Each of the following nine disciplines is enacted at each and every ite...
Implementing Rational Unified Process Within A Prince2 Envir
Implementing Rational Unified Process Within A Prince2 Envir
Implementing Rational Unified Process Within A Prince2 Envir
Implementing Rational Unified Process Within A Prince2 Envir
Implementing Rational Unified Process Within A Prince2 Envir
Implementing Rational Unified Process Within A Prince2 Envir
Upcoming SlideShare
Loading in...5
×

Implementing Rational Unified Process Within A Prince2 Envir

2,684

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,684
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
109
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Implementing Rational Unified Process Within A Prince2 Envir

  1. 1. 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
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×