Introduction
The success rate of information technology (IT) projects is well documented in literature; the most notable is “Extreme CHAOS” by The Standish Group. In addition, individual organizations provide a wealth of antidotal evidence that support The Standish Group's findings within their IT group. However, the problems that contribute to a high failure rate for IT projects are varied as the number projects and individual organizations. As a result, there is no clear solution or simple fix for improving of project success.
Organizations have placed a high priority on improving IT project performance. IT groups were once viewed as a supporting function within an organization. Project delays generally only affected internal operations. Today, IT groups undertake projects that are more closely tied to business objectives of the organization. IT project failures can have broad ramifications for an organization, including customer dissatisfaction, loss of market share and lower stock prices.
IT groups are attacking project performance by investing in its people and examining their processes. Budgets have increased for project management, application development skills, and technical training. Organizations are examining how they develop applications and manage projects. These organizations can either implement internally created software development and project management methodologies or purchase software development methodologies from third-party vendors such as Rational Software Corporation, IBM, CSC, and a host of other firms.
These third-party methodologies must be integrated with the organization's existing policies, procedures, and practices. Certain organizations that advocate modern project management have expressed difficulty in aligning Rational's Unified Process® or RUP® with the Project Management Institute (PMI®) standards. Many believe that RUP's® iterative approach and the assumption of changing requirements is incompatible with modern project management concepts. This belief is not supported as project management concepts are embedded in the RUP® and project management techniques can be used in a RUP® environment.
This paper first provides a brief overview of the RUP® process. This discussion will provide context for subsequent sections of the paper and is not meant to be a definitive white paper on the subject. Next, the paper will identify similarities and differences in the project management and RUP® project life cycles. The final section will outline considerations for project management in a RUP® environment.
Rational Unified Process®
RUP® is one of several object-orient software development processes currently on the market. RUP® is marketed by Rational Software Corporation and is embedded in the company's various product lines, which consist of online software development tools and templates.
As with any process, RUP® is a road map or how to guide for developing software. The process is based on certain key assumptions or elements, including:
• Product requirements evolve throughout the project, which makes it difficult to baseline requirements early in the project
• High-priority risks should be identified and addressed as early as possible in the development process
• Quality assurance and testing conducted throughout the development process produces higher-quality products with lower costs
• Iterative prototype development is the preferred technique for mitigating risks, defining and refining requirements, and quality control
• Software development should be viewed from a technical and management perspective.
RUP® consists of a gated four-phase development life cycle that includes Inception, Elaboration, Construction and Transition. The purpose of each phase is well defined and addresses specific software development risks. During the Inception phase, the emphasis is placed on scope definition and business case formulation. While all major project risks should be identified and analyzed, priority is given to those risks that affect requirements.
The focus of the Elaboration phase is creating a software development plan as well as identifying a stable software architecture. The software development plan includes an expansion of the requirements identified in the Inception phase, determining the project complexity, which is a major consideration for the number of iterations, and project schedule and budget. In addition, the project team is evaluating alternative architectures and identifies the preferred architecture, as architecture is the major risk element that is addressed during this phase.
Exhibit 1. RUP® Phase Deliverables and Success Criteria
During the Construction phase, project activity is oriented in fleshing out the baseline architecture and incrementally developing the final software product. Product deliverables for this phase would include internal and customer documentation (e.g., user manual), test beds, test results, and rollout collateral materials (e.g., training programs and materials, marketing materials, etc.). The key project deliverable is the iteration plan. Since the work is broken into iterations, the project team must prepare a detailed iteration plan that identifies capabilities being developed, production risks being mitigated, and defects being fixed during the planned iteration. Iteration schedule, budget, and staffing requirements are also identified in the iteration plan.
The Transition phase is concerned with deploying the application in the user environment. For a commercial product, Transition phase activities could include sales and marketing, manufacturing, and packaging. User training, application rollout, and help-desk orientation are transition activities for internally produced products. Iterations, including general availability, bug fixes or enhancement releases, may continue into the Transition phase. During this phase, the application's owner formally accepts the product. Additional revisions or enhancements to the product would be considered product maintenance. The project team is concerned with rollout risk.
Management through a formal review process can approve continued funding of the project at various checkpoints or gates throughout the development life cycle. Generally, this review and approval process occurs at the end of each phase. RUP® defines this decision cycle as a milestone, which is a “point in time at which certain critical decisions must be made, and therefore key goals must have been achieved” (Kruchten, 1996). The iterative development process allows for additional review at the conclusion of each iteration, as the software must be successfully tested against objective measurable criteria before the next iteration can commence.
Exhibit 1 summarizes the project deliverables and key success criteria for passing each milestone. The phase deliverables consist of both technical and business work products. Technical deliverables include prototypes, architectural documents, test cases and results, and user documentation. Vision document, use cases (requirements document), business case, risk assessment, software development plan and deployment documentation are considered business deliverables.
While phase deliverable include technical and business elements, most of the success criteria are business oriented. In reviewing the criteria, the emphasis of the success criteria is on stakeholder acceptance of scope, requirements, and the software product. Regardless of the phase, budget and schedule (actual and planned) are major consideration for a “go/no-go” decision. The success criteria from a technical perspective are dependent upon the requirements. In other words, does the product perform as required by the customer?
Exhibit 2. Standard Project Life Cycle—Phases and Activities
Project Management Process and RUP® Comparison
After reviewing the RUP® project life cycle, it appears that RUP® and project management best practices are consistent. To understand these consistencies, it is important to review the RUP® project life cycle against a standard project management life cycle. ESI International's project management methodology—ProjectFO-CUS®—will be used for this discussion.
As shown in Exhibit 2, the life cycle is divided into four phases—Project Initiation, Solution Planning, Solution Implementation, and Project Closeout. The project planning phases of both processes (Initiation/Planning and Inception/Elaboration) are fairly consistent with each other with some minor exceptions. The life-cycle activities diverge during project implementation as the two processes have different emphasis.
The main activities during Project Initiation are associated with defining the project. As with RUP®, team members during this phase are defining the project's scope by identifying and understanding high-level requirements, setting project objectives and identify assumptions and constraints. A business case is also developed at this time to determine the financial impact to the organization as well as aligning the project to overall goals and objectives of the organization.
Similar to RUP®, high-level risk are identified and assessed. Risk mitigation strategies are not developed until subsequent phases. In RUP®, risk management in this phase places greater emphasis on requirements risk and suggests that a mitigation strategy be developed for each risk.
Both processes require a clearly documented scope statement for the project, a set of high-level requirements, business case, and risk assessments. A sufficient level of detail is required to demonstrate to management that the project has merit and justifies further expenditure of limited organizational resources to better define the project.
In Solution Planning, the purpose is to prepare a technical solution to satisfy customer requirements through internal planning, and with the customer coordination. This technical solution describes how project objectives will be accomplished and a technical approach outlining the work to be undertaken. The technical solution also identifies any special or new technologies that need to be developed in order to manage the project, perform project work, deliver the technical solution, or to be incorporated into the product.
It is not usual to identify and evaluate multiple approaches before settling on an approved technical approach. Prototyping, concept design or “project work” is common and many times necessary to evaluate the alternative approaches. For example in product development, the project team may test component parts to determine if off-the-shelf components can be used or if new components must be developed. Product requirements, project schedule and budgets, and risk can be greatly affected depending upon the outcome of such tests. Concepts and prototypes, in many instances, are required in competitive bid situations, especially in the real estate industry for the selection of architects and design teams. The use for prototypes and conceptual design in the planning phase should not be considered unique to RUP® and are acceptable practices in standard project management methodologies.
The deliverables for this phase is similar to the deliverables in the RUP® Elaboration phase—project plan (schedule, budget, and resources) and any ancillary plans (e.g., change management plans, communications plans, mobilization plans), baseline requirements, and risk plan. While both processes require approval of a “project plan,” the information and level of detail may be different. In RUP®, the project plan or course grain plan estimates the schedule and budget for the overall project based on the number of iterations (top down). Detailed information with respect to schedule and budget is contained in the iteration plan. However, only the first iteration plan is contained in the course grain plan. Conversely, in the traditional project management approach, the project plan provides budget and schedule for the entire project developed by rolling up the schedule and cost information from the work package level (bottom up). Many organizations that embrace modern project management have adopted a RUP®-style rolling wave planning approach for their multiyear projects where the traditional planning approach can be not effectively applied.
At this point in the life cycle, RUP® and the project management methodology diverge. RUP® activities focus on the completion of the software code and associated documentation. RUP® is a software development process, and as expected places greater emphasis on the “product.” This is not to imply that RUP® ignores the schedule and budget aspects of the project. The purpose of a project management process is to ensure successful completion of the project, which places a greater emphasis on managing project activities by tracking actual vs. planned schedule and budget.
In Solution Implementation, the emphasis is on managing project execution to ensure the timely completion of all planned work within budget and scope with the allotted resources. This phase is comparable to the Construction and Transition phases of the RUP® life cycle. The project manager's responsibility focus on tracking and controlling activities, including budgets, schedules, and scope. Project deliverables generally consist of contract and project reviews and status reporting.
During Project Closeout, the emphasis is on performing the activities to effectively closeout the project. The activities are administrative in nature and include documenting customer acceptance of work products, ensuring vendor work is complete and invoices paid, project documents completed and store in a central location, and capturing and publishing lessons learned for the organization.
Considerations for Project Management within a RUP® Environment
Organizations adopting RUP® or other object-oriented software development processes need to understand that such processes are consistent and complementary to modern project management. In fact, organizations can improve the software development process by incorporating modern project management techniques into the development process. If project management process and RUP® is compatible, why do organizations have problems reconciling the two concepts? The answer can be found in debunking three myths or misconceptions.
Myth #1: Project management techniques are not effective because requirements are evolving throughout the development life cycle.
During the Inception and Elaboration phases, requirements do evolve, as more information about the project becomes available. Software projects, or any project, are undertaken to address needs or to take advantage of certain opportunities in the marketplace. The project team, users, customers, management, and other stakeholders articulate these needs and define high-level requirements for the new application during the Inception phase. The organization at this time also evaluates the financial and business implications for undertaking this new initiative.
As the name implies, the requirements and business case are revised and better defined during the Elaboration phase. The project team has time to conduct due diligence on the technical systems and to develop prototypes to determine the effectiveness of alternative platforms or technologies and to define requirements in more detail. During this phase, it is intended that requirements become more detailed rather expanding or a change in direction, unless caused by architectural constrains or significant changes in the business case. Upon achieving the Elaboration phase milestone, baseline requirements are established. Additional requirements or changes to existing requirements may be justified.
The steps just outlined are no different than the requirement formulation process presented in many project management methodologies and is consistent with A Guide to the Project Management Body of Knowledge (PMBOK® Guide). It is important to recognize that customers can use the iterative process to accommodate unlimited and/or unjustified changes. To resist the plethora of changes, project managers and the organization must establish and enforce change management procedures, as any change will impact schedule and budget.
Myth #2: The iterative development approach does not allow for effective project planning.
RUP® employs a rolling wave approach to project planning. The Software Development Plan (SDP), an Elaboration phase deliverable, consists of several elements including a “course grain” plan and initial iteration plan. The course grain plan, which is also referred to as the project plan, identifies the number and approximate length of the iterations. In addition, the course grain plan outlines what features and functionality will be coded during each iteration. SDA also includes a staffing plan and a high-level project schedule based on the number of planned iterations.
While the project plan provides a general outline for accomplishing the project, the iteration plan(s) provides the appropriate level of detail that is normally provided at the work package level. The iteration plan identifies goals for the iteration, including the capabilities being developed, risks being mitigated, defects being fixed and objective and measurable evaluation criteria for the software being developed in the iteration in addition to schedule and resource assignments (Kruchten, 1996). Each iteration plan is prepared upon the satisfactory completion of the previous iteration.
Iterative development provides for more effective planning. It does not necessarily mean that less project planning is required. RUP® and its iterative approach, which result in more reliable schedules due to a shorter planning horizon of each iteration plan (approximately eight weeks). In addition, developers and other team members gain valuable experience and insight from early iterations can provide better scheduling data and results in better efficiencies in coding and testing during subsequent iterations.
Myth #3: For RUP® projects to be successful, the project manager should have strong technical skills.
As Kruchten notes (1996), RUP® is centered on people, process, and tools and methods. Organizations spend considerable time and money on rolling out the process, understanding the tools, training their staffs on the process and in project management. These organizations overlook the key element to successful RUP® projects—effective project managers. This is a problem that is not limited to organizations using an object-oriented process or IT groups in general. Most organizations place a high value on technical competency and project management knowledge in promoting and selecting project managers. Most organizations have job descriptions and defined roles and responsibilities for project managers, but few organizations understand “what characteristics and attributes makes for a good project manager”?
Competency models are used by organizations to identify traits related to outstanding performance within professional, technical and managerial professions. ESI International's project management model (ESI, 1999) is based on a Department of Defense study of program managers and was validated in a corporate environment. In addition, this model can be applied across industry groups and project 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 important 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 result, project managers must be able to gather and synthesize information quickly, make sound decisions with input from team members, 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 persuasive 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 workflow. Problems develop when more than one process have contradictory results and/or become an administrative burden.
RUP® and modern project management methodology are complementary. RUP® guides the development of software applications. As a result, RUP® focuses on the software product and associated deliverables. Project management methodology provides a framework for managing projects within an organization. The purpose of a project management process is to ensure successful completion of the project, which places a greater emphasis on managing 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. Additional project management techniques could be incorporated to strengthen RUP's Construction and Transition stages.
