Project Management in a Rational Unified Process

(RUP) Environment

Larry Lambertsen, Director of Technical Solutions, ESI International

Introduction agement and RUP® project life cycles. The final section will outline
considerations for project management in a RUP® environment.
The success rate of information technology (IT) projects is well doc-
umented in literature; the most notable is “Extreme CHAOS” by
The Standish Group. In addition, individual organizations pro- Rational Unified Process®
vide a wealth of antidotal evidence that support The Standish
Group’s findings within their IT group. However, the problems RUP® is one of several object-orient software development
that contribute to a high failure rate for IT projects are varied as the processes currently on the market. RUP® is marketed by Rational
number projects and individual organizations. As a result, there is Software Corporation and is embedded in the company’s various
no clear solution or simple fix for improving of project success. product lines, which consist of online software development tools
Organizations have placed a high priority on improving IT proj- and templates.
ect performance. IT groups were once viewed as a supporting func- As with any process, RUP® is a road map or how to guide for de-
tion within an organization. Project delays generally only affected veloping software. The process is based on certain key assump-
internal operations. Today, IT groups undertake projects that are tions or elements, including:
more closely tied to business objectives of the organization. IT • Product requirements evolve throughout the project, which
project failures can have broad ramifications for an organization, makes it difficult to baseline requirements early in the project
including customer dissatisfaction, loss of market share and lower • High-priority risks should be identified and addressed as early as
stock prices. possible in the development process
IT groups are attacking project performance by investing in its • Quality assurance and testing conducted throughout the devel-
people and examining their processes. Budgets have increased for opment process produces higher-quality products with lower costs
project management, application development skills, and technical • Iterative prototype development is the preferred technique for
training. Organizations are examining how they develop applica- mitigating risks, defining and refining requirements, and quality
tions and manage projects. These organizations can either imple- control
ment internally created software development and project man- • Software development should be viewed from a technical and
agement methodologies or purchase software development management perspective.
methodologies from third-party vendors such as Rational Soft- RUP® consists of a gated four-phase development life cycle that
ware Corporation, IBM, CSC, and a host of other firms. includes Inception, Elaboration, Construction and Transition. The
These third-party methodologies must be integrated with the or- purpose of each phase is well defined and addresses specific soft-
ganization’s existing policies, procedures, and practices. Certain ware development risks. During the Inception phase, the empha-
organizations that advocate modern project management have ex- sis is placed on scope definition and business case formulation.
pressed difficulty in aligning Rational’s Unified Process® or RUP® While all major project risks should be identified and analyzed, pri-
with the Project Management Institute (PMI®) standards. Many be- ority is given to those risks that affect requirements.
lieve that RUP’s® iterative approach and the assumption of chang- The focus of the Elaboration phase is creating a software devel-
ing requirements is incompatible with modern project management opment plan as well as identifying a stable software architecture.
concepts. This belief is not supported as project management con- The software development plan includes an expansion of the re-
cepts are embedded in the RUP® and project management tech- quirements identified in the Inception phase, determining the proj-
niques can be used in a RUP® environment. ect complexity, which is a major consideration for the number of
This paper first provides a brief overview of the RUP® process. This iterations, and project schedule and budget. In addition, the proj-
discussion will provide context for subsequent sections of the paper ect team is evaluating alternative architectures and identifies the
and is not meant to be a definitive white paper on the subject. Next, preferred architecture, as architecture is the major risk element
the paper will identify similarities and differences in the project man- that is addressed during this phase.

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
Exhibit 1. RUP® Phase Deliverables and Success Criteria

Phase Deliverables Success Criteria

Inception · Vision Document or · Stakeholder Concurrence on Scope
Scope Statement · Documented Understanding of
· Initial Use Case Requirements
(Approximately 20%) · Credible Costs and Schedule Estimates
· Initial Business Case · Depth and Breadth of Prototype
· Initial Risk · Actual vs. Planned Expenditures
Assessment
· Preliminary Project
Plan
· One or More
Prototypes
Elaboration · Revised Use Case · Baseline Vision Document
(Approximately 80%) · Measurable Evaluation Criteria for
· Software Development Assessing Initial Iterations During
Plan (Management Plan, Construction
Staffing Plan, Phase Plan, · Credible Costs and Schedule
“Next” Iteration Plan and Estimates
Test Plan) · Actual vs. Planned Expenditures
· Updated Risk Assessment
· Revised Business Case
· Software Architecture
Description
· Executable Architecture
Baseline
Construction · Individual Iteration Plans · Product Stable and Ready for
· Release Description Release
Document · Stakeholder Ready for
· Test Case and Results Transition
· Deployment Plan · Actual vs. Planned
· User Documentation Expenditures
· Incremental ìProductî
Transition · Final Product Release · Customer Acceptance
· Updated Product Documentation · User Satisfaction
· Lessons Learned Analysis · Actual vs. Planned Expenditures

During the Construction phase, project activity is oriented in Management through a formal review process can approve con-
fleshing out the baseline architecture and incrementally developing tinued funding of the project at various checkpoints or gates
the final software product. Product deliverables for this phase throughout the development life cycle. Generally, this review and
would include internal and customer documentation (e.g., user approval process occurs at the end of each phase. RUP® defines this
manual), test beds, test results, and rollout collateral materials (e.g., decision cycle as a milestone, which is a “point in time at which cer-
training programs and materials, marketing materials, etc.). The key tain critical decisions must be made, and therefore key goals must
project deliverable is the iteration plan. Since the work is broken have been achieved” (Kruchten, 1996). The iterative development
into iterations, the project team must prepare a detailed iteration process allows for additional review at the conclusion of each iter-
plan that identifies capabilities being developed, production risks ation, as the software must be successfully tested against objective
being mitigated, and defects being fixed during the planned itera- measurable criteria before the next iteration can commence.
tion. Iteration schedule, budget, and staffing requirements are also Exhibit 1 summarizes the project deliverables and key success cri-
identified in the iteration plan. teria for passing each milestone. The phase deliverables consist of
The Transition phase is concerned with deploying the application both technical and business work products. Technical deliverables
in the user environment. For a commercial product, Transition include prototypes, architectural documents, test cases and results,
phase activities could include sales and marketing, manufacturing, and user documentation. Vision document, use cases (require-
and packaging. User training, application rollout, and help-desk ori- ments document), business case, risk assessment, software devel-
entation are transition activities for internally produced products. opment plan and deployment documentation are considered busi-
Iterations, including general availability, bug fixes or enhancement ness deliverables.
releases, may continue into the Transition phase. During this phase, While phase deliverable include technical and business elements,
the application’s owner formally accepts the product. Additional re- most of the success criteria are business oriented. In reviewing the cri-
visions or enhancements to the product would be considered prod- teria, the emphasis of the success criteria is on stakeholder acceptance
uct maintenance. The project team is concerned with rollout risk. of scope, requirements, and the software product. Regardless of the

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
Exhibit 2. Standard Project Life Cycle—Phases and Activities

1.0 Project Initiation 2.0 Project Solution 3.0 Solution 4.0 Project
Planning Implementation Closure
Develop Opportunity Structure Technical Manage Contract and Close Out Contract and
Profile Solution Vendor Agreements Vendor Agreements

Define Project Select Vendors Manage Resources Close Out Project

Documents
Develop Business Case Prepare Project Plan Manage Scope Changes
Disperse/Reassign
Initiate Project Structure Business Track and Control Project Resources
Solution Progress

Establish Customer Manage Quality and

Contract Acceptance

Prepare for Project Pre-Close Out Review

Execution

phase, budget and schedule (actual and planned) are major consid- strate to management that the project has merit and justifies fur-
eration for a “go/no-go” decision. The success criteria from a technical ther expenditure of limited organizational resources to better de-
perspective are dependent upon the requirements. In other words, fine the project.
does the product perform as required by the customer? In Solution Planning, the purpose is to prepare a technical solu-
tion to satisfy customer requirements through internal planning, and
Project Management Process and RUP® Comparison
with the customer coordination. This technical solution describes
After reviewing the RUP® project life cycle, it appears that RUP® how project objectives will be accomplished and a technical ap-
and project management best practices are consistent. To under- proach outlining the work to be undertaken. The technical solution
stand these consistencies, it is important to review the RUP® proj- also identifies any special or new technologies that need to be de-
ect life cycle against a standard project management life cycle. ESI veloped in order to manage the project, perform project work, de-
International’s project management methodology—ProjectFO- liver the technical solution, or to be incorporated into the product.
CUS®—will be used for this discussion. It is not usual to identify and evaluate multiple approaches be-
As shown in Exhibit 2, the life cycle is divided into four phases— fore settling on an approved technical approach. Prototyping, con-
Project Initiation, Solution Planning, Solution Implementation, cept design or “project work” is common and many times necessary
and Project Closeout. The project planning phases of both to evaluate the alternative approaches. For example in product de-
processes (Initiation/Planning and Inception/Elaboration) are velopment, the project team may test component parts to determine
fairly consistent with each other with some minor exceptions. The if off-the-shelf components can be used or if new components
life-cycle activities diverge during project implementation as the two must be developed. Product requirements, project schedule and
processes have different emphasis. budgets, and risk can be greatly affected depending upon the out-
The main activities during Project Initiation are associated with come of such tests. Concepts and prototypes, in many instances, are
defining the project. As with RUP®, team members during this required in competitive bid situations, especially in the real estate
phase are defining the project’s scope by identifying and under- industry for the selection of architects and design teams. The use
standing high-level requirements, setting project objectives and for prototypes and conceptual design in the planning phase should
identify assumptions and constraints. A business case is also de- not be considered unique to RUP® and are acceptable practices in
veloped at this time to determine the financial impact to the orga- standard project management methodologies.
nization as well as aligning the project to overall goals and objec- The deliverables for this phase is similar to the deliverables in the
tives of the organization. RUP® Elaboration phase—project plan (schedule, budget, and re-
Similar to RUP®, high-level risk are identified and assessed. Risk sources) and any ancillary plans (e.g., change management plans,
mitigation strategies are not developed until subsequent phases. In communications plans, mobilization plans), baseline requirements,
RUP®, risk management in this phase places greater emphasis on and risk plan. While both processes require approval of a “project
requirements risk and suggests that a mitigation strategy be devel- plan,” the information and level of detail may be different. In RUP®,
oped for each risk. the project plan or course grain plan estimates the schedule and bud-
Both processes require a clearly documented scope statement get for the overall project based on the number of iterations (top
for the project, a set of high-level requirements, business case, and down). Detailed information with respect to schedule and budget is
risk assessments. A sufficient level of detail is required to demon- contained in the iteration plan. However, only the first iteration

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
plan is contained in the course grain plan. Conversely, in the tradi- As the name implies, the requirements and business case are re-
tional project management approach, the project plan provides vised and better defined during the Elaboration phase. The project
budget and schedule for the entire project developed by rolling up team has time to conduct due diligence on the technical systems and
the schedule and cost information from the work package level to develop prototypes to determine the effectiveness of alternative
(bottom up). Many organizations that embrace modern project platforms or technologies and to define requirements in more de-
management have adopted a RUP®-style rolling wave planning ap- tail. During this phase, it is intended that requirements become
proach for their multiyear projects where the traditional planning more detailed rather expanding or a change in direction, unless
approach can be not effectively applied. caused by architectural constrains or significant changes in the
At this point in the life cycle, RUP® and the project management business case. Upon achieving the Elaboration phase milestone,
methodology diverge. RUP® activities focus on the completion of baseline requirements are established. Additional requirements or
the software code and associated documentation. RUP® is a soft- changes to existing requirements may be justified.
ware development process, and as expected places greater empha- The steps just outlined are no different than the requirement for-
sis on the “product.” This is not to imply that RUP® ignores the mulation process presented in many project management
schedule and budget aspects of the project. The purpose of a proj- methodologies and is consistent with A Guide to the Project Man-
ect management process is to ensure successful completion of the agement Body of Knowledge (PMBOK® Guide). It is important to
project, which places a greater emphasis on managing project ac- recognize that customers can use the iterative process to accom-
tivities by tracking actual vs. planned schedule and budget. modate unlimited and/or unjustified changes. To resist the plethora
In Solution Implementation, the emphasis is on managing proj- of changes, project managers and the organization must establish
ect execution to ensure the timely completion of all planned work and enforce change management procedures, as any change will im-
within budget and scope with the allotted resources. This phase is pact schedule and budget.
comparable to the Construction and Transition phases of the Myth #2: The iterative development approach does not allow for ef-
RUP® life cycle. The project manager’s responsibility focus on fective project planning.
RUP® employs a rolling wave approach to project planning. The
tracking and controlling activities, including budgets, schedules, and
Software Development Plan (SDP), an Elaboration phase deliver-
scope. Project deliverables generally consist of contract and project
able, consists of several elements including a “course grain” plan and
reviews and status reporting.
initial iteration plan. The course grain plan, which is also referred
During Project Closeout, the emphasis is on performing the ac-
to as the project plan, identifies the number and approximate
tivities to effectively closeout the project. The activities are admin-
length of the iterations. In addition, the course grain plan outlines
istrative in nature and include documenting customer acceptance
what features and functionality will be coded during each iteration.
of work products, ensuring vendor work is complete and invoices
SDA also includes a staffing plan and a high-level project schedule
paid, project documents completed and store in a central location,
based on the number of planned iterations.
and capturing and publishing lessons learned for the organization.
While the project plan provides a general outline for accom-
plishing the project, the iteration plan(s) provides the appropriate
level of detail that is normally provided at the work package level.
Considerations for Project Management within a The iteration plan identifies goals for the iteration, including the ca-
RUP® Environment pabilities being developed, risks being mitigated, defects being fixed
and objective and measurable evaluation criteria for the software
Organizations adopting RUP® or other object-oriented software de- being developed in the iteration in addition to schedule and re-
velopment processes need to understand that such processes are source assignments (Kruchten, 1996). Each iteration plan is pre-
consistent and complementary to modern project management. In pared upon the satisfactory completion of the previous iteration.
fact, organizations can improve the software development process Iterative development provides for more effective planning. It
by incorporating modern project management techniques into the does not necessarily mean that less project planning is required.
development process. If project management process and RUP® is RUP® and its iterative approach, which result in more reliable
compatible, why do organizations have problems reconciling the schedules due to a shorter planning horizon of each iteration plan
two concepts? The answer can be found in debunking three myths (approximately eight weeks). In addition, developers and other
or misconceptions. team members gain valuable experience and insight from early it-
Myth #1: Project management techniques are not effective because erations can provide better scheduling data and results in better ef-
requirements are evolving throughout the development life cycle. ficiencies in coding and testing during subsequent iterations.
During the Inception and Elaboration phases, requirements do Myth #3: For RUP® projects to be successful, the project manager
evolve, as more information about the project becomes available. should have strong technical skills.
Software projects, or any project, are undertaken to address needs As Kruchten notes (1996), RUP® is centered on people, process,
or to take advantage of certain opportunities in the marketplace. and tools and methods. Organizations spend considerable time
The project team, users, customers, management, and other stake- and money on rolling out the process, understanding the tools,
holders articulate these needs and define high-level requirements training their staffs on the process and in project management.
for the new application during the Inception phase. The organiza- These organizations overlook the key element to successful RUP®
tion at this time also evaluates the financial and business implica- projects—effective project managers. This is a problem that is not
tions for undertaking this new initiative. limited to organizations using an object-oriented process or IT

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
groups in general. Most organizations place a high value on tech- Krutchen, Philippe. 2000. From Waterfall to Iterative Lifecycle—A Tough
nical competency and project management knowledge in promot- Transition for Project Managers. Rational Software Corporation.
ing and selecting project managers. Most organizations have job de- Krutchen, Philippe. 2001. What is the Rational Unified Process? Rational
scriptions and defined roles and responsibilities for project man- Software Corporation.
Probasco, Leslee. 2000. The Ten Essentials of RUP: The Essence of an Ef-
agers, but few organizations understand “what characteristics and
fective Development Process. Rational Software Corporation.
attributes makes for a good project manager”?
Rational Software Corporation. 1998. Rational Unified Process: Best
Competency models are used by organizations to identify traits re- Practices for Software Development Teams. Rational Software Corporation.
lated to outstanding performance within professional, technical and Rational Software Corporation. 2001. Planning a Project with the Rational
managerial professions. ESI International’s project management Unified Process. Rational Software Corporation.
model (ESI, 1999) is based on a Department of Defense study of pro- Vawter, Matt. 2001. RUP® for Project Managers: Planning for Iterative De-
gram managers and was validated in a corporate environment. In ad- velopment. Rational Software Corporation.
dition, this model can be applied across industry groups and proj-
ect environments (e.g., IT, product development, etc.). The ESI
model identifies competencies that fall into four primary areas—
leadership, achievement, problem solving, and influence. It is im-
portant to note that technical ability is not included within the key
competencies; however, this is not implying that a project manager
should not be able to understand and articulate technical issues.
RUP® “involves the continuous negotiation of tradeoffs between
the problem, the solution and the plan” (Kruchten, 2000). As a re-
sult, project managers must be able to gather and synthesize infor-
mation quickly, make sound decisions with input from team mem-
bers, and articulate positions and decisions in a clear and concise
manner to stakeholders and team members. Iterative development
process also demands a project manager with leadership and per-
suasive skills for dealing with team members as technical members
have a tendency to gold plate or over design.

Conclusion

Organizations consist of varied and numerous processes. It is not

uncommon for activities to be guided by one or more processes. It
is important to understand how the process guide or affect work-
flow. Problems develop when more than one process have contra-
dictory results and/or become an administrative burden.
RUP® and modern project management methodology are com-
plementary. RUP® guides the development of software applica-
tions. As a result, RUP® focuses on the software product and asso-
ciated deliverables. Project management methodology provides a
framework for managing projects within an organization. The pur-
pose of a project management process is to ensure successful com-
pletion of the project, which places a greater emphasis on manag-
ing project activities. Some project management best practices are
already embedded in RUP®. In fact the Inception and Elaboration
phase follow best practices for project management very closely. Ad-
ditional project management techniques could be incorporated to
strengthen RUP’s Construction and Transition stages.

References
Ambler, Scott. 2001. Completing the Unified Process with Process Patterns.
Ronin International.
ESI International. 1999. Project Management Overview for Managers.
ESI International.
ESI International. 2001. ProjectFOCUS: A Project Management Method-
ology®. ESI International.
Kruchten, Philippe. 1996. A Rational Development Process. Crosstalk (9).

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
Previous Menu