Integrating the Rational Unified Process with Managing Successful Programmes

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Russell Norlund, Principal Consultant, FMI Solutions (FMIS)

15 Jun 2005

from The Rational Edge: This article outlines how to integrate RUP and MSP to address gaps in MSP in the important areas of business modelling, requirements management, and tool support. The end result is a more comprehensive approach for analysing and specifying the transformation of an organisation and the use of modern software tools and techniques.

Editor's note: The following article describes Managing Successful Programmes (MSP), a methodology popular in the United Kingdom. We intentionally left Russell Norland's British spellings -- such as organisation and programme -- to retain the flavour of his English for our international readers.

In today's business environment, pressure for change comes from diverse sources, such as government initiatives, increased competition from third-world competitors, and so forth. Programmes are the main vehicle for implementing business change whilst maintaining alignment with overall business strategies.

Managing Successful Programmes, or MSP, provides a non-proprietary best practice approach for programme management. Developed by the UK Office of Government Control, the method has been used successfully in both the public and private sectors. The Rational Unified Process,® or RUP,® provides a well-organised approach to the development of software products, utilising a set of project phases, disciplines, and iterations. It has also been used successfully throughout the public and private sectors. Organisations can derive great benefit from combining these two management methodologies for use in business transformation projects and programmes.

Figure 1 shows that the MSP and RUP programme management approaches are largely complementary.

Figure 1: Programme management approaches

Note that MSP lacks a number of important elements:

• A formal approach for analysing and specifying organisational structure and processes
  
  
• Methods for capturing and eliciting business requirements
  
  
• Methods for tailoring the process to individual organisations
  
  
• Internal tools and methods for identifying, capturing, and analysing metrics (benefits)
  
  
• Document templates
  
  
• Detail for core roles, such as business analyst

This article describes how adopting software engineering methods from the RUP can address some of these shortcomings and lead to more effective delivery of business change.

What is RUP?

The Rational Unified Process, or RUP, provides a well-organised approach to the development of software products, utilising a set of project phases, disciplines, and iterations.

As Figure 2 shows, the RUP development lifecycle consists of four sequential phases (top of diagram) that deal with financial, strategic, commercial, and human project aspects. Nine core disciplines (left of diagram) deal with technical aspects of the project, including business modelling, implementation, test, and so forth.

Figure 2: RUP overview

Each phase of a RUP project is further subdivided into iterations (bottom of diagram); these encompass development activities that produce a release of executable software.

As Figure 3 shows, each RUP role is responsible for a set of activities and an associated set of artifacts¹ (products). Each artifact is supported by a set of guidelines that show how to develop, evaluate, and use the artifacts.

Figure 3: RUP activity components

Each activity is supported by a work guideline that explains how the work is to be carried out. Tool mentors describe how software tools support the activity.

Back to top

What is MSP?

Managing Successful Programmes, or MSP, was developed by the Office of Government Commerce (OGC) in conjunction with industry experts, including BT, Logica, public sector organisations, and others. A vehicle for implementing business change, it consists of a set of key principles and processes for effective programme management.

As Figure 4 shows, the MSP process lifecycle is composed of a number of processes.

Figure 4: MSP process lifecycle

Table 1 outlines each of these processes.

Table 1: MSP processes

Table 2 outlines the key aspects of MSP that contribute to the successful delivery of a programme.

Table 2: Key aspects of MSP

Back to top

Using RUP with MSP

Table 3 highlights areas in MSP that could be enhanced by the use of RUP documents.

Table 3: RUP and MSP documents

As Table 3 shows, the following aspects of MSP could potentially benefit from RUP:

• Management of scope and change
  
  
• Issue and risk management
  
  
• Quality management (including CM and audit)
  
  
• Issue and risk management
  
  
• Benefits management
  
  
• Stakeholder management

Below we will consider each of these above aspects in turn, highlighting overlaps and gaps, and resolving inconsistencies.

Management of scope and change

As Table 4 shows, there is major overlap between RUP and MSP in two major documents. In both instances, the recommendation is to replace the MSP document with the RUP document.

Table 4: Vision and architecture documents in RUP and MSP

Table 5 shows which RUP documents organisations can adopt to supplement MSP documents. These documents, from the RUP Business Modeling and Requirements disciplines, are principally used to:

• Analyse the current and target organisation.
  
  
• Capture and document business requirements so the organisation can size and scope the project.

Table 5: Supplementing MSP with RUP documents for scope and change management

Appendix A provides more detail on the RUP Business Modeling discipline.

Issue and risk management

Table 6 suggests how to resolve overlaps between MSP and RUP documentation in the issue and risk management area.

Table 6: Resolving MSP and RUP issue and risk management overlap

Quality management (including CM and audit)

Table 7 suggests how to resolve the overlaps in this area.

Table 7: Resolving MSP and RUP quality management overlap

RUP business modeling techniques can also help to formally define programme management policies, standards, and procedures.

Benefits management

As Table 8 shows, both MSP and RUP use a business case to define a programme's potential benefits. This table also shows which RUP documents supplement the MSP's benefits management offerings.

Table 8: Resolving RUP and MSP benefits management overlap

Stakeholder management

Both RUP and MSP emphasise the importance of stakeholder buy-in and delivery of tangible business benefit to the customer.

The MSP Stakeholder Map lists each of the primary stakeholders and their interest in the programme. This document's primary purpose is to serve as the basis for the programme's communication strategy. To capture a more detailed analysis of stakeholder needs and requirements, the RUP Vision document may be a better vehicle.

The Vision can create a common understanding of the motivation for undertaking the programme. This document, which is public, shared, and agreed upon by all stakeholders, provides the means for managing stakeholder expectations, based on their particular interests and needs.

Aligning MSP and RUP documentation

Table 9 shows an alignment of MSP and RUP artifacts, based on the resolutions recommended above.

Table 9: Aligned MSP and RUP documents

Applying RUP to the MSP lifecycle

Figure 5 shows how a subsection of the RUP disciplines can be applied across the MSP lifecycle. Most of the MSP processes have been grouped into two disciplines:

• Programme management (benefits, risks and issues, finance, quality, planning processes)
  
  
• Business change (stakeholders, communication)

Figure 5: Application of RUP disciplines to the MSP lifecycle

The RUP disciplines that can compensate for gaps in MSP are shown in Table 10.

Table 10: RUP disciplines to adopt for MSP

Where appropriate, use as much of the RUP discipline as possible to save time and effort. If you tailor a discipline, capture it in the RUP Development Case document.

One additional benefit worth mentioning is that RUP comes with a comprehensive set of artifact templates and examples. These templates reduce the amount of effort required to create documents and institute a consistent approach in the organisation. They also help to reduce learning curves.

Impact of RUP on programme organisational structure

Figure 6 shows a generic programme organisational structure. Introducing RUP would have greatest impact on the Programme Support Office.

Figure 6: Typical programme organisation

In MSP, the main responsibilities of this office are:

• Administer programme processes.
  
  
• Define programme contents.
  
  
• Quantify programme costs and benefits.
  
  
• Identify and initiate component projects.
  
  
• Provide a design authority capability.
  
  
• Provide aid in communications planning and marketing.

To support the RUP enhancements, the Program Support Office will need to add the RUP roles shown in Table 11.

Table 11: RUP roles needed to support a RUP / MSP integration

IBM Rational tool support

All of IBM Rational's automated tools are designed to support RUP. Figure 7 shows a selection of planning, configuration, requirements management, and visual modelling tools that can provide automated support for developing programme artifacts, enabling the team to save time, reduce effort, and improve communications.³

Figure 7: IBM Rational toolset applied to programme management

Table 12 describes a selection of these IBM Rational tools.

Table 12: Selected IBM Rational tools that speed and support software development

Back to top

Conclusion

To recap the benefits of combining RUP and MSP, we can say that RUP supplements MSP effectively in the following key areas:

• Organisation structure -- RUP defines a set of technical roles to support the programme, including business analyst, systems analyst, configuration manager, and so forth.
  
  
• Benefits management -- RUP's measurement techniques can improve the measurement of programme progress and benefits delivery.
  
  
• Scope management -- The RUP Business Architecture document provides a concise but rigorous definition of business scope.
  
  
• Stakeholder management -- RUP provides mechanisms for capturing, managing, and reaching agreement on stakeholder needs and requirements. Shared understanding of needs enhances the chance for programme success.

Combining the engineering methods, techniques, and tools from RUP with the programme management practices embodied in MSP yields a "best of both worlds" solution that includes the following benefits:

• A rigorous approach for analysing and specifying organisation structure and processes
  
  
• Formal methods for eliciting, documenting, and managing business requirements
  
  
• A process tailored to programme needs
  
  
• Supporting software tools that can save time, reduce effort, and improve team communications
  
  

With MSP providing the "what" and RUP providing the "how," your prospects for delivering successful programmes are greatly improved.

Back to top

References

Office of Government Control (UK), Managing Successful Programmes. HMSO, 1999. ISBN: 0113300166

Philippe Krutchen, The Rational Unified Process: An Introduction, Second Edition. Addison-Wesley, 2000. ISBN: 0201707101

Walker Royce, "Improving Software Economics, Part III," The Rational Edge, June 01, 2001.

Back to top

Appendix A: Business modelling

The major product of a business change project is change, which may impact:

• Business processes
  
  
• Business organisational areas (business units)
  
  
• Business locations
  
  
• Business data
  
  
• Business applications
  
  
• Business technologies
  
  
• Business service levels
  
  
• Business competency requirements

Without assessing these changes, it is impossible to:

• Estimate project costs.
  
  
• Effectively scope, plan, and manage the project.
  
  
• Fully model or document the changed organisation.

In MSP, this key information is captured in two key documents:

• The Vision
  
  
• Blueprint

The Vision communicates the programme's end goal to the stakeholders. The Blueprint, as outlined in Figure A-1, outlines the realisation of the Vision within the changed organisation.

Figure A-1: Vision and Blueprint in MSP

MSP does not offer tools, methods, and techniques for creating the Blueprint. The RUP Business Modelling discipline does provide these. This discipline describes how to develop a Vision of the new organisation that will be installed after the business change is complete. In addition, based on this Vision, it also defines the processes, technology, roles, and responsibilities of that organisation in a Business Architecture document.

Figure A-2: Key business modelling roles and documents

Figure A-2 outlines the key role and document within business modelling. The business process analyst leads and coordinates the business modelling effort and is responsible for the following key documents:

• Business Vision -- communicates the end goal of the change programme. Paints a simple picture of how the business will be transformed once the change is implemented.
  
  
• Target Organisation Assessment -- describes the current status of the organisation in which the change is to be deployed.
  
  
• Business Use Case Model -- models intended business functions. Used as an essential input to identify roles and deliverables in the organisation.
  
  
• Business Object Model -- models how business workers and business entities need to relate and collaborate to perform the business process.
  
  
• Business Architecture Document -- documents the architectural views of the business:
• Business process view -- outlines key business processes.
  
  
• Organisation structure view -- outlines and groups key business roles and responsibilities.
  
  
• Culture view -- expresses a vision of the organisation's culture and defines mechanisms to encourage that culture.
  
  
• Human resource aspects view -- discusses mechanisms to maintain and develop the staff's skill set.

Back to top

Appendix B: Process engineer role

RUP defines this role's responsibilities as follows:

• Assist programme manager and / or team in the use of the methodology (MSP / RUP) for the purpose of creating the project work breakdown structure and schedule that will be used in the development effort.
  
  
• Mentor the project team throughout the life of the programme on the methodology on an as-needed basis. This includes providing guidance to the team on tasks, task dependencies, techniques, and deliverables and task roles.
  
  
• Audit deliverables produced by the team to verify that they align with the methodological approach to the project and that they further the progress of the project.
  
  
• Monitor and provide periodic status to the programme manager and advice to the programme team on development progress, schedule, possible risks, necessary modifications of methodology, and any other issues regarding the programme's alignment with the methodology employed.
  
  
• Provide input to the process improvement group on changes that have been made to the programme plan for the purpose of updating the methodology for future use.

Back to top

Notes

¹ An artifact can be a model, a model element, or a document. A document can encompass other documents.

² Roles are not individuals! Individual programme members will wear different hats or perform different roles (i.e. people can be multi-skilled)

³ See Appendix B.

About the author

		Russell Norlund is principal consultant at fmisolutions, a leading software process improvement consultancy and IBM Rational Premier Partner. Specializing in process engineering and program and project management, he is an IBM Rational certified RUP consultant and holds professional qualifications in PRINCE2 and Managing Successful Programmes. He has been involved in roll-outs of RUP and the IBM Rational toolset within some of European's largest companies. His sixteen years of prior experience in the mobile telecommunications industry covered areas as diverse as software architecture, development management, process management, software process improvement, and program set-up. As a software development manager, he led a team creating state-of-the-art mobile telephony and network management applications for Orange.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top