Risk Management

What is Rational Unified Process, and how should you use it?

What is RUP?

RUP stands for Rational Unified Process. This is a system development methodology that was developed by Rational Unified Corporation, now owned by IBM. Although the author is not affiliated with any of these organizations, he has used the process framework in large development projects.

This process was created by Booch Jacobson, Rumbaugh (often referred to as the Three Amigos), who were largely the creators of UML (“Universal Modelling Language”)). RUP was developed from an analysis of the failure rate in development projects. It is typically 30%.

It is a good fit for the ‘Agile’ project management spectrum, which follows Scrum, XP and DSDM, depending on the complexity of the project and the size of the team.

The project process is designed so that the most risky items, often architecture as well as software and hardware, are addressed first. While the risk of a project being ‘unstoppable’ or collapsing at any stage is reduced initially, aggressive measures are taken to reduce the likelihood that it will collapse. As a result, the risk of failure should diminish as the project progresses. This is quite different from what happens in other non-Agile projects. However, this will not protect you from the risks of a business paradigm shift which has not been anticipated.

RUP is short for nine project disciplines.

Six ‘engineering disciplines’ are included: Business Modeling; Requirements (capture and management); Analysis and Design; Implementation, Testing, Deployment

There are three “supporting disciplines”: Configuration and Management, Project Management, and Environment Management.

Software toolsets, such as UML modelling tools, automated test and test management tools, are extensively used and integrated into project processes. Iterative working is an essential part of the process structure. Products (artefacts) are continually refined and retested (even a plan for testing should be checked against its standards, as it’s a project artefact).

The following four phases are the definition of a project.

1. Inception is the creation of the project’s high-level design. This includes governance, budgets and plans. The Lifecycle Objective Milestone, which is what the project is trying to achieve throughout its lifecycle (including the realisation of benefits), is the exit gateway.

Expected Requirements/Design changes – high Probability of Requirements/Design change – high

2. Elaboration: This involves the expansion of the teams, prototype buildout, enhancements of project processes (eg, testing), and so forth. There is also a formal exit gateway called the Lifecycle Architecture Milestone. It confirms that an executable architectural design has been developed which’realises, that is, physically delivers’, the architecturally-risky Use Cases, and how they are mitigated. It also requires that 80% have been identified and developed, and prioritized according to their risk. The software architecture model and development plan are important ‘tangibles’ that must be completed at this point. This is the point where the project enters a phase that increases the risk profile relative to the complexity of accommodating changes.

Expected Degree of Requirements/Design Modification – Moderate Probability of Requirements/Design Improvement – Moderate

3. Construction – This is the place where the majority of the system is built. Coding and other tasks are also performed here. The Initial Operational Capability Milestone marks the exit gateway. It is, in other words, now “on the runway” at the end.

Related Articles

Expected Degree of Requirements/Design Modification – Low Probability of Requirements/Design Improvement – Moderate

4. Transition – The system is now in production. It is made available to users as a beta version and training is ongoing. It is reviewed against the quality standards established during the Inception Phase. The Product Release Milestone is the exit gateway.

RUP: Why should a project use it?

These are the main reasons.

1. The project risk profile must be pre-loaded.

2. Priority is given for technical risks. Mitigation is established early in the process. If this is not possible, the project will be redesigned or cancelled prior to significant commitments.

Each formal phase and each iteration within that phase have their own inception, elaboration, and construction phases. This is true even for software programmers.

3. Testing is a pervasive of the framework process, with proofs/confirmations/reviews a constant theme, so that problems and issues are flushed out as early as possible.

4. Because it is iterative, it can be designed in a way that a prototype may be produced early rather than a waterfall approach.

5. It’s ideal for larger projects with significant technical risks, or that are “ground-breaking” in other ways.

6. Iterative buildout and incremental delivery are great options for situations in which a business area is experiencing rapid change. The shape of the system can also be matched to the rate of change. However, this will require a flexible underlying system architecture.

When should RUP be used?

A very experienced project manager is required to make it successful. It can be used with a light or heavy touch. A project manager should have the ability to use a ‘contingent approach’ and adjust the intensity to fit the risk profile of each team member. A project manager should be able to tailor the process to their needs. The process framework is very flexible and allows for customization.

The iterative approach is a must for the Technical Architect, Lead Analysts, Lead Designers, and Test Team.

A RUP deployment requires investment in software toolsets, and infrastructure to be effective. The minimum project size that the RUP framework can be used effectively is around 4,000 to 5,000 man hours, unless the organisation is large enough so they can share the overhead with other projects.

People who have been used to a waterfall structure may not be able to understand the iterative approach. The process must be understood at all levels of project governance. Early benefits delivery is almost always an interest at the governance level.


We are a team of professionals with each having two decades of experience in start-ups, sales, marketing, finance, HR, large scale project and profit centre management and running mature cross functional operations. At Molw.net we are big believers that knowledge transfer is critical to our industry’s evolution. We love to share our experiences and learnings through our online resources.

Related Articles

Back to top button