A project or organization must right-size the process to their needs. For example, governance, size of the project, regulations etc, drive the degree of formality that should be used in a project. RUP provides pre-configured process templates for small, medium and large projects, which can be used for easier adoption. The ceremony of the process should reflect the goals of the RUP phases. Adapting a process also encourages the continuous improvement of a process in an organization.

This key principle widens the discussion from a pure software requirements point of view, to a higher discussion. This includes business goals and stakeholder needs. Often, they compete and conflict, which needs to be balanced out between the parties involved.

Software engineering is a team effort. With a broad variety of stakeholders, all voices need to be heard. With the increasing demand of globally distributed development, collaboration is enabled through modern communication tools. The collaboration is not limited to requirements, but includes exchange of metrics, test results, release management and project plans. That is especially true for RUP projects which are executed in an iterative-incremental approach.

Projects are delivered, even though often only internally, in increments in an iterative fashion. The increment, which includes the value of the past iteration, is used to measure the progress of the project. That increment is also used to encourage feedback from stakeholders about the direction of the project. This allows projects to adjust to changed situations based on the feedback. The stakeholders on the other side, can influence the shape of the development effort while the project is executed. The combination of the iterative development and the focus on risks in RUP, allows projects an iterative risk-assessment.

This key principle motivates the use of reusable assets such as software pattern, 4GL or Framework to name a few. This prevents software engineers going directly from the requirements to custom-made software code. A higher level of abstraction also allows discussions on different architectural levels. These can be accompanied by visual representations of the architecture, for example using UML.

Quality checks are not only at the end of each iteration but a continuous ongoing activity in the software engineering project, often performed in a daily rhythm supported by the entire team. Automating test scenarios (scripts) helps in dealing with the increasing amount of tests due to iterative development.

Establishing a baseline by which to compare actual expenditures versus planned expenditures
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled outright or it can repeat this phase after being redesigned to better meet the criteria.

The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

This phase must pass the Lifecycle Architecture Milestone by the following criteria:

A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete. A description of the software architecture in a software system development process. An executable architecture that realizes architecturally significant use cases. Business case and risk list which are revised. A development plan for the overall project. Prototypes that demonstrably mitigate each identified technical risk. If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is system architecture.

In this phase, the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.

This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, another iteration of the phase begins.