![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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 artifacts1 (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.
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
|
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.
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.
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
|
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
|
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.3
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
|
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.
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.
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.
Within RUP, there is a documented workflow and associated set of activities to enable production of these documents. In addition, a number of tools can help with the business modelling effort, including IBM Rational Rose, which enables you to produce business use case models.
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.
1 An artifact can be a model, a model element, or a document. A document can encompass other documents.
2 Roles are not individuals! Individual programme members will wear different hats or perform different roles (i.e. people can be multi-skilled)
3 See Appendix B.
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.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
