from The Rational Edge: Read how the IBM Rational Unified Process, or RUP, complements the Project Management Body of Knowledge (PMBOK), and how project managers well-versed in PMBOK can use and understand RUP to support the Project Manager (PM) role. This content is part of the The Rational Edge.


Vitalie Temnenco, Software Architect, Sierra Systems

author photoVitalie Temnenco is a software architect with Sierra Systems Inc., where he provides architecture, methodology, and project delivery services to Sierra’s clients. Previously, he was an architect for the Ontario, Canada government's Workplace Safety and Insurance Board, where he provided architectural mentoring on implementation projects and helped teams embrace IBM Rational Unified Process (RUP) and enterprise architecture concepts. His experience includes designing and building solutions for clients in a variety of business domains, such as banking, finance, insurance, retail, and telecommunications, and he teaches UML and RUP for business and systems analysis, as well as in construction of new systems.

developerWorks Contributing author

15 April 2008

Also available in Chinese Russian

illustrationLooking for answers, project managers (PMs) typically bounce from architects to developers, from developers to testers, and so on. Often empowered by Project Management Professional (PMP) certification, PMs find themselves increasingly dependant on domain-specific expertise. They often find that the IBM® Rational® Unified Process®, or RUP®, is the framework chosen by their implementation teams, so they must adjust and rethink what they know according to RUP disciplines.

This article takes a look at project management in the modern, IT-driven enterprise. It explores common misconceptions about RUP as a project management tool, discusses how the Project Management Body of Knowledge (PMBOK) standard intersects with RUP, and explains ways to reduce or eliminate the ambiguity often misperceived to exist when relating these two complementary process frameworks. Finally, it posits and explores the potential value of an enterprise PM role.

By virtue of my experience as an Enterprise Architect, this article also includes a glimpse into the architectural perspective on project management. IT architects can read it in order to understand project managers' expectations, while PMs can read it to learn more about RUP and IT architecture.

Things we already know about project management

According to the popular internet encyclopedia, a project is a "temporary and one-time endeavor to create a unique product or service that brings about beneficial change or added value." Every project requires resources -- including people and cash -- and project management (PM) is a discipline that attempts to organize and manage resources in such a way that a product or a service is delivered within the scope, quality, time, and cost boundaries allocated to the project.

While the project management style often roughly corresponds to the Software Development Life Cycle (SDLC) methodology format being used, such as waterfall, iterative, Rapid Application Development (RAD), or Agile, each project involves a common set of activities, including:

  • Plan, analyze, and design objectives
  • Assess and control risks
  • Estimate and allocate resources
  • Acquire human and material resources
  • Organize work through assigning tasks and directing activities
  • Analyze results based on the achieved value
  • Forecast projects
  • Manage quality
  • Issue prevention and resolution
  • Project closure
  • Project communications
  • Track and report on progress

What is PMI?

The Project Management Institute (PMI) was formed in the late 1960s and is one of the world's leading bodies in the area of the project management. Its membership totals more then 220,000, including 160,000 certified members in more then 170 countries. The PMI developed one of the most all-encompassing PM frameworks (PMP) and provides several levels of project management certifications.

What is PMP?

PMP is the world's most widely recognized PM certification program, in terms of number of individuals certified. It offers three levels, including PM associate, project manager, and a degree in program1 management.

What is PMBOK?

PMBOK is a collection of processes and knowledge assets commonly accepted as a standard for best practices in project management. It consists of five process groups (e.g., initiating and planning) and nine knowledge areas (e.g., scope management and time management) reusable in most projects, and in most business domains, from construction to software engineering. In PMBOK, processes are described in terms of input artifacts, tools, and techniques. Techniques consume and produce the artifacts and use tools.

Different kinds of managers

Among various management roles, only one has a "project" qualifier. In today's dynamic business environment, it stands apart, as it requires understanding of the unique qualities of the project entity, as well as knowledge of an application domain's management principles, which in the case of the software development are "iterative," "architecture-driven," and "risk-mitigating."

Organization manager

In contrast with the definition of "project" as a temporary and one-time endeavor, many organization tasks are repeating, with each repetition having the same basic scope (not to confuse this with iterative implementation, where tasks repeat but produce different scope or detail). Examples are Human Resources and Inventory Management functions, where management activities equate to ensuring adequate, day-to-day, and step-by-step execution of tasks. People who fill this latter role may hold various management positions, and execute various standard management activities.

Project manager

Unlike the other organization management roles, the PM role is specifically formulated to govern unique assignments. Therefore, a PM must be able to understand the scope of the assignment and select and apply an optimal management process in order to deliver a product or a service on time and within other identified constrains. This combined with the need to commence and conclude projects are very essential to a PM's job, and also make it different from the other enterprise management roles.

Acting project manager

Quite often the project gets started without a dedicated PM at all. All-too-common is the situation when a seasoned team member assumes all or some of the responsibilities of a PM. Although, in general, it is better to have someone managing the project temporarily or part-time than no project management at all, to have an acting project manager for a long time is considered a poor practice, as it puts continuity and consistency of decision-making at risk. Moreover, quite often this temporary PM role is assumed by a team member without significant field expertise or without an incentive to have additional responsibilities, which leads to missed expectations, or worst case to a complete project fiasco.

Technical project manager

It is not uncommon for the PM to also play a solution architect or technical lead role. Although this is frequently a poor practice, it works for smaller project teams (usually with less than ten members). One benefit of having a technical project manager on the team is that she may be capable of producing sound project plans, while basing them on a thorough understanding of the requirements and/or design. This, in turn, can help eliminate a "broken telephone" syndrome within the implementation team. The problem is that there may not be enough time for her to work on the project plans, let alone provide effective project coverage and control.

Program manager

Some projects set out to accomplish way more than they can manage. A typical scenario is to introduce a hierarchical project management structure, with the top level called "a program" and projects underneath. Program management is a very special type of project management that deals with projects holistically; while at the same time being knowledgeable about the projects' individual performance. Major responsibilities of the Program Manager include "slicing and dicing" scope into manageable chunks (projects), documenting and managing their dependencies, and planning and running escalation and delegation.

Enterprise project manager

A modern organization is a fairly complex entity where things routinely get done without being set up as projects. One example is enterprise architecture implementation and its various steps, such as vision development, business case development, and business process analysis. Some of these functions can get quite complex and, thus, difficult to manage if they are not contained within firm boundaries in a timely manner. Subject matter experts, such as IT architects, process engineers, and consultants rarely have the skills required to perform formal enterprise PM activities. All of this stipulates a need for the Enterprise Project Manager role, which I expand on below.

A PM's greatest worries

While some PMs appear to be more rational, informed, trusting, or experienced than others, all share the same concerns about the project. The greatest worries are described below.


PMs get disappointed with their architects when they receive estimates that allow 20%, 50%, or even 100% margins for error. Indeed, many industries have achieved a state wherein a project may be quantified, estimated, and planned based only on standard terminology, high-level scope, and industry productivity -- and PMs might well expect the same from software development. This, however, is often too much to expect from IT, where everything from frameworks and platforms to methods and tools is in dynamic transition, which requires a thorough understanding of the requirements in order to produce estimates of adequate precision.

In the software industry today, no quote for a significant amount of work can be produced with reasonable accuracy unless it is derived from detailed, method-specific structured requirements [4] and uses a productivity ratio associated with the previous successfully completed projects, delivered by more or less the same team, which dealt with the same technologies. Estimates produced by architects often relate to unstructured requirements (not good enough), which they adapt from actual similar past solutions (bad), or base on commitments acquired from the project teams (even worse).

Budget and cost

As a proxy in the middle between an organization and the project team, the PM is often caught in the crossfire of demands and realities. One area where this gap is often revealed is in a discrepancy between dedicated resources and estimated costs. In most cases, the issue comes down to the fact that an organization allocated its budget long before the solution requirements were even collected, let alone well understood. In effect, the project team is appointed to understand what can be reasonably built under these circumstances. This leaves the PM to hope that an estimate produced by the architect before the project started will come true.


The success of a project often hangs on whether a project methodology is chosen and followed. In contrast to the construction or manufacturing industries, many styles and flavors of methodology are available to a software project to choose from, ranging from very formal to very agile. The PM often does not get to choose the project's methodology, but its proper execution is almost always a PM's responsibility. Therefore, PMs have to be pragmatic and cooperative when deciding on a project methodology to use.


By the nature of their work, most project managers cannot objectively judge architecture and design decisions. Instead, they have to rely for these key decisions on someone in their team -- usually an architect or a lead developer. It is no surprise that every project manager wants this relationship to work flawlessly. An architect who assists the project manager with deliverables ought to understand the implications of the PM's dependency and be sensitive to it.

Ownership and responsibility

In some organizations bureaucracy and politics overshadow constructive logic. It is great if both the project team and the management team are motivated. In this case they are more likely to choose a "lean" implementation method that can spread responsibilities for individual problems pragmatically across the team. If, however, there is lack of transparency around responsibilities, a PM is better off equipped with an explicit ownership and responsibility approach, perhaps one based on the RACI (Responsible Accountable Consulted Informed) model. A trusted relationship with an architect and a project sponsor is a good start, but is no substitute for a well-articulated ladder of responsibilities. Clear responsibility structure is a safety net for a project manager, which also provides transparency to rest of the project team.

Common misconceptions about RUP

Frequently in my conversations with PMs I hear uncertainty and hesitation regarding the application of project management tasks on RUP projects. The thing that strikes me the most is their scant understanding of RUP concepts and principles. Everyone is usually quick to state that RUP is an iterative process; however, most PMs do not fully understand and appreciate the essential qualities and practical benefits that come from RUP's application. The misconceptions that I encounter the most -- and my resolution for them -- are discussed below.

Misconception: RUP is an alternative to the PMBOK standard

Sadly, RUP is often perceived to be in competition with a project management standard like PMBOK. Perhaps this misunderstanding stems from RUP's definition as "providing a disciplined approach to assigning tasks and responsibilities within the development organization" -- seemingly a project management task. This definition is both not representative and grossly misunderstood.

Although RUP lists project management as one of its nine core disciplines (see Figure 2 below), organizations using RUP may still benefit from having an anchoring project management framework. RUP project management discipline elaborates on select PM aspects that are relevant to planning its activities and executing its tasks, specifically in regards to iteration planning. Unlike PMBOK, RUP does not address project management as an end-to-end process. RUP also completely ignores some important project management-related activities, including people management, resource planning and estimation, escalation, and contact management.

Misconception: RUP is only about use cases

There is no doubt that the use case analysis technique is essential to RUP as it supports one of its key doctrines -- risk-mitigating, iterative implementation. It is, however, wrong to equate use case modeling and analysis to RUP, since RUP permits other notations and techniques, as long as they fit with its basic principles in the context of an iterative lifecycle. The use case analysis technique is especially helpful for describing interaction-intensive software applications, but may be less useful in other solution or application contexts, such as for instance when communication between system users and the system is minimal, or when there is no need to re-capture a flow, such as during Commercial Off-the-Shelf (COTS) implementation. Application of use cases beyond the software development purview may not be a viable alternative either, whereas applying RUP as a process framework and platform of best practices may well be.

Having said that, RUP is not only a container for managing use cases, but also a customizable process framework that can be used for iterative and incremental project delivery. In a broader, enterprise organization methodology context supported by IBM Rational Method Composer, RUP-induced activities, together with activities from other methods and standards, may be used to assemble custom processes that fit organizational needs.

Misconception: RUP diverts attention from project management

Due to its vested accountability for the project and assumed supervisory responsibilities, the role of Project Manager is often considered a powerful role. Although adequate management empowerment is critical to the success of any project, in a highly specialized software development environment, management success is more often conditional on the professional skills of multiple individuals than is the case, for instance, in transportation or mass-manufacturing projects; and therefore the PM role should be treated differently on software projects. In its turn, RUP is not a project management process, and software development is not a "command and control" environment. In RUP, disciplines play a balanced role.

Project management has a pivotal role to play in RUP, which derived its PM discipline from PMBOK. In the reference RUP lifecycle, project management activities commence before activities from any other discipline. In fact, as shown in Figure 2, these activities may commence even before the official RUP project starts (see below). With some caution and requirements-driven scope considerations, PMBOK can thus be used as an anchoring process to setup RUP iterations, as illustrated in Figure 1.

RUP disciplines

Figure 1: RUP PM discipline expanded from PMBOK

Importantly, RUP is agnostic to both bureaucracy and politics [2], so when the project management process is used not as a "cover up," "must have," or "go, go" command sequence but instead to organize and direct professional teams, RUP is definitely there to help keep attention locked on the most important things.

Whether RUP is the best solution to a problem is a different question, however. Some organizations are so far off in their understanding and application of PM standards that I would question whether they should immediately embark on an SDLC methodology such as RUP to improve their affairs. Instead, to catch up with the industry they might consider screening their existing processes, systems, and methods using a structural enterprise architecture framework, such as the Zachman Framework. This may allow them to better understand and document the current state of the IT architecture, and can later be followed by an adoption of a common notation, such as UML, and eventually an SDLC process like RUP [5].

Misconception: RUP is more complex than the waterfall method

If it worked as well in practice as in theory then, perhaps, the waterfall method would represent a simpler management process than RUP, primarily because it does not assume repetitive iteration planning and management. This, however, is only in theory.

For example, in engineering in general, and specifically in the software development, no one can be sure that the original design and, thus, implementation schedule will stay intact for long, let alone until the project end. In fact, the opposite has been proven through many projects. Incremental refinement is inherent in engineering, where, unlike construction or manufacturing, the original design does not stand a chance of surviving for long, while industry dynamics add additional volatility.

Another false assumption is that any complexity can be effectively dealt with in a "big-bang" approach. It has been experimentally (and scientifically) proven that managing growing complexity requires an exponential increase in effort, which in turn results in both a need for additional time and higher skill. RUP, in contrast, has been formulated to reduce complexity by breaking activities into manageable, yet significant chunks, each having a face value to stakeholders, and each implementing incremental changes to user requirements. Having multiple "pseudo-projects" and, thus, an iterative approach as a whole, is deemed as a more project management-intensive process. While it is more intensive, it is also a more reliable and, as a result, less expensive approach to implementation. In practice, an iterative approach usually brings a confidence boost to an engineering team, as well as cost reduction to a project.

Project management in an iterative environment is widely regarded as a professional skill, which depends on a good understanding of principles of incremental design, requirements engineering, and risk management basics. Project management standards like PMBOK are slowly embracing the incremental nature of software engineering and adjust their activities and rules to account for a vision of iterative management. RUP, in turn, attempts to help manage project risks by advocating early intervention and requirements-based project planning, which, although seeming to require greater project management effort, helps to deliver superior results with less risk.

Misconception: RUP offers no obvious entry/exit criteria

It is not clear to some project managers (and, in my observation, other managers also) when a RUP project begins and, to a lesser degree, how it ends. PMs often ask whether PMBOK Initiation activities, such as the one to link scope with strategic objectives and the one to secure project funding occur, during the RUP lifecycle.

It is worth noting (again) that RUP is a solution implementation methodology, which departs from a clearly articulated need to develop a solution for the specific business problem. It is used to address the needs of a select group of users functioning in a select area of the organization, who typically utilize only a limited part of the overall business process. Activities that project managers often seek in RUP therefore exist outside of RUP; however, it is not uncommon for organizations to perform some of these activities within the Inception phase of a RUP project, usually as part of the Business Analysis discipline. This type of architecture planning may be considered an enterprise architecture "anti-pattern," and is also in a conflict with PMBOK, which expects to receive such analysis as an input into decision-making processes performed during Initiation (see Figure 2).

enterprise disciplines

Figure 2: RUP, PMBOK, and the Enterprise disciplines

Today, many organizations still do not have an enterprise architecture team that could accurately trace strategic decisions through the implementation projects into the features and components of implemented solutions. The Enterprise Architecture (EA) domain, supported by frameworks like The Open Group Architecture Framework (TOGAF) and Catalyst, is only slowly being adopted in the software industry. In part because of their relatively low adoption rates, but also because of the industry controversy around their purpose, EA frameworks do not sufficiently describe transitions from the enterprise architecture into the solution design. Portfolio Management and Change Management processes and tools, which are an administrative response to various management challenges, do not fully support decision-making based on architectural considerations.

Rational Method Composer, as a way to expand RUP in the direction of a complete, enterprise-wide lifecycle process, attempts to address some of these limitations by provisioning rich procedural and informational guidance that can be selectively leveraged to create a tailored process that would support methodology phase transitions. Within Rational Method Composer there is guidance for assimilating business goals and the results of business architecture analysis (TOGAF, Enterprise Unified Process (EUP), and others), with stakeholder requests and usage requirements (RUP, feature-driven development (FDD), Scrum), resource management (PMBOK), and existing system architectures (Zachman). Reference processes are available for most popular enterprise governance models (e.g., Department of Defense Architecture Framework (DoDAF) or Capability Maturity Model Integration (CMMI®)), solution architecture and implementation patterns (e.g., service-oriented architecture (SOA), Model-Driven Systems Development (MDSD), and COTS), and can be fitted to an engagement of any size (by adapting RUP for Small/Medium/Large projects, respectively). Increasing numbers of custom plug-ins implementing industry-leading processes (recently for TOGAF) are also becoming available.

Misconception: RUP does not produce an estimate

Many project managers complain that RUP does not create an estimate. This appears to be correct. RUP is a process framework that neither guides nor promotes any specific estimation techniques; however, it does contain some useful pointers about where and how to estimate.

Early versions of RUP were extremely short of estimation guidance. This has changed with an emergence of Rational Method Composer and the maturation of several estimating models [3]. In Rational Method Composer estimation is represented with both process content, which can be included into a custom process as needed, and as part of the references processes that target different project permutations (e.g., RUP for Maintenance and RUP for Asset-based Development). An executable engine is also available in the form of several custom Rational Method Composer plug-ins, such as the Quantitative Software Management (QSM) Measurement and Estimation plug-in. This latter plug-in is intended to be invoked at key milestones in the process, as well as on-demand, to produce estimates. The plug-in allows high degree of parameterization using environment, process, and project metrics.

Currently, the core RUP contain a library containing guidance for function point estimation with use cases and wideband DELPHI technique. The QSM estimation plug-in implements a refined Putnam Lifecycle Model and accepts function counts (FC) or software lines of code (SLOC) inputs. Unfortunately, Rational Method Composer content does not convey expertise-based and learning-oriented methods, and largely ignores all other techniques, which, however, may still be used.

An important point is that Rational Method Composer treats estimation the same way as it treats other techniques and best practices, such as use case analysis or unit testing. It forces process engineers and project managers to think about estimation as an optional (however important) technique that can be executed where it makes most sense, either as a predefined part of the delivery process, on an ad hoc basis.

Misconception: RUP leaves no audit trail

Similar to the Project Management discipline, which is governed by its own standards and best practices such as PMBOK and Projects in Controlled Environments (PRINCE2), so is the Audit practice. In the core RUP it is a part of the Configuration and Change Management discipline. Like Project Management, Change Management activities get an early start in the process. They include Configuration Management, Change Request Management, and Status and Measurement Management, all of which may directly feed Audit activities.

Part of the reason for concern is that Configuration and Change Management tasks are often neglected during the project in favor of activities that belong to the Requirements, Analysis and Design, and Implementation disciplines, as those are believed to be more critical to solution delivery. For this short-sighted thinking projects and organizations eventually pay a hefty price. It is therefore up to the project manager to make sure that activities from all disciplines are timely and effectively run. RUP has no shortage of guidance regarding what needs to be done and when.

Misconception: RUP lifecycle is based on phases

Forget iterations -- most projects I've seen used RUP as a sticker, very rarely going beyond defining the phases and using use cases to describe front- and back-end interactions.

To have multiple project iterations, each delivering a production release, is a very difficult decision for the PM to make, and planning them is, arguably one of the most challenging parts of a PM's job. It takes flexibility and trust, as well as subject domain and methodology experience, to induce proper iterations. Phases, however, seem easier to comprehend as they provide clear buckets into which PMs can throw their tasks. In RUP, each phase ends in a well-defined major milestone -- something that is a cornerstone of its reference architecture and remains the same for all RUP projects, regardless of their size, type, or complexity. Iterations, which end in minor milestones, however, may differ from project to project.

Milestones allow project managers to "synchronize watches" with their technical teams and deliver important updates to their bosses. Importantly, they coincide with the delivery of the most critical artifacts and, therefore, can and must be used to construct project plans and make "go/no-go" project decisions.

Major RUP milestones, most of which, most of the time exist within a single iteration, are:

  • Lifecycle objectives
  • Lifecycle architecture
  • Initial operational capability
  • Product release

Minor (but not extremely minor) milestones coincide with the delivery of major product releases.

The concept of an iteration is, undoubtedly, more important to RUP as a process framework than the concept of a phase. The latter often makes people, including PMs, think that requirement gathering occurs in Elaboration, development in Construction, and deployment in Transition, which is more reminiscent of the waterfall method than RUP. It is unfortunate that RUP phases feel like they were extrapolated from a building development lifecycle model of the construction industry. The prevalent process model in that industry is sequential in nature, whereas the prevailing engineering model is cyclical [6].

Misconception: RUP must be mapped to PMBOK

Conducting a mapping exercise between RUP and PMBOK is not a must; however, some form of mapping will be required if standards are to be used jointly during the project. At a high level this mapping is fairly straightforward, but in practice every project ends up with a slightly different model. The first question that should be asked is which of the two standards should be used as a baseline. I strongly recommend RUP; even as PMBOK will normally act as an anchoring project standard. The reason is that RUP represents the more discrete and more specialized domain of software engineering, while PMBOK is a largely industry-agnostic project management approach. After the custom method is authored and tailored, a RUP-based and PMBOK-conscious delivery process can be tendered as hands-on project approach guidance, which it is not likely to become otherwise.

If mapping work is to happen, it should only proceed to the degree of detail that meets the aspirations of the PM. Some project managers will be inclined to go as far as mapping individual tasks and artifacts. I suggest that agreement on the mapping principles for lifecycle elements is sufficient. It would be a better investment of time to stick with the RUP's project planning recommendations. summarizes mapping between lifecycle elements from the RUP and PMBOK standards.

Table 1: Matching RUP and PMBOK elements

Major MilestoneMilestone
Minor MilestoneMilestone
DisciplineKnowledge Area
ActivityProcess Group
Work Product (Artifact, Deliverable)Deliverable

Artifact collision and added redundancy are just some of the potential challenges that either the process engineering team or the project team will face when they follow the hybrid approach. A good example is the PMBOK Project Charter deliverable, which, as some PMs point out, "gets superseded" in RUP by Business Case and Vision artifacts. While a hybrid approach may advocate using a mix of artifacts from both standards, I strongly suggest for the sake of supporting traceability that all RUP artifacts be maintained, whereas PMBOK artifacts can be added and derived from them on a case-by-case basis.

What also causes grief among the PMs is that fact that RUP allows some of its artifacts, such as the Software Architecture Document, to evolve throughout project phases and iterations, and to remain in a partially completed state for a longer time than is consistent with PMBOK. It is important to emphasize that RUP restricts its artifacts from evolving indefinitely and employs stringent principles and criteria to allow its artifacts to pass through milestone gates. More recent PMBOK specifications consider the incremental approach as well, by applying the principle of "progressive elaboration."

Misconception: RUP is an "out-of-the box" process

Like many other IT project participants, project managers often think of RUP as a single, out-of-the box process. Perhaps this perception originated in the early days of its evolution, when RUP was a monolithic process that addressed a narrow range of projects (mainly "green field" software development projects) and lacked sufficient flexibility regarding project size (it tended to treat all project as being large). At that point RUP also lacked adequate descriptive guidance and customization capabilities. Despite all these deficiencies having been addressed long ago, the perception of RUP as a ceremonial and stiff process still exists.

The situation has changed even more significantly with the introduction of Rational Method Composer. The later RUP releases embrace several categories of engagement by size (and, arguably, by the amount of ceremony involved), including "RUP for Small Projects," "RUP for Medium Projects," and "RUP for Large Projects." Specialized "plug-ins," such as "RUP for COTS" and "RUP for Business Modeling" can be tailored along with the base RUP in order to create a specialized, appropriately sized delivery processes. Other than the out-of-the-box specializations, a custom process may be adjusted from the pool of guidance developed by the organization internally, as well as content from other methodologies, frameworks, and best practices, such as PMBOK or the Information Technology Infrastructure Library (ITIL®), and also via RMC plug-ins.

Misconception: RUP lacks "initiation"

PMs often expect RUP to help with their administration tasks, such as acquiring funding approval or securing "buy-ins" from the senior management. Along these lines, many PMs would like to see RUP Inception phase preceded by an additional period where such issues could be taken care of. This approach to manipulating the RUP lifecycle, however, would go against few of its principles.

If designed to extend the RUP Initiation phase, these activities will constrain project resources, which is against RUP`s concurrency and process efficiency rules. When the key project decisions are made without considering requirements-based evidence, they would either prove entirely superficial or deliver faulty or incomplete solutions. Accurate project planning can only be performed upon structured requirements, which are, generally, elicited through Elaboration.

If an aim is to secure more time for business analysis or political maneuvering, it has little to do with RUP. Perhaps, some resolution can be found in the domain of EA. EA mandate is broader then RUP's and guidance is available in Rational Method Composer for transforming vision goals and business measures contained in the Enterprise Vision, Business Case and other planning documents into business technology specifications and solution proposals. EA methodologies contain guidance for enterprise process and structure analysis, goal and scope identification, resource estimation, architectural analysis, solution identification and prioritization, and implementation method selection. More potential aid resides in the area of Project Portfolio Management. With continuous portfolio management processes underway, it is natural that project selection and general vetting would be a recurring function, thus removing any prejudice towards the solution implementation methodology.

Some of these measures may require a new perspective on project management in the organization, perhaps in the format of the Enterprise Project Manager role. I discuss this possibility next.

Enterprise PM: a story in the making?

Is it even worthwhile for an organization to institute an Enterprise PM role? It may be, if the enterprise's evolution is envisioned as a single, long-running process -- something that TOGAF and some other EA implementation frameworks capitalize on.

Naturally, mapping the EA implementation onto one or more projects would entail either embracing the entire EA lifecycle, or a part of the lifecycle, within a given project. While the former approach is tempting, it is not advisable as it may result in a very long project. Although it may alleviate a bureaucratic burden on the implementation activities by reducing work related to project initiation and closure, the fact that it may take years to run a project, makes it less practical (and goes against RUP recommendation that calls for restrained projects).

It is more advisable, therefore, to institute several projects along the EA implementation path, whose life spans are more reasonable. These projects may, for instance, overlap one or a few of the EA implementation phases. They can run either simultaneously or overlap. Taking TOGAF ADM as an example, three different enterprise projects can be setup to articulate vision (Phase A), develop architectures (Phases B to F), and provide solution implementation governance and change management (Phases G to H).

It is up to the organization to decide whether it requires a dedicated enterprise PM to handle its enterprise affairs, or it becomes an added responsibility of the enterprise architect [1]. It is, then, up to the enterprise PM (or an architect) to come up with an optimal set of solution projects to implement the EA. This decision must take into consideration factors such as organization's incentive to change, its ability to deliver, its historical productivity while executing similar projects, and historical or anticipated duration of the EA implementation cycle. The history of the issue suggests that the enterprise architect will have other things to worry about (like architecture issues), which may create a gap in responsibilities that is not easy to bridge.


  1. A program is a project that regulates multiple projects.

Notes and References

The author would like to thank Jas Madhur, Mark Arshawsky, and Francis Pring-Mill for their thoughtful remarks. The opinions expressed here are those of the author and do not necessarily match those of Sierra Systems Inc.

[1] Read more about the correspondence between enterprise architectures and solution implementation in my Rational Edge article about TOGAF and RUP used together:

[2] This terrific paper by Philippe Kruchten talks about challenges of transitioning from waterfall to iterative development for PMs:

[3] Some useful patterns about enterprise estimation can be learnt here:

[4] This article of mine from The Rational Edge explains more about structured requirements:

[5] For related information see my Rational Edge article for using Zachman, RUP, and UML together:

[6] Here is another interesting piece on predicting iterative projects:

[7] A template to be used during formal mapping between PMBOK and RUP can be found here:

[8] For ideas and analysis around mapping PMBOK into RUP visit:

[9] Also consult the Rational Method Composer content database for guidance and useful advice.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=A Project Manager's RUP in review