Professional Documents
Culture Documents
Implementing Rational Unified Process Within A PRINCE2 Envir
Implementing Rational Unified Process Within A PRINCE2 Envir
Laurence Archer
31st October 2001
www.oakms.com www.oakms.com.au
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
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 Softwares 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
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
PRINCE
PRINCE (PRojects IN Controlled Environments) is a generic structured method for effective project management. It was developed by the UK Governments 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
RUP
The Rational Unified Process (RUP) is a proprietary methodology described as a software engineering Process. Rational Softwares 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
Page 5
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.
Page 6
Page 7
Project Management
Project Organisation Project Lifecycle Management Stakeholder Management Planning Controls Risk Management Change Request Management Quality Management
Specialist Mgmt
software engineering includes disciplines such as: Requirements Management System Architecture Modelling and design Testing and verification Configuration Control
Page 8
Methodologies apply to each level of managing business change. A software development project within a programme of business change requires:
Page 9
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)
Project
PRINCE
Specialist
RUP
Page 10
Project
PRINCE
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
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.
Page 12
Page 13
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
Specialist
RUP
Page 14
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 Managers delegated authority (tolerance), beyond which an exception is raised The customer / supplier relationship
Page 15
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 projects 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
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.
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
compatibility. The role of Team Manager in PRINCE is an optional role that only acts as a placeholder for the specialist roles in RUP. The various products defined in PRINCE as responsibility of the Team Manager therefore can be assigned to one or more of the RUP specialist roles. The proposed combined set of roles is as follows.
Management Level Programme Management PRINCE Project Board Executive Senior User Senior Supplier Stakeholders Project Manager Project Assurance Project Support RUP Stakeholders
Project Management
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
Page 18
Planning (PL) Controlling a Stage (CS) Managing stage Boundaries (SB) Manage Product Delivery (MP) Close Project (CP) Specialist
Page 19
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.
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 RUPs 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
Project Management
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
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.
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 o o o Determining the length of an iteration Determining the number of iterations Aligning the traditional waterfall review sequence with the iterative approach 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
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
Specialist
Planning Planning
Page 23
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
Disciplines Business Modelling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Mgmt Project Management Environment
Design
Close A Project
Initial
Elab #1
Elab #2
Const #1
Const #2
Const #n
T ran #1
T ran #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 o o Prepare Project Environment Produce Business Vision 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
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 o o o Manage Iteration process Iteration Plan artifact Iteration Assessment artifact 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 o o o o o o o o o o Business Case Software Development Plan Problem Resolution Plan Risk Management Plan Issues List Risk List Product Acceptance Plan Quality Assurance Plan Review Record Status Assessment Work Order
Page 25
Page 26
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.
Page 27
Page 28
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 organisations 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.
Page 29
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 organisations 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
Page 31
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 Managers 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 projects 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
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 organisations 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
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 projects 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
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 customers 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
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
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
Page 37
The four phases are: 2.1 Inception During this phase the projects 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
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
3.5 Testing The purpose of testing is: To verify the interaction between objects To verify the proper integration of all components of the software To verify that all requirements have been correctly implemented To identify and ensure defects are addressed prior to the deployment of the software
3.6 Deployment The Deployment discipline describes the activities associated with ensuring that the software product is available for its end users. There are three modes of product deployment described in RUP: The custom install The "shrink wrap" product offering Access to software over the internet
3.7 Configuration and Change Request Management An organization's Configuration and Change Request Management System (CM System) holds key information about its product development, promotion, deployment and maintenance processes, and retains the asset base of potentially re-usable artifacts resulting from the execution of these processes. A CM System is essential for controlling the numerous artifacts produced by the many people who work on a common project. Control helps avoid costly confusion, and ensures that resultant artifacts are not in conflict due to some of the following kinds of problems: Simultaneous update Limited notification Multiple versions
3.8 Project Management The project management workflow presents an approach to managing the project that will markedly improve the odds of delivering successful software. Its purpose is: To provide a framework for managing software-intensive projects To provide practical guidelines for planning, staffing, executing, and monitoring projects To provide a framework for managing risk
This workflow focuses mainly on the important aspects of an iterative development process: Risk management Planning an iterative project, through the lifecycle and for a particular iteration Monitoring progress of an iterative project, metrics
3.9 Environment The environment workflow focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team.
Page 40
The development environment for a software development project is the term for all things the project needs to develop and deploy the system, such as tools, guidelines, process, templates, and infrastructure.
Page 41
This approach, also known as the waterfall lifecycle, is supported by the principle of phase containment. This requires that you define the project completely and in detail at the start and also that you do not pass to the next phase until the current phase is complete, and then you do not go back. For example, you do not proceed to the design phase until the requirements have been finalised and signed off, and then you do not modify the requirements again. This approach, when applied to software development in the current business context, leads to a number of drawbacks. Two of these are particularly relevant to this paper: Resistance to change. Phase containment naturally resists change, it discourages the business from returning to and changing requirements after they have been signed off. If all design and specification is completed up-front, any change in requirements after that will imply re-work and have an impact on the projects cost and schedule. Changes get significantly more expensive as you move through the project lifecycle. Late risk reduction. In the waterfall lifecycle the project outcomes are not visible and verifiable until the very end, when they are assembled and implemented. Any possible misunderstandings of requirements and errors in design cannot be identified until very late, and then the very principle of phase containment makes it difficult to go back and make the appropriate changes.
Business reality is that the needs of the business will evolve and change even while a single project is being conducted. The final outcome of a project will not be fully defined at the beginning, but it will gradually take shape as the project progresses. Successful projects do not resist change, they facilitate it. Iterative development is an alternative approach to the software development lifecycle that deals with these two drawbacks effectively. It can also be called successive approximations or eating the elephant one byte at a time In iterative development the project is conducted not as a single waterfall, but as a succession of weirs, each of which tackles one part of the overall problem. These are repeated cumulatively until the entire problem has been resolved. Iterative development manages risk up-front while leaving the door open to change. It becomes possible to tackle during the first few cycles or iterations the parts of the problem that carry the highest risk, verify the outcomes and take corrective action before the project has gone too far. Changes can be made to the basic design or architecture
Page 42
before it becomes the basis for further design and development, thus correcting the most expensive mistakes as early as possible. It also becomes possible to have multiple bites at the cherry when dealing with the parts of the problem that are most subject to business uncertainty, thus leaving the door open to finalising these requirements as late as possible in the overall project. This is particularly useful for new and innovative components and elements of the user interface that cannot be fully defined by the business until they can see a usable example. It becomes possible to introduce breakpoints in a project or programme, thus making it easier to bail out but still have delivered something tangible. This keeps senior management and investors happier as they will always see a return on their investment rather than just another expensive failure.
Certain key components can go through a number of successive releases, each of which adds to the previous ones, until the final release contains all the features and functionality required. For example, a project may aim at implementing a customer call centre together with a number of changes to existing systems in order to provide an integrated set of information about the customers. With an iterative development approach one might choose to implement a simplified version of the call centre early in the project, even though the integrated customer data is not yet available. This way the overall architecture and the call centre procedures can be tested and improved early on, and successive versions released as more and more customer information becomes available. We can therefore see that by adopting an iterative approach to software development we can reduce the most important risks early on and manage projects in accordance with the current business environment where requirements are not fully known at the beginning of a project, but take shape during its execution.
Page 43
BIBLIOGRAPHY
Managing Successful Projects with PRINCE2 ISBN 0 11 330855 8 Published by Her Majestys Stationery Office Rational Unified Process Version 2001A.04.00 Software available from Rational Software Managing programmes of business change By John Bartlett ISBN 1 900391 03 X For a very good description of PRINCE, see http://www.uclan.ac.uk/facs/destech/compute/staff/casey/integ/prince.htm For a scientific description of methodology and of cyclical development and water sluice development as instances of iterative development, see http://www-db.stanford.edu/~burback/watersluice/node75.html
For Alistair Cockburns refreshing view of software development as a cooperative game, see http://members.aol.com/humansandt/papers/asgame/asgame.htm
Page 44
Page 45