How PMBOK-RUP-ITIL integration contributes to successful software development projects

 

Manager – Technology Development, Tourism Australia

Introduction

According to The Standish Group research in 2004, only 29% of IT projects succeeded – delivered on time, on budget and with required features and functions. 53% were challenged (late, over budget and/or with less than the required features and functions), and 18% failed (cancelled prior to completion or delivered and never used), as shown in Exhibit 1.

IT Projects Status in 2004

Exhibit 1 - IT Projects Status in 2004

The reasons for this continuing non-performance are several and have not changed much in last 10-15 years. These include:

  • Lack of User Input;
  • Incomplete or Changing Requirements & Specifications;
  • Lack of Executive Support;
  • Technology Incompetence / New Technology;
  • Lack of resources;
  • Unrealistic expectations;
  • Unclear objectives;
  • Unrealistic Time Frames;
  • Lack of processes - project management, software development and implementation, operational.

The list goes on. It is not unusual to see same mistakes being repeated within an organization. The technology is becoming complex – from one-tier to n-tier to Service Oriented architectures, the risks of things going wrong are continuously increasing.

With increasing complexity of technology, the processes have to be adaptable to support such implementations. A good methodology always reduces risks. Industry standards, guidelines and processes help achieve business goals, resolve business process deficiencies, gain a competitive edge, do more with less, or simply provide the equivalent of a thesaurus for better communication. This paper discusses how the integration of the three popular methodologies can be used effectively by an organisation to deliver software projects.

A Guide to Project Management Body of Knowledge (PMBOK® Guide)

The PMBOK®Guide identifies and describes that subset of the Project Management Body of Knowledge, which is generally recognised as good practice. “Generally recognised” means that the knowledge and practices described are applicable to most projects, most of the time, and that there is widespread consensus about their value and usefulness. Good practice does not mean that the knowledge described should be applied uniformly on all projects; the project management team is always responsible for determining what is appropriate for any given project.

The document maps forty-four Project Management processes against the five PMBOK®Guide and the nine PMBOK®Guide knowledge areas. The five PMBOK®Guide Process Groups consist of Initiating, Planning, Executing, Controlling and Closing processes. The nine PMBOK®Guide knowledge areas are Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management and Project Procurement Management.

Rational Unified Process (RUP)

What is RUP?

RUP is a risk-driven, use-case-based, and architecture-centric, iterative software development process. RUP embodies industry-standard management and technical methods and techniques to provide a software engineering process particularly suited to creating and maintaining component-based software system solutions. RUP communicates roles, activities, and artifacts organized by process workflows that guide project teams through software engineering disciplines under the purview of operational business phases and decision making milestones.

RUP‘s foundation consists of three key elements: the role, the activity, and the artifact, as shown in Exhibit 2. The role performs activities and produces artifacts. Each role is primarily responsible for a set of activities and artifacts. But all roles will contribute to other activities and artifacts. Roles, activities, and artifacts are used repeatedly during the execution of workflows. The workflows form a sequence of tasks unique to each of the nine software disciplines in the RUP iterative development software lifecycle framework as shown in Exhibit 3.

Key elements of Rational Unified Process

Exhibit 2 - Key elements of Rational Unified Process

RUP framework

Exhibit 3 - RUP framework

The RUP product is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

Exhibit 3 illustrates the overall architecture of the RUP, which has two dimensions:

img    The horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds. This first dimension illustrates the dynamic aspect of the process as it is enacted and is expressed in terms of phases, iterations and milestones.

img    The vertical axis represents disciplines that logically group activities by nature. This second dimension portrays the static aspect of the process—how it's described in terms of process components, disciplines, activities, workflows, artifacts, and roles.

The graph shows how the emphasis varies over time. For example, in early iterations you spend more time on requirements; in later iterations you spend more time on implementation.

Phase: Inception

The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

Phase: Elaboration

The goal of the elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.

Phase: Construction

The goal of the construction phase is on clarifying the remaining requirements and completing the development of the system based upon the baselined architecture. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimise costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

Phase: Transition

The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.

Best Practices

RUP shows how to apply various software engineering practices. It also provides mentoring on how to make use of various tools to automate a specific software engineering process. Some of the recommended best practises are:

img   Develop Iteratively;

img   Manage Requirements;

img   Use Component Architectures;

img   Model Visually;

img   Continuously Verify Quality;

img   Manage Change.

Information Technology Infrastructure Library (ITIL)

ITIL is the most widely accepted approach to IT Service Management in the world. ITIL provides a cohesive set of best practice, drawn from the public and private sectors internationally. It is supported by a comprehensive qualification scheme, accredited training organisations, and implementation and assessment tools. The best-practice processes promoted in ITIL both support and are supported by the British Standards Institution's Standard for IT Service Management (BS15000).

ITIL consists of a series of books giving guidance on the provision of quality IT services, and on the accommodation and environmental facilities needed to support IT. ITIL has been developed in recognition of organisation's growing dependency on IT and embodies best practices for IT Service Management.

Service Management processes cover two core areas Service Support and Service Delivery. The functions and processes are described below.

Service Desk

The goal of Service Desk is to act as the central point of contact between the User and IT Service Management; and to handle Incidents and requests and provide an interface for other activities such as Change, Problem, Configuration, Release Service Level,and IT Service Continuity Management.

The Service Desk is a function essential to effective Service Management. It is the principal operational interface between IT and their users.

Incident Management

The goal of Incident Management is to restore normal service operation as quickly as possible with minium disruption to the business, thus ensuring that the best achievable levels of availability and service are maintained.

“An Incident is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in the quality of that service”.

Problem Management

The goal of Problem Management is to minimise the adverse effect on the business of Incidents and Problems caused by errors in the infrastructure, and to proactively prevent the occurrence of Incidents, Problems, and errors.

Configuration Management

Businesses require quality IT services to be provided economically. To be efficient and effective, all organisations need to control their IT infrastructure and services. Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence.

Configuration Management covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships. Items that should be under the control of Configuration Management include hardware, software, and associated documentation.

Change Management

The goal of Change Management is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of any related Incidents upon service.

In order to be able to define clear boundaries, dependencies and rules, Change Management should be integrated with processes used to control very large organisational programs or projects.

Change Advisory Board (CAB)

The Change Advisory Board is a body that exists to approve Changes and to assist Change Management in the assessment and prioritisation of changes. As, and when, a CAB is convened, its members should be chosen who are capable of ensuring that all Changes are adequately assessed from both a business and a technical viewpoint. To achieve this mix, the CAB needs to include people with a clear understanding of the Customer business needs and the User community, as well as the technical development and support functions.

Release Management

The goal of Release Management is to take a holistic view of a Change to an IT Service and ensure that all aspects of a Release, both technical and non-technical are considered together.

Service Level Management (SLM)

The goal of Service Level Management is to maintain and gradually improve business aligned IT service quality, through a constant cycle of agreeing, monitoring, reporting and reviewing IT service achievements and through instigating actions to eradicate unacceptable levels of service. SLM ensures that the service targets are documented and agreed in Service Level Agreements (SLAs) and reviews the actual service levels achieved against their SLA targets.

Financial Management for IT Services

The goal of Financial Management is to provide a cost effective stewardship of the IT assets and the financial resources used in providing IT resources.

Capacity Management

The goal of Capacity Management is to understand the future business requirements (the required service delivery), the organisation's operation (the current service delivery), the IT infrastructure (the means of service delivery), and ensure that all current and future capacity and performance aspects of the business requirements are provided cost effectively. The Capacity Management ensures that IT processing and storage capacity provisioning match the evolving demands of the business in a cost effective and timely manner.

IT Service Continuity Management

The goal of IT Service Continuity Management is to support the overall Business Continuity Management process by ensuring that the required IT technical and services facilities can be recovered within required and agreed business time-scales. It is concerned with managing an organisation's ability to continue to provide a predetermined and agreed level of IT services to support the minimum business requirements following an interruption to the business.

Availability Management

The goal is to optimise the capability of the IT infrastructure and supporting organisation to deliver a cost effective and sustained level of availability that enables the business to satisfy its objectives. It ensures that the services are available when the Customer needs them.

PMBOK®Guide -RUP-ITIL Integration

PMBOK®Guide -RUP Integration

The level of integration depends on an individual organisation's requirements but the recommendation is to use PMBOK®Guide for all project management artifacts and use some of the best practises from RUP.

img   Develop Iteratively

o  All project schedules have iterations

o  Every iteration has deliverables

o  Address high risk use cases in early iterations

img   Manage Requirements

o  Traceability among functional requirements, use cases and test cases

o  Use RUP templates for scoping

■   Vision

■   Use Cases Scenarios

■   Use Case Diagrams

■   Schema

■   Glossary

■   Supplementary Requirements

o  Use Rational toolset

■   Rational RequisitePro

■   Rational Rose

■   Rose Modeller

■   Rational SoDA

img   Use Component Architectures

o  Reuse existing components to reduce costs and leverage existing technology components

img   Model Visually

o  Using UML (Unified Modelling Language)

o  Capture processes using Activity and Use Case Diagrams

o  Mapping Logical to Physical Architecture

img   Continuously Verify Quality

o  Technical artifacts by SME (Subject Matter Experts)

o  Project Management artifacts by PMO Manager

img   Manage Change

o  Implement Source Control

o  Implement Change Request Management

PMBOK®Guide -ITIL Integration

The recommendation is to integrate three ITIL processes with the Project Management methodology to provide a seamless transition from Projects to Operations:

img   Configuration Management

o  Record information of Configuration Items in Configuration Management Database (CMDB)

o  Maintain baseline for Change Management

img   Change Management

o  Establish Change Advisory Board (CAB) for the organisation and Program specific CABs to manage Project and Operational Changes

img   Release Management

o  Plan & manage all major Hardware & Software rollouts and Change Requests

o  Ensure rolled out items are secure and traceable via CMDB

How does integration help

The integration allows an organisation to implement best of breed processes via PMBOK®Guide, RUP and ITIL. The Project Management Methodology can remain independent of software development domain. The Requirements Gathering process is uniform and has consistency and quality in Requirement artifacts. The projects are delivered iteratively which increases the acceptance of project deliverables by the customer and reduces the risk of delivering something which is not as per user expectation. The detailed Requirement artifacts may allow engagement of vendors under fixed price contracts thus bringing certainty on costs. The users can be involved in testing in early iterations thus eliminating a large testing effort at the end of project as in a typical waterfall approach and instead spreading it over the project duration.

The implementation of ITIL Configuration, Change and Release Management processes allow integration of projects with the operations. As proper Configuration Management controls are extended to applications software development, the influence of Change Management spreads to the requirements specification. Requirements specifications can take into account infrastructure management issues at the design stage. By so doing, infrastructure management not only improves the chances of smooth live operations of new applications, but also reduces the problem of maintenance. In terms of progress of program development, it makes sense for Change Management to know what is going on, but day-to-day version control and so on is more sensibly left to the applications development team, with emphasis on good and rapid communications.

Integration has helped Tourism Australia increase the project delivery success rate. For example, Oracle CRM was implemented in the organisation in 3 months. Multiple iterations were used for the delivery and testing.

Conclusion

For organisations involved in software development and implementation projects, it is important to assess maturity of Requirements Gathering, Software Development and Operational processes. The relevance of RUP and ITIL can be investigated then. RUP processes are mature and cover the entire spectrum of software development – it is important to identify which ones are relevant for the organisation. Similarly, as ITIL processes cover entire IT Operational area, it is relevant to see where the focus should be. The implementation and integration of the processes take time and need to be planned with a long term strategy of the organisation in mind.

References

Cottrell, B. (2003) Integrating Project Management Institute's PMBOK® and Rational Unified Process®. Retrieved on 10/01/2005 from http://webinars.raindance.com/iccdocs/pubDocument.shtml.

IBM. (2003) Rational Unified Process (Version 2003.06.00). IBM

IT Service Management Forum. (2003) IT Service Management (Version 2.1.b, 2003, May). itSMF.

Office of Government Commerce (OGC). (2000). ITIL Service Support CD (Version 1.2, 2000, September). The Stationery Office

Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge – Third Edition (PMBOK® Guide). Newtown Square, PA: Project Management Institute.

Standards Australia (2004). ICT Service Management– Specification for Service Management (AS8018.1-2004). Sydney, NSW: Standards Australia.

Standards Australia (2004). ICT Service Management– Code of practice for Service Management (AS8018.2-2004). Sydney, NSW: Standards Australia.

The Standish Group (2004), Chaos Demographics and Project Resolution - Third Quarter Research Report, Retrieved on 10/01/2005 from http://www.standishgroup.com/quarterly_reports/pdf_copy/q3_intro.pdf

© 2005, Sandeep Mathur
Originally published as a part of 2005 PMI Global Congress Proceedings – Singapore

Advertisement

Advertisement

Related Content

Advertisement