Rational Unified Process in a public procurement environment
Annette Ibsen TietoEnator Consulting A/S, Denmark
Jesper Rugård Jensen TietoEnator Consulting A/S, Denmark
In a public procurement environment (or rather in most situations of competitive tendering) there is a clear signoff between the offer and the tender. Most often the offer is fixed and any changes requires new contracts and possibly a new procurement process. This is in contradiction to the Rational Unified Process where the requirements are being adjusted throughout the process and furthermore are tested by the parallel implementation of an executable architecture.
In this way the iterative incremental process is diluted (and parts of the analysis activities are removed from the projects). There is thus a risk of the losing the gains of: better control of time, budget and quality.
It is our intention to discuss how to solve this focusing both on the long run and what to do in the short run, i.e. how to adapt the Rational Unified Process to a world of competitive tendering.
Being hurt badly once by the hope of fitting into another's slipper, one isn't likely to try doing it again. This even though the shoe is touted as being flexible and a sure fit for nearly every one.
One the surface processes and glass slippers may not seem to have a lot in common, but the problems of fitting into them are very similar and the consequences of a misfit can be equally disastrous. Both physically and financially.
In the last couple of years the use of a process to support software development activities has gained widespread acceptance. One common denominator in these processes is that they are iterative/incremental. Rational Unified Process (RUP) is one of the new processes. One that right now is looking as the standard modern development process.
RUP is described as a flexible customisable process framework that should be instantiated before being used in a specific environment.
The Rational Unified Process™ (RUP) is a Web-enabled software engineering process that enhances team productivity and delivers software best practices to all team members. RUP is a customisable framework, which can easily be adapted to work the way you work. [2]
But does RUP fit all?
And how flexible is it?
Cinderella's stepsisters wouldn't likely buy a one size fits all process. They already got hurt once by their stepsister's shoe design.
In our daily work using RUP and adapting this process, we have met difficulties applying RUP in working with large organisations who are used to doing waterfall and fixed price projects. They have a hard time incorporating the concepts behind RUP and even though they often find the process interesting, they are too big, too busy or otherwise too set to effectively change direction overnight. What we have noticed is that when we succeed in adapting RUP to a company, they tend to be satisfied with the results.
This paper concentrates on the practical side of using RUP in these environments, but it could be about any modern iterative process such as OPEN [4], XP [5], DSDM [6] i.e. The questions spring from using the process (and parts of it) in practice and from observing our colleagues and customers trying to understand, adapt, and customise the process. One of the obvious stumbling blocks when using (or teaching/discussing) the process is the dichotomy between the iterative/incremental aspects of the process and the use of the process in large projects in a supplier/customer relationship, where a procurement process has laid the foundation for the project.
We want to explore where we stumble in our work with iterative, architecture-centric and use case driven processes and what to do to ameliorate these difficulties.
This paper consists of a short presentation of an iterative/incremental process exemplified by RUP, a description of one type of problems we have met in practice working with our customers and finally some recommendations for long and the short strategies using RUP.
These recommendations are not in any way a silver bullet, but more a way of easing the pain of adapting a new development process and as a starting point for further discussion.
Maybe the slipper can be eased on slowly.
Furthermore there is a split between who do the requirements analysis and who do the actual implementation of the system. This way of working is referred to as fixed price projects, a tendering process, a (public) procurement process. The differences between the above mentioned is mostly a matter of degrees.
We focus on the parts of RUP relevant for the discussion of using RUP in a public procurement environment and will not try to cover all aspects of the process.
Rational has identified six best practices for developing software [3]:
Furthermore we will present the four fundamental phases of RUP as they are important for the discussion on contracts and how to apply RUP in a fixed price project.
Fig. 1 Iterative Development
All software projects of some size are risky. There are unknowns in regards to requirements and technical matters. As software development is concerned with some kind of innovation it is not possible to predict all risks regardless of how experienced the development team is.
The earlier in the lifecycle you can verify that you have avoided a risk, the more stable the project is likely to be. The earlier a risk is handled the less it is going to influence large parts of the project in a negative manner.
In a waterfall lifecycle, it cannot be verified that risks have been avoided or not until late in the lifecycle and this could result in costly over-runs and in some cases even project cancellation. Because using a traditional development process many risks are not even discovered until it is attempted to integrate the different modules of the project.
Fig. 2 Iterative lifecycle
In an iterative lifecycle, the iterations are planned in order to address the identified key risks in descending order of importance. Since the iteration produces a tested executable, it is possible to verify whether a targeted risk has been mitigated or not.
Integration is not one "big bang" at the end because the project now is broken into smaller increments with integration earlier in the process and with fewer elements in the beginning.
Iterative development focuses on the architecture first, and in that way verifying the architecture by doing integration and allowing design flaws to be detected and resolved earlier in the lifecycle
Risks are mitigated earlier. The early iterations are the iterations where we are to discover and address the risks. That means we can resolve major risks before making large investments.
Requirements are dynamic - they will change during the project life-cycle. Therefore you have to evaluate changes, determine their impact on the project and document the tradeoffs and decisions. Furthermore these changes will influence the architecture and the design of the system.
The early iterations of the process should focus on producing and validating a software architecture. This takes the form of an executable architectural prototype that should evolve gradually into the final system in later iterations. An executable architecture is a partial implementation of the system, built to demonstrate selected system functions and properties, in particular those satisfying non-functional requirements, but also the key requirements. It is built to mitigate risks related to performance, throughput, capacity, reliability etc., so that the complete functional capability of the system may be added in the construction phase on a solid foundation, without fear of breakage.
An example of an architectural concern is an integration risk. For example, does the chosen database work properly with the chosen operating system? Another example is performance risk. Is the chosen database fast enough?
RUP is composed of four sequential phases. An assessment is performed at each phase-end to determine whether the stated objectives of the phase have been met. A satisfactory assessment is necessary for the project to move to the next phase.
Inception In the inception phase the scope of the project is defined. The main goal of the inception phase is to achieve agreement among the stakeholders on the lifecycle objectives for the project and the success criteria. 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 be initiated.
The primary objectives of the inception phase include:
Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow) Estimating potential risks (the sources of unpredictability)
Elaboration The goal of the elaboration phase is to baseline the architecture of the system. This baselining is done in order to provide a stable basis for the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (both functional and non-functional) and a risk assessment. The stability of the architecture is evaluated through architectural prototypes.
The primary objectives of the elaboration phase include:
To ensure that the architecture, requirements and plans are stable enough, and the risks sufficiently mitigated to be able to predictably determine the cost and schedule for the completion of the development. To address all architecturally significant risks of the project To establish a baselined architecture derived from addressing the architecturally significant scenarios, which typically expose the top technical risks of the project.
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. This phase focuses primarily on the implementation of the system and is meant to be a fairly stable phase as most of the risks hopefully have been resolved. It is still iterative though and changes to requirements can still arise.
The primary objectives of the construction phase include:
Completing the analysis, design, development and testing of all required functionality. To iteratively and incrementally develop a complete product that is ready to transition to its user community. To achieve some degree of parallelism in the work of development teams. A robust architecture is essential if any significant parallelism is to be achieved.
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.
The primary objectives of the Transition Phase are:
training of users and maintainers assessment of the deployment baselines against the complete vision and the acceptance criteria for the product achieving user self-supportability
In this part we would like to introduce a standard contract template (K33) used extensively in Denmark, the added challenge of participating in a EU setting and how the contract situation fits an iterative process like RUP. These examples should be seen as specific instances of what we see as general problems using an iterative process in an fixed prices setting.
Development of a new application (K33) [8]
The K33 covers deliveries that typically are the result of a lengthy development project and where installation and support often are included in the project. It is hard to formulate exact criteria for evaluating a K33 type of project because it often includes major new functionality.
The contract template supports sequential deliveries of modules where the customer accepts or declines the result on the basis of acceptance tests of the individual modules.
The activities defined by K33 are:
The activities in the K33 contract maps to the waterfall model:
Looking at the K33 standard contract from the waterfall perspective:
The supplier analyse the specification à Requirement analysis The supplier deliver a proposal for solution à Design The supplier implements the system à Code and Unit test The supplier deliver the system à Systemtest and deployment
In the waterfall model the requirements specification is produced in the requirement analysis phase. In the contract situation the customer delivers a complete specification and the supplier has to interpret that specification through e.g. use case modelling. I.e. it is the customer who does the requirement analysis and there is no provisions for the work that the supplier has to do in order to understand the specifications. This is covered in the contract, but the contract doesn't cover the requirements analysis. This split between who produces the requirements and who builds the solution is crucial to the problems with the use of RUP in a fixed price environment.
If the project furthermore is in a EU setting the time to produce the solution is limited. The steps in EU settings are [9]:
The typical project profile below shows the relative duration and effort per phase [3]. It is suitable for projects that has following characteristics:
Fig.4 Typical project profile
When we look at a fixed price contract situation the customer will have completed the requirements specification and expects the supplier to be able to give an offer based on this specification, i.e. the customer expects to be able to move into the construction phase. The customer has completed both the inception and elaboration phases before the supplier enters the stage, but hasn't built an architectural baseline, which is a major critical risk according to RUP.
For the supplier, it will be necessary to reinterpret the requirements, in order to be able to give an offer for the project and therefore work still has to be done in what amounts to the elaboration phase, but time is normally limited for this as the customer considers the project to be ready to enter the construction phase and is not ready to pay for more work in the elaboration phase.
The time spent by the supplier doing this, is often very short and unpaid and it is not feasible to baseline the architecture and address risks. Because of this the elaboration phase gets compressed as illustrated in the figure below and the project may continue into the construction phase with major risks not mitigated.
Fig. 5 Compressed project profile
In a tendering process it is not possible to reiterate and the supplier thus loses the opportunity to do iterative development in a meaningful manner.
The supplier doesn’t have the opportunity to baseline the architecture and address risk before the construction phase and that will be reflected in the eventual offer for the project.
"A fixed price-contract for something that is not well understood either includes large safety factors or is an enormous gamble" [10]
If one is adamant in wanting to continue using a waterfall approach, one fairly obvious approach is to scope the projects more tightly. As it is much easier to succeed doing one or more small projects than a large monolithic one, this will help the chances of the project succeeding. This is difficult to do in a tendering environment, unless the supplier can influence the tendering process in some way or the customers realise the advantages of doing smaller projects. And of course this solution doesn't scale, if e.g. the customer really needs the big, complex solution.
A more comprehensive solution would be to focus on the missing architectural baselining and move this activity into the engineering stage. This baselining activity can either be incorporated as a part of the contract and done by the supplier (sharing the risk) or, if the contractual constraints on change are strict, done by the customer as part of the requirements elicitation activities. It is very risky to do a fixed price project based solely on the requirements specification as written by the customer. If an offer is given without resolving architectural risks, the chances of correctly estimating total cost of the project are not great. The solution is thus to have the engineering stage of the process to incorporate the architectural baselining activity and it should then be possible to do a fixed price project with a bit more assurance than if the project only relies on the detailed, fixed requirements.
This is a temporary measure in that it moves some of the risk resolving into the first part of the project, but does not solve the deeper problem of having what amounts to a waterfall process with requirements specifications frozen at signoff instead of using a iterative process. The reason this seems to be a sufficient short term solution in that it focuses on the architectural risks and how to resolve these and these are crucial for the successful completion of a project. This can also be a difficult solution in that the customer might not want to move such a big part of the development process into the time/material based part of the project fearing to loose control with time and expenses. This is a technical solution and is, as such, not enough to solve what is fundamentally is a cultural issue.
Any short term solutions should focus on minimising the overall risk of the project without antagonising the customer or the supplier. It is of vital importance in such a situation to be aware of how much it is possible to change in the way projects are driven and contracts are specified. It is better to find and implement the two most important best practices than fail implementing them all. We feel that iterative development and risk resolving (especially architectural risk resolving) are very important and will endeavour to do these even in a fixed requirements environment if at all possible, so that when problems arise they will do so early in the project.
And the software crisis is still here: The Danish Audit Department recently made a survey of 124 public projects, started or finished in the period of 1997-1999, where the total cost pr. project should be min. 2 mill. DKr. All offers were given using the K33 standard contract. The total cost for all 124 project was 4.527 mill. DKr. or on average 37 mill. pr. project. 18 of these succeeded (meaning they where on time and budget). 88 projects either ran over estimate or will not be finished at all. The remaining 18 are not finished yet but seem to be successful.
There is a changing awareness of the inadequateness of the existing contracts and the processes supporting these. [11]
This changing awareness will hopefully result in a move towards a process that is more realistic in terms of not trying to fix price and cost before requirements and technologies are explored in sufficient detail.
If such a change is to happen the software development culture of both supplier and customer will have to change. It is necessary for the customer to accept that it is not possible to fix requirements once and for all. In any project of a certain size an iterative approach will have to be used to minimise risk. On the other hand, if this is to happen the customer will want to be able to stop a project, that is getting out of hand, very fast. It is thus necessary to provide the customer with frequent feedback, i.e. not only an iterative but also an incremental process. To avoid iterating forever the customer needs measurable checkpoints at predefined mileposts. The customer gains more control of the process and is able to react to changes in the business domain in a controlled way. The supplier gets to work in more realistic terms and to build up trust between themselves and the customer. Of course if new forms of process are seen as necessary then changes to the contractual templates will have to follow. These will have to reflect the inherently iterative nature of the processes and incorporate the feedback activities in the contract.
To meet these challenges modern software development processes have become oriented towards iterative software development and risk-management that makes it possible to meet the dynamic requirements of the customers. This is a major step towards maturing software development and making it a cost-efficient and quality-oriented.
RUP is one of the iterative software processes that we have experience with. It’s based on best practices drawn from a lot of successful organisations and is a very flexible process. But in order to broaden the scope of the process, some adaptation of the process is necessary. The public procurement process is not based on the idea that software development is dynamic and change is everywhere, but rather the opposite.
To return to the glass slipper: It is not the slipper that is too small but the foot that is too big. But only resizing the foot is too drastic a measure.
Our example of how to handle public procurement is obviously one area that we find is very important to make processes work in accordance with the customer's needs. It is based on our own and our customers experiences working with a modern iterative software development process while also meeting the requirements of fixed-price contracts
The transition to modern software processes and technologies necessitates several culture shifts that will not be easy to achieve. Some of these change will be resisted by customers or by factions within a project or organization. Therefore we think its necessary to adapt the process to the customers world and changing the development culture incrementally. Our recommendation is: Focus the first shift in culture on the architectural baselining.
Our experience tells us that, if the customer agrees to let the supplier do architectural baselining on a time/material basis instead of a fixed price contract, the rest of the iterative approach is more likely to become a success. Otherwise the customer has to pay for not sharing the risk with the supplier in terms of very conservative estimates, resulting in a very expensive offer for the project or in costly overruns or low quality.
[2] RUP online - Rational Unified Process version 2000.02.10
[3] Philippe Kruchten: The Rational Unified Process: An introduction 2nd ed., March 2000
[4] The OPEN methodology Henderson-Sellers, B., 1996, Object Magazine (Nov 1996), 6(9), 56-59 (+ figures)
[5] Kent Beck: Extreme Programming Explained - Embrace Change, 1999, Addison-Wesley Pub Co.
[6] DSDM: Dynamic Systems Development Methods
[7] Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process, January 1999
[8] PLS Rambøll: IT-Købekontrakt 2nd ed., 2000
[9] TietoEnator Consulting: EU settings, April 2000
[10] Watt S. Humphrey: Managing the Software Process, 1989
[11] Danish Data Society: Contracts regarding complex IT - mostly for outsourcing, 2000
The Group specializes in developing and managing its customer’s business operations in the emerging Network and Information Society. Most of the products and services in this new world are produced, distributed and consumed digitally via networks. TietoEnator is playing an active role in building this global society.
TietoEnator aims to be a strategic IT partner to its customers. This requires focusing on businesses in which the company can achieve superior expertise and, in this way, offer significant added value to its customers.
TietoEnator’s services are consulting, development and integration of IT systems, operation and network management and software products. The scope of services covers everything from the supply of single information systems to taking responsibility for a customer’s entire IT operation.
Author: Annette Ibsen, Senior Consultant in TietoEnator Consulting A/S. Education: Software engineer from Odense Tekniske Skole, Denmark, July 1984 I have been working with object technology methods since 1990 in different kinds of business areas, mainly as a method specialist. Now I'm working with Modern Software Processes and Software Process Improvement. In 1999 I got certified as instructor in Rational Unified Process by Rational Corporation and have since worked with implementation of Rational Unified Process.
Author: Jesper Rugård Jensen, Consultant in TietoEnator Consulting A/S. Education: Cand. Scient. Soc. from Roskilde University, Denmark 1992. Certified Sun Java Programmer. Certified Rational OOAD instructor. I have been working with object technologies since 1987. I have been working with TietoEnator since 1997 focusing mainly on the practical sides of object technology analysis/design and implementation. In this capacity I have worked with a range of different customers of all sizes implementing and teaching object technology including RUP and OOAD. Before this I have taught on commercial colleges, including courses on obejct oriented methods at Copenhagen Business College.