© Copyright IBM Corporation 2004 ......developerWorks > Rational > Issue contents Editor's notes —May 2004 For more than two decades, the Rational organization, now part of IBM,

© Copyright IBM Corporation 2004 http://www-106.ibm.com/developerworks/rational/rationaledge/

Search for: within

Search help

IBM home | Products & services | Support & downloads | My account

developerWorks > Rational >

About IBM | Privacy | Terms of use | Contact

http://swgiwas001.sby.ibm.com/developerworks/rational/rationaledge/index_0504_new.htm5/14/2004 1:29:19 PM

Search for: within

Search help

IBM home | Products &services | Support &downloads | My account


Issue contents

Editor's notes —May 2004

For more than two decades, the Rational organization, now part of IBM, has worked to improve the various processes associated with software development. While most of the products under the Rational brand support aspects of the development lifecycle —testing, requirements, modeling, etc. —it's the Rational Unified Process that provides the full context for our specific product capabilities. This month, we have devoted an entire issue of The Rational Edgeto this process, covering some of the major concepts behind project management and software development process improvement. For those of you who have asked about the relationship between the Rational Unified Process and the PMBOK (the Process Management Institute's "Project Management Body of Knowledge"), you'll find two interesting approaches to that topic.

And there's much more in the table of contents below!

Happy iterations, Mike PerrowEditor-in-Chief

Features

● Planning and estimating a RUP project using IBM Rational SUMMIT Ascendantby Per KrollThis article describes how to plan and estimate a RUP project using the IBM Rational SUMMIT Ascendant, an integrated suite of software engineering practices, project planning and estimating tools, and techniques guidance, delivered through a Web interface.

● Effective management through measurementby Doug IshigakiUsing sample views generated by automated tools in the IBM Software Development Platform, Ishigaki shows how an automated measurement program can help software project managers assess progress, mitigate risks, and improve team productivity.

● Project Portfolio Management (PPM): Aligning business and IT by Ashok ReddyThis article introduces Project Portfolio Management, or PPM, a strategy that involves managing a project portfolio much as you would manage a portfolio of diverse financial investments. By using PPM, organizations can align their IT projects and resources with corporate business objectives.

● Program management: Different from project managementby Michael F. HanfordMike Hanford asks some basic questions about program management and discusses practices associated with this discipline. He explains relationships between project management and program management roles and techniques, noting significant differences.

● New whitepaper on software configuration management!Register to download "Improve developer productivity with integrated SCM for WebSphere Studio and Eclipse" and learn about how IBM Rational174ClearCase174Change Management products provide advanced SCM capabilities from within IBM WebSphere174Studio and Eclipse development environments.

● New Webcast focuses on "Improving Productivity and Cutting Costs through Effective Change Management"Hear insights from META Group on current business issues and trends, and how effective change management can improve productivity and software quality while reducing costs. Includes a real-world example of how an IBM Rational SCM solution increased team productivity. Free access to this Webcast when you register.

● Read about IBM's new J2EE Code Validator in the latest issue of Think!Developed at the IBM T. J. Watson lab, this new product for Java developers combines for the first time "…deep, heuristic static analysis with best practice rule sets for Java…." The article explains how the J2EE Code Validator was developed, how it works, and how it might evolve in the future.

Teams and projects

● Software Project Management —A Mapping between RUP and the PMBOKby Serge CharbonneauThis paper compares the Rational Unified Process (RUP) with the PMI’s “Project Management Body of Knowledge” (PMBOK) and provides a mapping between best practices in the RUP project management discipline and best practices in the PMBOK.

● Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOKby Bill CottrellThis article explains the relationship between IBM Rational Unified Process, or RUP, and the PMBOK, the “Project Management Body of Knowledge,” maintained by the Project Management Institute, or PMI. It is the first in a series of articles describing the relationship of RUP to industry standards, what compliance means, how to leverage standards to improve your tailored use of RUP, and how you integrate those standards with RUP to achieve business value.

Theory and practice

● Matching project and processGary PolliceIn this month's column, Gary Pollice discusses the often overlooked necessity of tailoring a software development process to match the people, tools, and project type.

Rational reader

● JavaServer Pages, second editionby Larne PekowskyReviewed by David WarnerWarner reviews a book that covers topics such as basic Java coding, the JSP standard tag library, and database access, and supplements them with material for advanced practitioners on XML, advanced bean topics, servlets, creating tag libraries, and controllers such as Struts.

● The Seven-Day Weekend: Changing the Way Work Worksby Ricardo SemlerReviewed by Manjeri R. DharmarajanManjeri Dharmarajan reviews a book describing a management philosophy for finding a work/life balance and creating a sustainable organization.

issue contents

archives

subscribe

submit an article

contact us

Entire issue in .pdf

Downloadthe entire issue in .pdf (2.7 MB)

© Copyright IBM Corporation 2004 http://www-106.ibm.com/developerworks/rational/rationaledge/

http://swgiwas001.sby.ibm.com/developerworks/rational/rationaledge/admin/0504current.html (1 of 2)5/14/2004 1:36:55 PM

The Rational Edge: Issue contents


http://swgiwas001.sby.ibm.com/developerworks/rational/rationaledge/admin/0504current.html (2 of 2)5/14/2004 1:36:55 PM

Search for: within

Search help

IBM home | Products &services | Support &downloads | My account


FeaturesEach month, this section will help project and business managers understand more about technologies from IBM Rational and IBM Business Partners -- how they're used, and how projects and companies can benefit.

Planning and estimating a RUP project using IBM Rational SUMMIT Ascendantby Per Kroll

Program management: Different from project managementby Michael F. Hanford

Effective management through measurementby Doug Ishigaki

Project Portfolio Management (PPM): Aligning business and ITby Ashok Reddy

New whitepaper on software configuration management!

New Webcast focuses on "Improving Productivity and Cutting Costs through Effective Change Management"

Read about IBM's new J2EE Code Validator in the latest issue of Think!

issue contents

archives

subscribe

submit an article

contact us


Copyright IBM Corporation 2004 http://www-106.ibm.com/developerworks/rational/rationaledge/

http://swgiwas001.sby.ibm.com/developerworks/rational/rationaledge/content/0504features.html5/14/2004 1:32:39 PM

© Copyright IBM Corporation 2004. http://www-106.ibm.com/developerworks/rational/library/4772.html

Search for: within

Use + - ( ) " " Search help


developerWorks > Rational

Planning and estimating a RUP project using IBM Rational SUMMIT Ascendant

Contents:An overview of software estimation

The Inception phase

The Elaboration phase and beyond

Notes

About the author

Rate this article

Subscriptions:dW newsletters

dW Subscription(CDs and downloads)

Per Kroll ([email protected])Director, Rational Unified Process, IBM11 May 2004

from The Rational Edge: This article describes how to plan and estimate a RUP project using IBM Rational SUMMIT Ascendant, an integrated suite of software engineering practices, project planning and estimating tools, and techniques guidance, delivered through a Web interface.

[Author's note: This article was a collaborative effort with my colleagues Carlos Goti, Michael Hanford, Bruce MacIsaac, Gordon Schneemann, and Bruce Wallman.]

IBM® Rational® SUMMIT® Ascendant® is an integrated suite of software engineering practices, project planning and estimating tools, and techniques guidance, delivered through a Web interface. Used with the software project management best practices in IBM Rational Unified Process®, or RUP®, it can help a project manager estimate high-level cost and schedule early in the project, create detailed plans for each iteration, and manage cost and schedule as the project proceeds.

This article describes how to plan and estimate a RUP project using the IBM Rational SUMMIT Ascendant toolset. We will see how planning and estimation is an iterative process, requiring and enabling continuous improvements of your plans and estimates throughout the project as you gain more knowledge about 1) what work needs to be done, and 2) the effectiveness of your team.

We can divide planning and estimating a RUP project1 into the following three main activities:

● Perform initial project sizing. Understanding a project's size is part of the start-up. This allows you to understand the project in terms of work effort and provides a basis for high-level resource planning by skill type. You can augment the sizing activity using a variety of estimation techniques, many of which the IBM Rational SUMMIT Ascendant toolset supports. You can periodically revisit the initial project sizing to refine it as you learn more about project characteristics.

● Produce a phase plan. In the first iteration, you produce a high-level phase plan that provides initial cost and schedule "scale" information for a project go/no-go decision or possible re-scoping. Later, you can use this high-level plan to check and refine the overall scale of the project using the actual results of each iteration as input.


● Produce iteration plans. For each iteration, you produce an iteration plan and use it to guide work and track progress. The iteration plan specifies what deliverables you should be produce, who creates them, and how to assess the results, primarily through executable testing .

See Figure 1 for a sample RUP project that demonstrates where these activities occur.

Figure 1: When to plan and estimate a RUP project

An overview of software estimationBefore we go through how to plan and estimate a RUP project, let's walk through estimation in general, and estimation in IBM Rational SUMMIT Ascendant specifically.

Commonly used estimation techniquesThere are several techniques for estimating and sizing a project. The more commonly used techniques include:

● Algorithmic models. These models produce an estimate as a function of several variables, which are considered to be the major drivers of work effort. Algorithmic models include:

❍ COCOMO II, a method initially coordinated by Barry Boehm and maintained by the Center for Software Engineering at the University of Southern California (http://sunset.usc.edu/research/COCOMOII/).

❍ Function points, a language-and implementation-independent approach that counts specified user functions. ❍ Use-case points, an extension of function point analysis for projects using use-case-based requirements

approaches.❍ QIF-based estimates, a method developed for use within IBM Rational SUMMIT Ascendant, based on

"Quantitative Influencing Factors" derived through IBM's extensive software estimation experiences working with Fortune 500 companies.

● Expert judgment. Experts may be asked to estimate the amount of effort required for the project. Wide-band Delphi is a popular method for collaborative expert judgment estimation.

● The Analogy-based estimation technique. The estimator compares a new project to one or more past projects of a similar nature.

● Parkinson/Effort to win. This technique is used during the Inception phase only. The definition of project scope, and project inclusions, is "backed into," based on available funding or resources.

You should try to use at least two of these techniques. One technique serves to validate the other. If, however, you discover major differences in two sets of results for project size, you should question whether the goals, scale, and desired results are properly understood.


There are also two models for distributing estimates across a Work Breakdown Structure (WBS):

● With the top-down approach, you specify an estimate for the entire project, and then distribute the estimate across the various WBS members. You can combine this approach with, for example, function point analysis and COCOMO II, to provide the top-line estimate.

● With the bottom-up approach, you make an estimate for all low-level WBS elements, and then sum up those estimates to produce an overall estimate for the project. You can combine this approach with SUMMIT's QIF-based estimates, as well as with expert judgment, to provide estimates for the low-level WBS elements.

QIF-based estimationQIF-based estimation has been developed specifically for IBM Rational SUMMIT Ascendant and has been used by a number of Fortune 500 companies over the last decade. The estimation is an algorithmic model requiring numerical values for various project characteristics, such as number of use cases, number of reviewers, and so on. These numerical QIFs drive the effort estimates for each task in the WBS.

QIF-based estimation is combined with bottom-up estimation, and each WBS member is calculated as follows:

Estimate = Multiplier * (QIF Count) * Formula( Low Range, High Range) + Adjustment

Consider the following example, which is based on the activity of detailing a use case.

Example

Project Activity: Detail a Use Case

The QIF is: Number of Use Cases

A Labor Effort Range is associated with the QIF:

● Low Range = 2 hours● High Range = 8 Hours

The number of use cases is estimated at 8 (the QIF Count). Note that there are two ways of setting a QIF count: 1) Allow the estimation template to set the QIF count for you, since when you choose an estimation template, values are set for all QIFs. If you choose an estimation template for a simple project, the template will, among other things, set the QIF count for use cases to 8, as in this example. 2) Alternatively, you can examine the various QIF counts provided by the template selected, and manually specify reasonable QIF counts based on your understanding of the project. For instance, the estimation template may have set the QIF count to 12, but you know that a more reasonable estimate for number of use cases for this project is 8.

The Estimator provides a variety of formulas. Using the average calculation formula, we will set the labor effort at 5 work hours associated with each use case (that is, the low range 2 hours added to the high range 8 hours for a total of 10 hours divided by 2 (the average), or 5 work hours.

So, the Estimate work effort associated with 8 use cases is — given the average work effort of 5 hours — approximately 40 work hours.

The Estimator allows you to use a Multiplier and an Adjustment.

You can use the Multiplier to provide some overall percentage change to all, or a selected set of, activities within a project. If the project team consists of all relatively junior staff, the team may work more slowly than an experienced team. The project manager may decide to allow an extra 10 percent of work effort to allow for this experience difference. You can do this by setting the Multiplier to 1.10.

You can use the Adjustment to change the work effort of each activity by some specific number of work hours. The project manager knows that there must be time for some on-the-job learning for the team's junior members, so the project manager allows an extra 2 work hours for each activity to allow for this learning experience. You can do this by setting the Adjustment to 2.

So, the Estimate work effort that was previously estimated to 40 work hours will now be estimated to 1.10 x 40 hours + 2 hours, or roughly 46 hours.

Figure 2 is a screen shot from IBM Rational SUMMIT Ascendant. The text boxes with blue arrows indicate where on the screen to find the key concepts discussed above.


Figure 2: Loaded values with formula applied

Estimation support in IBM Rational SUMMIT AscendantIBM Rational SUMMIT Ascendant supports top-down as well as bottom-up estimation. SUMMIT directly supports many of the specific estimation techniques discussed earlier, including function points, QIF-based estimation, analogy, and the Parkinson/Effort to win estimation models.

If you do COCOMO II, use-case point estimation, or expert judgment, SUMMIT allows you to enter the results of your effort into SUMMIT, and you can then leverage SUMMIT's top-down estimation support to break down a project estimate by individual component. Finally, if you use expert judgment to estimate lower-level WBS elements, you can leverage SUMMIT's bottom-up estimation support to understand the overall project effort.

IBM Rational SUMMIT Ascendant's support for such a broad set of estimation techniques makes it a very powerful tool. There are many ways you can leverage these capabilities for a project, each with its pros and cons. Below we will explore one recommended approach for using many of these estimation techniques when planning and estimating a RUP project.

The Inception phaseEstimation in the Inception phase involves three major steps: performing the initial project sizing; producing a phase plan; and producing iteration plans.

Performing initial project sizingFor the initial project sizing, we will leverage a combination of the analogy estimation model to rapidly produce a rough estimate correlated to similar project types, and the algorithmic QIF-based estimation to modify the estimate to better reflect the specifics of our project. Finally, we may also use expert judgment to override and improve upon the algorithmic estimates.

The technique consists of the following steps:

1. Choose a planning template. The template will provide the WBS that you will use for estimation. Adopting organizations can add their own templates, drawn from the actual plans used by past, successful projects. IBM provides out-of-the-box


templates for RUP configurations that conform to small, medium, and large process needs. Note that at this stage we only try to understand what type of activities we are likely to spend time on in our project; we are not trying to produce a detailed project plan for the entire project.

2. Select default QIF counts. IBM provides pre-defined sets of QIF counts for projects of small, medium, and large complexity. The project manager will select one of the default QIF sets as the starting point for a series of sizing scenarios and exercises. This allows the project manager to pre-load estimation data that best reflects past stereotypical projects. You can add QIF count templates to calibrate the method to the organization's experience.

3. Determine which estimation formula to use. SUMMIT allows you to choose from several pre-defined formulas for sizing an entire project or project segment. In the section titled QIF-based Estimation, we used the average formula, but you can choose from many other formulas in order to increase or decrease your estimate based on your project's specifics. Typically, you use the same calculation for the entire WBS, but you may choose to use different calculations for different elements of the WBS.

4. Review estimates and modify as required. You now have an initial effort estimate for all of your WBS elements. By reviewing them, you can assess whether they are realistic or not; you can run additional sizing scenarios using different project assumptions and characteristics; and you can choose the overall sizing formula, as needed. A project manager can override the sizing of one (or more) WBS members, using their own sizing. There is also a summary report that summarizes percent effort by phase, by workflow detail, and by role, and shows the relative impact of each QIF on the estimate. This allows the project manager to better understand and validate the estimates against prior project experience.

Note that both Steps 1 and 2 accommodate necessary adjustments based on your own project or experience. Step 1 above allows you to take advantage of out-of-the-box, experience-based IBM Rational SUMMIT Ascendant WBSs. In Step 2 you have available the out-of-the-box, experience-based SUMMIT calibrations of effort (based on QIFs and QIF counts) for each WBS item.

SUMMIT provides you with a variety of useful information, including overall effort, effort by phase, resource need by role and phase, and resource need by phase and discipline, as shown in Figure 3. In the next section, we will see how this information will help you build a phase plan.

Figure 3. Resource need by phase and discipline

The accuracy of results from application of estimation techniques varies, based upon the estimator's knowledge and experience with the specific project. It should be clear that estimates developed early in the Inception phase are not informed by actual work effort and consumption of resources that are known later in the phase. When you create (or refine) an estimate later in the project, you can apply such information from actual experience. You should also treat the estimation of effort as an iterative process.


In other words, it is important to revisit plans and estimates periodically during the project execution. It is also important to set the expectation with the project sponsor(s) that this periodic re-estimation will occur, and that increased knowledge of a project's scope will certainly affect the timing and sizing of the project as it progresses.

Producing a phase planA phase plan is normally driven by a project completion date; at a high level, the phase plan outlines the start and end dates of RUP phases and iterations, as well as the objectives of each iteration. Since most of the information involved in the phase plan concerns the objectives, and is therefore text-based, this information is best captured in a text document — either standard word processing or spreadsheet format — attached to the Software Development Plan; see Table 1.

Table 1: Generic phase plan

Phase Iteration Primary Objective (Risks/use cases addressed) Scheduled Start/End Effort Estimate (Person hours)

Percent effort of total Staffing

Inception I1● Define vision● Determine project scope● Define candidate architecture● Create business case● Create software development plan

week1/week4 1000 9 6.3

Elaboration E1● Install and test architecture ● Components● Validate requirements details● Implement priority use cases● Test proposed architecture

week5/week11 1400 13 5.8

E2● Mitigate architectural risks● Complete architecture installation and test● Implement additional use cases● Load test architectural elements

week12/week17 1400 13 5.8

Construction C1● Describe additional use cases● Design additional subsystems● Implement use cases and subsystems● Integrate product and validate state

week18/week21 1900 17 11.9

C2● Describe additional use cases● Implement use cases● Integrate product and validate state

week22/week25 1900 17 11.9

C3● Describe additional use cases● Implement use cases● Integrate product and validate state● Plan beta program● Plan user manual

week26/week29 1900 17 11.9

Transition T1● Deliver beta to customers● Analyze comments from beta● Apply corrections ● Finalize user manuals and other collateral● Create gold CD and product package● Deliver to customers

week30/week35 1400 13 5.8

Project Summary

week1/week35 10900 100

The basic input to the phase plan comes from the QIF-based estimation described previously. But you should manage the phase plan as a separate artifact, for several reasons:

● The phase plan may require the combined results of different estimation techniques, not just the QIF-based estimation.● Because the phase plan will be updated as necessary with data from the iteration plans (see next section), the overall effort

— and hence the start and end dates of phases — will likely be different from the overall effort you may have derived from the QIF-based estimate. As shown in Figure 3 earlier, there are no dates indicated, but rather labor estimates. If this data is sent to a scheduling tool such as PMOffice or Microsoft Project, then the detailed plan in the scheduling tool will require


start/end dates for each project activity, and you will have to adjust the phase plan to reflect these dates.● You typically do not want to include low-level WBS elements in your phase plan. ● In addition, the phase plan usually includes start and end dates for each iteration.

Typical steps in producing a phase plan are as follows:

1. Estimate the required staffing level for each phase. This estimate is provided through the QIF-based estimate.2. Determine a duration for the project by summing phase durations.

❍ Phase duration (weeks) = phase effort (hours, according to estimation)/number of full-time equivalent staff/staff hours per week. A more detailed analysis that considers project-specific characteristics, such as availability of staff with the right skill set, may produce a more accurate schedule. The summary report in IBM Rational SUMMIT Ascendant of work per role per phase can help with this.

3. Decide the number of iterations per phase. ❍ Iterations within a phase have start and end dates. The iterations do not overlap.❍ Iteration duration = phase duration/number of iterations in phase.

4. Outline objectives for each iteration.5. Update coarse project plan throughout the project.

❍ This step provides an overall roadmap against which you can track progress.❍ When used in conjunction with scheduling software, this allows you to realize when you have delays and need to

re-plan your project.

An important decision is how many iterations are needed in each phase. Table 2 shows project characteristics that tend to increase the number of iterations in a given phase.

Table 2: Project characteristics that can increase the number of iterations in a given phase

Inception● Working with new functionality (unprecedented system for the team)● Unknown business environment● Highly volatile scope● Make-buy decisions

Elaboration● Working with a new system environment (new architectural features)● Untested architectural elements● Need for system prototypes

Construction● Lots of code to write and verify● New technologies or development tools

Transition● Need for alphas and betas● Conversions of customer base● Incremental delivery to customers

Because an iteration is a milestone where the current product is integrated, tested, and validated, the duration of each iteration should be brief. If it is too long, you delay chances to adjust your plans as requirements change and the software under development is certified to work (which may not happen). Long iterations tend to reduce the effectiveness of your focus on risk mitigation. Depending on project size, the iteration duration should be between one and two months. Project size tends to increase iteration duration, but long iterations may cause the team to lose focus.

Iterations have a cost. They need to be planned and assessed, which involves team effort. Phase Plans should be a balance between effort consumed to control a project and effort to deliver results.

As we can see, IBM Rational SUMMIT Ascendant provided us with much of the critical information we need for phase planning. Teams leveraging SUMMIT to manage their iteration plans (see "Producing iteration plans" below) should consider using SUMMIT to manage the phase plan schedule information discussed above. Having all schedule-related information managed within SUMMIT facilitates, among others, status reporting and portfolio management.


Producing iteration plansAs a project manager for a RUP project, you typically, at any given time, actively work with two iteration plans: One for the current iteration, and one for the next iteration. The purpose of an iteration plan is to:

● Define the scope of the iteration, expressed in terms of concrete objectives, such as: ❍ Mitigation of specific risks❍ Detailing specific use cases❍ Implementing and testing scenarios and/or subsystem functionality

● Validate and/or adjust the iteration scope by: ❍ Estimating effort for each objective❍ Comparing bottom-up estimates for the objectives with overall coarse plan estimates

● Create a detailed plan of how the iteration will unfold● Set the order and composition of builds● Increase maturation of specific artifacts● Create, identify, and manage task dependencies● Assign tasks to individuals

Using IBM Rational SUMMIT Ascendant for iteration planningIBM Rational SUMMIT Ascendant can be very helpful for:

● Creating tasks● Assigning effort estimates to tasks● Assigning task dependencies● Assigning tasks to individuals

Since the underlying data format is identical to the data structure of a Microsoft Project database, you can open and edit the iteration plan can be opened and edited in Microsoft Project, as well as make changes in either Microsoft Project or in SUMMIT.

If you are using IBM Rational SUMMIT Ascendant to do iteration planning, you need to decide how tasks will be structured. One simple way to structure tasks so that you can compare them with the estimations done for the phase plan is to use the same WBS and add more detailed tasks.

For example: Suppose there are two Elaboration iterations, and you are planning the first one. A possible set of steps for creating the iteration plan using IBM Rational SUMMIT Ascendant are:

1. Copy the Elaboration phase section of the coarse estimation plan as a starting point.2. Divide the estimates by number of iterations in the phase (in this case, divide by 2).3. Add tasks for specific iteration goals:

❍ "Detail Use Case X" becomes a subtask under Refine the System (see Figure 5).❍ "Implement Scenario Z" becomes a subtask under Implement Components.❍ Subdivided workflow details become summary tasks.

4. Provide an override estimate for each new subtask (overrides are further described in "The Elaboration phase and beyond" section below).

❍ Total effort for the iteration must match available effort❍ Percentage of artifact completions should correlate with project effort allocations

5. Add dependencies between tasks as needed. ❍ Use builds to drive the tasks and limit the number of dependencies. Assign tasks to specific people. Use IBM

Rational SUMMIT Ascendant and Microsoft Project to manage the plan, as shown in Figure 4.


Figure 4: Example IBM Rational SUMMIT Ascendant iteration plan

Other iteration planning approachesSome project managers may prefer a different WBS structure for iteration planning: for example, a WBS organized around artifacts. Also, some project managers prefer to manage tasks more informally, such as managing tasks as a list; in this case, the team collaborates to manage dependencies and ensure that the iteration objectives are achieved.

Table 3 shows an example format for an informal iteration plan organized around artifacts.

Table 3: Example artifact-based iteration plan

Inception Iteration Plan - Example Format

Artifact State of Artifact Start/End Dates Effort (person days)

Role ResponsibleScheduled Actual Scheduled Actual

Vision Baselined Jim

Supplementary Specifications Baselined Jim

Business Case Baselined Jane

Risk List Baselined Jane

Software Development Plan Baselined Jane

Software Architecture Document Drafted Bob

Software Development Plan - Phase Plan Baselined Jane

Iteration Plan Completed Jane

Iteration Assessment Completed Jane

Use-Case Model Drafted Jim

Use Case "A" Identified Jim

Architectural Proof of Concept Prototyped Bob

Risk — Performance of legacy database Prototype measured Sally

Phase Reviews — Project Approval Completed Jane

TOTALS

The Elaboration phase and beyondWith the conclusion of the Inception phase, you have a solid base of actual work effort to measure against the projected work effort, and you can refine and enhance the project sizing and project schedule data from actual experience. You should go back and revisit QIF counts and estimation formulas used, as well as remove WBS elements that are no longer relevant. You should consider overriding some estimations of individual WBS elements, since at this stage you probably have a much more accurate estimate for how much time you will spend on various activity types than derived earlier from the QIF-based estimation. At this point, you also have a better understanding of what resources will be available so that you can perform appropriate changes to staffing profiles,


and corresponding iteration lengths based on resource leveling.

Using the revised data, we re-estimate the subsequent phases and iterations by going through each of the three activities described in the Inception section of this article, but now with improved data, as shown in Figure 5 below. In particular, we can measure productivity2 and use this as the basis for re-estimation. As better information becomes available, the project manager typically replaces QIF-based estimates with overrides that reflect the improved project understanding, and this replacement occurs more frequently over the course of the project. Note that this is made possible by QIF-based estimation being combined with a bottom-up estimation model, which is different from other common algorithmic models, such as COCOMO II, function points, or use-case points.

Figure 5: Example of an estimation override

For example:

● In Inception, we thought we would have 8 use cases for a system, and that we would spend roughly 5 hours (using average formula, see section QIF-based Estimation), for each use cases in the activity Detail a Use Case. In Elaboration, we realize that we will probably have 11 use cases, and that we spend 8 hours describing each use case. We will update the QIF count for use case to 11, use the formula "High," and then have SUMMIT re-estimate our project.

● As subsystems are identified, and use cases are described and allocated to subsystems, you can obtain effort estimates for implementing subsystem functionality. You can also use these estimates for bottom-up effort estimation.

As these tasks are performed, we can compare the estimated effort for the task against the actual effort, and improve the estimates for those tasks that are not yet complete. You may compare stimates based on specific artifacts and project metrics with the original QIF-derived estimates, but typically supercede those estimates.

ConclusionIBM Rational SUMMIT Ascendant supports a broad set of estimation models, and you can use many of these effectively when planning and estimating a RUP project.

The analogy estimation model allows us to quickly produce estimates that reflect experiences from past projects that have been captured in planning templates and default QIF-count templates.

The QIF-based estimation model allows us to specify a limited number of estimation parameters to capture the project characteristics that will have the most impact on the overall project effort. This helps us rapidly refine the analogy estimate to reflect the specific characteristics of our project.

The QIF-based estimation model provides us with valuable estimates of how many resources of what type was needed at what time in the project. This allows us to produce a more accurate phase plan.


IBM Rational SUMMIT Ascendant allows us to continuously improve our estimate as we gain a better understanding of what needs to be produced, the productivity of our team, and staff being available to us. We use this information to improve our QIF-based estimate, and we also leverage the override capability to replace QIF-based estimates with our expert judgment, as we understand what it will take to carry out low-level task.

QIF-based estimation is combined with a bottom-up estimation model, which makes it different from other algorithmic models, such as COCOMO II and function points. This is crucial to allow a continuous and incremental refinement of the algorithmic estimates using expert judgment of low-level tasks. The override mechanism in IBM Rational SUMMIT Ascendant enables capturing the expert judgment.

Finally, IBM Rational SUMMIT Ascendant allows us to manage all schedule and estimation information, including providing an audit trail for planning and estimation activities. This makes SUMMIT a powerful tool for planning and estimating a RUP project.

Notes1 A RUP project consists of four phases; Inception, Elaboration, Construction, and Transition. For more information about the Rational Unified Process, please see "What Is the Rational Unified Process?", or any of the other articles available from The Rational Edge archives under this category.

2 The Rational Unified Process provides guidelines for performing productivity metrics.

About the authorPer Kroll is the director of the Rational Unified Process development and product management teams at IBM Rational Software. He's been working with customers as a trainer, mentor, and consultant on the RUP and its predecessors since 1992 and was the original product manager for the RUP when the product team was launched in 1996. He's also been heavily involved in certifying partners and training Rational personnel to deliver services around the RUP.

What do you think of this document?

Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Comments?




Search for: within




Effective management through measurementContents:

Measurement as an effective management tool

Measurement and process

Key management measures and views

Summary

References

About the author

Rate this article



Doug IshigakiIBM12 May 2004

from The Rational Edge: Using sample views generated by automated tools in the IBM Software Development Platform, Ishigaki shows how an automated measurement program can help software project managers assess progress, mitigate risks, and improve team productivity.

Management without measurement is meaningless!

Managing software development is difficult for project managers with any amount of experience, and obtaining accurate measures of project progress is a constant challenge. Typically, when project managers rely on team members to provide status data, they get results that are inconsistent, imprecise, and hard to collate. In addition, throughout the project, executives, functional managers, and clients may ask for status reports containing selected data in various formats. Too often, teams find they are spending more time reporting on status than on developing the solution.

An efficient, automated software project measurement program can help project managers cope with these challenges. It enables them to assess progress in multiple project areas, identify problems early in the development lifecycle, and improve team productivity by eliminating tedious reporting tasks.

In this article, we will discuss the benefits of using such a measurement program and identify best practices and tools that can support it. Throughout the article, we will examine sample measurement views for both executives and project managers, generated by automated tools in the IBM Software Development Platform.

Measurement as an effective management toolMeasurement is an effective management tool because it provides the information decision makers require to accurately monitor key issues related to company and organizational goals, progress and quality at both the executive and project levels, and performance against a plan. Measurement also provides data that managers need to ask the right questions — and make the right decisions based on objective information.

The January 2003 Rational Edge article "Practical Measurement in the Rational Unified Process" detailed several benefits that bear repeating here, along with new advantages we have identified. As managers, measurement helps us do the following:

● Communicate effectively and improve visibility. Measurement supports communication among stakeholders across all levels of the organization. Objective measurement also reduces ambiguity. It provides an effective way to communicate status between suppliers and their clients.

● Identify and correct problems early. Measurement facilitates pro-active management. It allows us to identify and manage potential

Effective management through measurement

problems early in the development lifecycle. Problems discovered late are more difficult to manage and more costly to fix. With measurements, managers do not have to wait for problems to arise; instead, they can anticipate and quickly address them.

● Make key trade-offs. Decisions in one area often impact others. Measurement helps assess the impact objectively so that managers can make informed trade-off decisions to best meet project objectives.

● Track specific project objectives. Measurement helps managers answer specific questions such as: "Is the project on schedule?" or "Is the quality improving?" or "Is the system ready to be delivered?" By tracking actual measures against a plan, managers can assess progress toward project and organizational objectives.

● Manage risks. Risk management is a widely accepted best practice that involves identifying and analyzing risks early in a project's lifecycle. Risks uncovered late can be difficult and costly to fix. With high-quality objective data, managers can gain visibility into risk areas such as requirements creep. By measuring and monitoring requirements volatility, they can determine whether a risk has been mitigated.

● Defend and justify decisions. Managers must effectively defend and justify their decisions. Given a choice between basing their decisions on subjective or objective data, the vast majority would choose objective data. Measurement provides objective historical performance or trend data as well as current performance data. It also provides perspective with respect to time, projects, releases, and so forth. This allows decision makers to interpret the measures and decide on appropriate actions.

● Plan future projects. In project planning, managers must set realistic goals and schedules, not to mention budgets. Recording timelines and expenditures for past projects provides the data that managers need to predict schedules and costs for similar projects.

Measurement and processIt has been proven many times: Companies and teams that develop software successfully follow a repeatable and measurable process. At IBM Rational, we have also discovered how these companies and teams relate process to measurement. Successful organizations do the following:

● Establish the underlying process first.● Use measures that are natural by-products of the underlying process.● Follow the underlying process to make the measures valid.● Improve the quality of their measures via automation, which produces more objective results.● Identify instrumentation points in the process that they can translate into measures or trackable measurement attributes.

In working with many organizations, we have also identified common problems relating to measurement and process and helped managers find solutions.

● In some organizations the software development process is rigid, and measurement is secondary to this process. If you need a new measurement, you first need to update or change the process. You can resolve this problem by tailoring the process and incorporating instrumentation points directly into it. You can make these points easily accessible by deploying development tools to do the instrumentation (see Figure 1). Automated tools make it much easier to define what you can and will collect.

● Sometimes measurements do not reflect actual work. This is a problem if the organization can (or chooses to) track only project budget and schedules. In such cases, the amount of money or time spent on a task may not reflect the actual work performed. For example, you may know you spent X amount of dollars developing code, but you won't know how much code was actually developed. You cannot measure productivity by tracking only task schedules and expenditures. Again, by modifying your process to include additional measurements of project artifacts, such as requirements, use cases, design objects, code, test cases, defects, and so forth, you can get a more accurate picture of what your time and money actually bought and how far you have progressed.

Using automated tools like those shown in Figure 1 can help make measurement a key component of the software process and provide easy access to instrumentation points.


Figure 1: Tools in IBM Software Development Platform that are useful for measurement

Key management measures and viewsHow should you modify your process and what should you measure? We are often asked these questions. And often, our answer is, "It depends." First, it depends on where you are in the software development lifecycle. If you're doing iterative development, what you want to measure in the Elaboration phase will be different from what you measure in the Construction phase. It also depends on your position in your organization. If you're a division manager, you'll want different information than a project manager. You may be interested in improving productivity, whereas a project manager will be interested in meeting the proposed schedule and reducing the number of product defects.

The key is always to know your information needs and then design your measures. You can define these needs by organization, project, team objectives, issues, and risks. Furthermore, you'll want to categorize your measures in order to make them understandable to the intended users. As an example, in this article we will organize management measures based on IBM Software Development Platform capabilities, shown in Figure 1.

IBM Software Development PlatformA comprehensive set of tools, proven best practices, and professional services, IBM Software Development Platform helps teams build, integrate, extend, modernize, and deploy software and software-based systems. Using IBM Rational Unified Process®, or RUP®, as a foundation, the platform automates and integrates the software development lifecycle using an iterative development approach. Platform tools enable companies to focus on architecture, continually ensure quality, and manage change and assets so that they can better leverage their software development capability.

IBM Software Development Platform spans all areas of software development: ● Process and project management. Managers can plan and implement measures for every project and ensure consistent processes

across the enterprise.● Requirements and analysis. Automated tools help reduce risk by enabling managers to understand and manage the evolution of


business and software requirements throughout the software development lifecycle.● Design and construction. Teams can maximize their productivity while building business applications, software products, and

systems.● Software quality. Teams can increase predictability and ensure quality by uncovering defects early in the development lifecycle,

when they are easier to address and less expensive to fix.● Software configuration management. The platform includes tools for securely managing software changes and assets, providing

traceability throughout the development lifecycle.

Let's look at examples of management measures you can implement with IBM Software Development Platform for each of these areas. These examples were generated using IBM Rational® ProjectConsole, a component of IBM Rational Team Unifying Platform, which is itself a component of IBM Software Development Platform.

Rational ProjectConsole automates reporting on project status, providing a number of automated collection agents, customizable reporting, and a graphical dashboard, which allows you to customize measurement views and perform drill-down, root-cause analysis.

Measuring project management and processA successful measurement system must be flexible enough to satisfy the information needs of an organization. Measurement requirements vary from high-level views for executives at the C-level (CTO, CIO, CEO, etc.) or division manager level, to more detailed views at the project manager level.

Executives usually need high-level information. For example, the division manager responsible for a number of projects or products would like to determine, at a glance, the status of each project and key progress measures. A green-yellow-red visual status indicator can provide this high-level shorthand. The example view in Figure 2 displays information generated by Rational ProjectConsole for a list of projects. It includes:

● Status: Overall project status based on a calculated value compared to a known threshold. The actual calculation is organization- or project-specific.

● Open High-Priority Change Requests: The number of high-priority change requests that are currently open. In this example, this measurement was identified as an information need.

● Glidepath: The number of defects that have been verified versus the number of forecasted defects to be verified. In planning a release, the projects identified n-number of defects that teams planned to fix in the release. This measurement shows progress toward the goal.

● Test Coverage: Percent of the code that has been tested.● Change Requests to Verify: How much work is left to perform.

Figure 2: Executive view for a list of projects

Figure 3 shows another executive view with a visual (green-yellow-red) status indicator of project health. The executive can also drill down on


the project name to view a second level of detailed status information (Figure 4) for each project.

Figure 3: Executive view of a division status report

At the project level, typical areas of interest for overall status reporting are:

● Project management: Cost, schedule, risk, staffing, and so forth.● Process: Compliance, conformance, productivity goals, and so forth.● Requirements and analysis: Progress in meeting requirements, volatility, and use-case development.● Design and construction: Completion of, and changes to, business, design, and database models; code development.● Software quality: Unit test progress, system test progress, test coverage. ● Software configuration management: Defect and change request tracking, baseline progress, activity management.● Engineering support: Tool development, software development environment support. ● Operations: Hardware availability.

Figure 4 shows an example project manager view.


Figure 4: Project manager's high-level status report for all areas

A manager might choose to drill down into the areas shown in Figure 5 to gather more status information related to the following project management categories:

● Highlights and issues: To identify, analyze, and track action items and issues. ● Planning and schedules: To monitor the project plan and schedules and track progress (work completed over time) against the plan.

One useful schedule indicator is the Schedule Performance Index (SPI), shown in Figure 6. SPI is a calculated index. If the SPI is greater than one, the project is ahead of schedule. If it is less than one, the project is behind schedule.

● Cost and earned value: To maintain control over expenditures throughout the project lifecycle. A useful cost indicator is the Cost Performance Index (CPI) shown in Figure 6. Like the SPI, the CPI is calculated. If the CPI is greater than one, the project is over budget. If it is less than one, the project is under budget.

● Staffing: To monitor project member additions and attrition as indicators of project momentum and morale. Sharp increases in staff can slow project progress as new people are brought up to speed. A low attrition rate for good team members is a sign of success. High turnover may indicate problems in morale or motivation; it is a warning sign for project managers.

● Risk: To continually identify, analyze, and track risks that threaten project success. Pro-active risk management increases the chance of project success.

● Compliance: To track compliance with standards or process improvement goals. ● Customer satisfaction: To ensure that customer needs are satisfied.

Project managers may pick and choose what categories to monitor on this list.


Figure 5: Project management status report

Figure 6: Cost Performance Index (CPI) and Schedule Performance Index (SPI)

Figure 7 shows progress against the plan. Automated project plans let you identify tasks and assign scheduled completion dates. Using IBM Rational ProjectConsole, you can track the progress of tasks in your project plan as you work toward completion.


Figure 7: Task progress — planned tasks versus tasks complete

In the process area, a project manager may want further status information about the following:

● Highlights and issues: To identify, analyze, and track action items and issues. ● Planning and schedules: To monitor the project plan and schedules for rolling out the process.● Cost and earned value: To track expenditures and their results.● Staffing: To track project member additions and attrition.● Risk: To identify, analyze, and track risks and mitigation efforts.● Compliance: To determine compliance with standards or process maturity goals. ● Defects contained: To monitor defects found and fixed during a specific time period or release. This measure may be an indicator of

test effectiveness.● Defects escaping: To measure the number of post-release defects. This measure may indicate problems in the software

development process.● Scrap and rework: To monitor the amount of change to the software baseline. In a healthy project, this trend is decreasing or stable.

Increasing rework is a sign of increases in maintenance demands and costs. Figure 9 shows scrap in line of code. However, scrap and rework are not limited to code; they also result from design changes and can be monitored in the design model.

● Productivity: To determine whether the underlying process is improving productivity.

Figure 8 shows a high-level green-yellow-red status report for process.


Figure 8: Status report for process area

Figure 9: Scrap — measured by lines of code deleted

Measuring requirements and analysisRequirements and analysis involves understanding the problem space, capturing and managing evolving requirements, modeling user interactions, and incorporating stakeholder feedback throughout your project lifecycle. Good requirements and analysis practices help reduce project risks.

Areas to monitor and measure within requirements and analysis include:

● Highlights and issues: Action items and risk mitigation in requirements and analysis.● Planning and schedules: Plan versus actual requirements or use cases developed against schedules.● Cost and earned value: Budget tracking for requirements and analysis.


● Requirement reviews: Progress on requirements and stakeholder reviews.● Use-case reviews: Progress on use cases and stakeholder reviews.● Inspections: Requirements verification.● Requirements volatility: Changing requirements impact schedules and cost. See Figure 13 for a detailed look at this measure.

A high-level view for a project manager could show green-yellow-red status indicators for each area, as shown in Figure 10.

Figure 10: High-level status view for requirements and analysis

Additional detailed views, such as the requirements summary in Figure 11 and the use-case summary in Figure 12 (both extracted from IBM Rational RequisitePro), can provide specifics about requirements and analysis development progress.


Figure 11: Requirements summary view

Figure 12: Use-case summary view


Figure 13: Requirements churn (volatility) — measured by number of revisions

Measuring design and constructionDesign and construction involves architecting and modeling for design, model-driven development, software coding, fixing defects and responding to enhancement requests, and component testing.

Within design and construction, areas to monitor include:

● Highlights and issues: Action items and risk mitigation.● Planning and schedules: Planned design elements or source code versus actuals and against schedules. ● Staffing: Additions and attrition among development staff. This measure is important on large projects.● Cost and earned value: Expenditures and budget tracking.● Design model completeness: Completeness of your architecture and design model, or design model progress (trend). See Figure

15. Ideally, compare against planned values (not shown).● Size at complete: Code development trends that show progress (see Figure 16). Ideally, compare actual code developed against

planned values (not shown) to determine how much work remains to be done. ● Software inspections: Peer review inspections to uncover defects, inconsistencies, and trouble spots in products that might affect

quality and performance.● Requirements volatility: Changing requirements that impact delivery schedules and increase software rework and cost. ● Open problems and originating dates: Number of open problem reports, together with their age, that help determine whether

staffing is adequate.

Figure 14 shows a high-level, green-yellow-red status view of design and construction for a project manager.

Figure 14: Design and construction high-level status view


Figure 15: Design model completeness measured by classes developed

Figure 16: Trend of total source lines of code (SLOC) developed


Measuring software qualityEnsuring software quality involves testing functionality, reliability, and performance. It also involves tracking all your test efforts and ensuring test coverage for all required functionality in an application targeted for release.

For software quality, areas to monitor include:

● Highlights and issues: Action items, issues, and risk mitigation.● Planning and schedules: Planned test cases versus actual results and against schedules.● Staffing: Additions and attrition among the test team.● Cost and earned value: Budget tracking.● Unit testing: Number of tests planned, executed, passed, and failed to determine progress.● System testing: Number of tests planned, executed, passed, and failed (Figures 18 and 19).● Performance testing: Throughput or response times.● Defects: Tracking for customer-reported defects (Figure 20) or all defects (Figure 21).

For software quality, a project manager might view a high-level green-yellow-red status report like the one in Figure 17.

Figure 17: High-level status view for software quality


Figure 18: Test status (trend chart)

Figure 19: Test status by iteration


Figure 20: Defect tracking — customer reported defects

Figure 21: Defect tracking by severity


Measuring software configuration managementSoftware configuration management involves capturing, controlling, and managing software changes and assets. This includes defect and change tracking along with software asset management.

Within software configuration management, areas to monitor include:

● Highlights and issues: Action items and risk mitigation, which are usually necessary within all areas of a project.● Planning and schedules: Source code planned for development versus actuals and against schedules. ● Staffing: Additions and attrition among configuration management staff.● Cost and earned value: Budget tracking.● Defect status: Targeted defect status.● Enhancement status: Status of features under development.● Build status: Build readiness.● Code churn: Number of lines added, modified, and deleted in the configured or baselined software (Figure 23). This measure shows

build and release readiness. Increasing churn indicates that the release is "not ready."

Figure 22 shows a high-level, project manager's view of the status for these software configuration areas.

Figure 22: High-level view of software configuration management status


Figure 23: Configured software code churn

SummaryFor managers, measurement provides progress assessment, insight into the quality of an evolving project, and data for objective decision making. Although it cannot guarantee a project's success, measurement does help decision makers take a proactive approach to managing critical issues inherent in software projects.

We have provided many examples of measurement views, but the key to success is not to implement all the measurements shown here. Rather, assess your project and organization, identify your stakeholders' needs, identify measures and indicators to ensure that you satisfy those needs, and implement a non-intrusive, automated measurement program that will provide the objective information you need to make key management decisions.

For more information about IBM Software Development Platform, see the IBM Web site.For information about IBM Rational ProjectConsole, see the IBM Team Unifying Platform page.

ReferencesDoug Ishigaki and Cheryl Jones, "Practical Measurement in the Rational Unified Process." The Rational Edge, January 2003.

John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, and Fred Hall, Practical Software Measurement: Objective Information for Decision Makers. Addison-Wesley, 2002.

Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition. Addison-Wesley, 2000.

IBM Rational Unified Process 2003.06.12. IBM, 2004.

Practical Software and Systems Measurement Web site (includes the PSM Insight tool): http://www.psmsc.com.

ISO/IEC 15939 Software Measurement Process. International Organization for Standardization, 2002.

Software Engineering Institute, "Capability Maturity Model® Integrated (CMMI(sm)) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, Version 1.1 Staged Representation." Carnegie Mellon University, March 2002.

Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley, 1998.

About the authorDoug Ishigaki joined Rational Software in 1996, where he has been primarily involved in the research and development for Rational ProjectConsole. As senior technical marketing engineer, he helps customers understand and deploy IBM Rational ProjectConsole. Prior to joining Rational, he was involved in all phases of development and deployment for a large, real-time distributed system as well as a commercial middleware product at TRW, Inc. He holds a degree in linguistics/computer science from the University of California, Los Angeles.



Comments?


Search for: within




Project Portfolio Management (PPM): Aligning business and IT

Contents:What is PPM?

Business drivers for PPM

Key benefits of PPM

Aspects of IT management

First steps: A common process

References

Notes

About the author

Rate this article



Ashok ReddyIBM11 May 2004

from the Rational Edge: This article introduces Project Portfolio Management, or PPM, a strategy that involves managing a project portfolio much as you would manage a portfolio of diverse financial investments. By using PPM, organizations can align their IT projects and resources with corporate business objectives.

Today's business organizations are increasingly using software development and IT to capture and apply knowledge that is unique to their business in order to drive innovation and make better use of limited resources. This reliance on IT to support new business initiatives is a major aspect of on-demand computing, IBM's vision for a business environment in which companies respond with flexibility and speed to any customer demand, market opportunity, or external threat. Realizing this capability, however, has its challenges, including:

● Lack of understanding among business managers about how IT can help achieve corporate goals; many regard IT as a necessary evil.

● In some organizations that recognize the importance of investing in IT to achieve corporate goals, IT projects often do not deliver enough value because they fail to align themselves with business objectives.

● Some IT organizations launch more projects than they can handle effectively; and they neglect to set project priorities based on business objectives.

● IT decision makers in many organizations do not know how to analyze needs and focus resources on projects that would lead to better efficiency and cost savings.

This article introduces Project Portfolio Management, or PPM, a strategy supported by IBM's Software Development Platform that helps organizations meet these challenges. This article will explain the strategy; a future article will discuss how IBM Software Development Platform tools, including IBM Rational Unified Process,® or RUP,® function in connection with PPM.

What is PPM?PPM is a strategy that allows organizations to align their IT and application development projects, resources, and initiatives to


corporate business objectives by developing and monitoring measures that treat IT assets as financial assets — and to run as a project-oriented business. PPM enables integrated management of pipeline, scope, time, resource, skills, cost, procurement, communication, reporting and forecasting, and risk management functions.

In essence, PPM allows you to manage a portfolio of projects much as you would manage a portfolio of diverse investments, such as stocks, bonds, real estate, and so forth. By maintaining a balanced portfolio, you can reduce the risks of individual projects and produce an overall higher rate of return. PPM allows executives and managers to proactively monitor their project portfolios for alignment with business objectives and planned costs and schedules. It also allows them to identify project risks and quickly address them.

Business drivers for PPMWhy do businesses need a PPM strategy? Let's look at some of the strongest reasons:

● Limited IT budgets and resources. Most organizations need to improve the way they use their existing resources in order to maximize productivity. This applies to both people and tools.

● Need for better IT governance (and data for compliance with Sarbanes Oxley Act1). Many IT organizations lack a consistent, accountable body for decision making. PPM provides a decision-making framework that helps ensure IT decisions are aligned with the overall business strategy; IT participates in setting business goals and directions, establishing standards, and prioritizing investments.

● Need to improve project success rate. According to the latest Standish Group survey, executive support and clear business objectives are among the top ten success factors for application development projects. PPM includes approaches for achieving both of these requirements.

Table 1 lists, by IT management role, the specific challenges that PPM addresses.

Table 1: Challenges for IT management roles

Role Challenges

CFO/CIO/CTO● Cope with reduced budgets and increased expectations. ● Meet productivity goals consistently.● Align business goals and IT projects.● Use reliable measures to determine whether teams are really working on the "right" projects.● Put out fires and cut costs that prevent proactive planning.

Portfolio/Program Manager ● Prioritize initiatives, resources, and assets across the project portfolio.

● Assess and communicate portfolio status.● Ensure consistent processes across projects.● Enable reuse of assets and optimize key resources across projects.

Project Manager● Align project management and application development processes.● Match up business team and technical team perspectives.● Predict project outcomes, assess project status, and identify inter-project dependencies.● Manage scope, planning, verification, and change management.

Team Members● Understand project scope: priorities, requirements, dependencies, and traceability.● Monitor and report progress without sacrificing coding activities.

Key benefits of PPMAs with any new strategy, introducing PPM into an organization requires an investment of time and effort. However, this investment yields proven benefits:

● Closer alignment of IT with business: With an easily digestible, holistic view of their entire project portfolio, executives and managers can more readily understand where IT dollars are being spent and which projects continue to be worthwhile.


● Better IT governance: PPM helps managers monitor project progress in real time and provides detailed data to help satisfy Sarbanes Oxley Act compliance specifications.

● Cost reductions and productivity increases: PPM helps managers identify redundancies and allocate resources appropriately; it enables them to make better IT staffing and outsourcing decisions, and to spot opportunities for asset reuse.

● Business-based decision making: By viewing projects as they would view components of an investment portfolio, managers can make decisions based not only on projected costs, but also on anticipated risks and returns in relation to other projects/initiatives. This leads to improvements in customer service and greater client loyalty.

● More predictable project outcomes: A PPM strategy bridges the gap between business managers and the practitioners who deliver the projects; it ensures consistent processes across projects and helps managers assess project status in real-time, predict project outcomes, and identify inter-project dependencies.

Aspects of IT managementAs Table 2 shows, the PPM strategy addresses four main aspects of IT management associated with specific activities and functions. The table also details automated support for these activities and functions.

Table 2: The PPM solution framework

Aspect Activities Function Automated support

Govern● Identify and prioritize projects● Formulate vision/strategy● Analyze ROI ● Verify project value● Communicate progress and results

● Method management● Idea/innovation management● Portfolio management

● Project dashboard● Process controls and vocabulary● Analysis and management

Plan ● Schedule● Allocate resources for optimization and process

efficiency● Create a balanced portfolio

● Program planning● Project planning● Resource planning● Scheduling● Financial planning

● Project accounting ● Process templates● Resource management/skills matching ● Project scheduling and time management

Build ● Translate goals into action● Measure and verify performance● Deliver results

● Business process modeling● Requirements analysis● Design and construction

● Business modeling ● Requirements management ● System modeling and code generation● Configuration management and change

management ● Testing

Operate● Manage and maintain products● Measure project results against business

objectives

● Maintenance and productivity monitoring ● Business monitoring

● Application management and monitoring ● System analysis and performance

measurement ● Project metrics collection and comparison

against business models

Govern Governance relates to the most important questions for software development and IT managers: "Are we working on the right things, and are we building the right system?" If their teams don't get this right, nothing else matters. A project might be successful from a schedule, budget, or scope perspective, but if it fails to meet business objectives, it fails overall. Efforts to align business and IT objectives are often thwarted by governance issues, such as:

● Project teams use different vocabularies.● Team members do not understand the business objectives.● Projects are not prioritized by ROI potential. ● Software requirements are not traceable to business objectives.

To address these common causes of failure, a PPM strategy provides support for governance, including:


● Method management: A consistent, repeatable process, providing the means for establishing a common vocabulary, instituting a framework for assessing project health, and prioritizing initiatives.

● Idea/innovation management: Support for considering IT project requests in relation to other prospective and current projects (project pipeline management).

● Portfolio management: Ways to align and prioritize proposed initiatives and projects.

PlanFunctionality that enables planning under a PPM strategy includes:

● Program management: A holistic view of multiple projects and their inter-dependencies. ● Project management: Support for planning and tracking schedules, establishing milestones and assigning tasks for

individual projects, identifying project dependencies, completing Gantt charts and other reporting artifacts.● Resource management: Ways to plan, balance, and schedule resources for IT initiatives. ● Time management: Means to allocate, track, and compare time spent on project activities. ● Financial management: Help with establishing and managing IT budgets; means for capturing expenses and

obtaining approvals.

BuildTo ensure that developers build systems correctly, a PPM strategy includes functionality for:

● Business process modeling: Support for managers to discover, document, and specify current business processes with metrics, and specify new goals and requirements.

● Requirements analysis: Means to analyze financials and prioritize projects according to potential business value, define and prioritize requirements, identify/prepare existing assets for reuse.

● Design and construction: Functionality for rapid integration and/or application development, visual construction and programmatic code generation, unit testing and debugging.

● Testing and deployment: Support for functional and load testing, and for managing testing requirements.● Change management: Configuration management and change management support to deploy and monitor the

solution.

OperateTo verify a system's effectiveness, a PPM approach includes functionality for:

● Maintenance and productivity monitoring: Support for testing and measuring system performance.● Business metrics collection: Means for collecting and analyzing post-deployment business results. PPM also helps

you track metrics for component reuse.● Setup and monitoring of Service Level Agreements (SLA): Setup for specific IT service levels and metrics

collection for response time, service availability, and other parameters.

First steps: A common process Instituting a PPM strategy is one way IT managers can begin diagnosing and addressing the causes of project failures. However, ultimately, the "cure" must come from those managers' determination to bridge the disconnect between products their teams produce and the decisions of their organizations' business strategists. Standardizing on an automated process across every project in the IT portfolio is a proven way for managers to start building the bridge. RUP enables many of the management functions we have described in this article. A key component of IBM Software Development Platform support for the PPM strategy, RUP helps managers make meaningful plans, assessments, and corrections. It also provides a common, enterprise-wide vocabulary to enable communication among IT and business groups.

In an article to be published in The Rational Edge in Fall 2004, I will detail the support that RUP and other automated tools in IBM Software Development Platform provide for PPM. In the meantime, to get more information on the PPM strategy, see References below.


References"How to Run IT Like a Business." CIO Magazine, May 1, 2004. http://www.cio.com/archive/050104/howto.html

"At Your Service," eweek, March 1, 2004. http://www.eweek.com/article2/0,1759,1542787,00.asp

"The Best Best Practices: CIO Research Reveals the Basic Building Blocks of IT as a Business." CIO Magazine, May 1, 2004. http://www.cio.com/archive/050104/best.html

Notes 1 This Act is designed "to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws." Organized into eleven titles, the Act has three sections especially relevant to IT: Section 404, which requires officers to attest to the effectiveness of internal controls for financial reporting; Section 302, which requires officers to sign statements verifying the completeness and accuracy of financial statements; and Section 409, which requires that "material financial events" be reported in real time. The internal control report must articulate management's responsibilities to establish and maintain adequate internal control over financial reporting as well as management's conclusion on the effectiveness of these internal controls at year-end. The report must also state that the company's independent public accountant has attested to and reported on management's evaluation of internal control over financial reporting. More information is available at http://www.aicpa.org/info/sarbanes_oxley_summary.htmand http://www.sarbanes-oxley-forum.com.

About the authorIn addition to setting product strategy for IBM Rational process and portfolio management solutions, Ashok Reddy manages both the RUP and IBM Rational SUMMIT Ascendant product management teams. Previously, he was responsible for Rational Software’s unified software project management, common reporting, XML Web Services, and .NET strategies; he also served as a product manager for Rational’s ProjectConsole, SoDA, and XDE Web Modeler. He is certified by the Project Management Institute (PMI) as a Project Management Professional (PMP), and he represented IBM Rational on the PMI Executive Council, Web Services Interoperability (WS-I). Registered in California as a Professional Engineer (PE), he holds an MBA as well as M.S. and B.S. degrees in engineering.



Comments?




Search for: within




Program management: Different from project management

Contents:

Program governance

Program management

Program financial management

Program infrastructure

Program planning

Conclusion

References

Notes

About the author

Rate this article



Michael F. HanfordIBM6 May 2004

from the Rational Edge: Mike Hanford asks some basic questions about program management and discusses practices associated with this discipline. He explains relationships between project management and program management roles and techniques, noting significant differences.

Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that "traditional" project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.

This article considers five major aspects of program management:

● Governance: Defining roles and responsibilities, and providing oversight

● Management: Planning and administering both projects and the overall program

● Financial management: Implementation of specific fiscal practices and controls

● Infrastructure: The program office, technology, and other factors in the work environment supporting the program effort ● Planning: Activities that take place at multiple levels, with different goals. The program plan is not a traditional plan

We will take a closer look at each of these aspects, contrast them with similar aspects of project management, and outline for each the effort and results required to achieve success.

Program governance Program governance is the aspect of the discipline that creates both the structure and practices to guide the program and provide senior-level leadership, oversight, and control. Strategically, it encompasses the relationship between the oversight effort and the enterprise's overall business direction. It also encompasses all the decision-making roles and responsibilities involved in executing the program effort.

Projects are typically governed by a simple management structure. The project manager is responsible for day-to-day direction, a senior IT executive integrates technology with business interests, and a business sponsor is accountable for ensuring that the deliverables align with business strategy.

Programs require a more complex governing structure because they involve fundamental business change and expenditures with significant bottom-line impact. In fact, in some instances their outcomes determine whether the enterprise will survive as a viable commercial/governmental entity.


Figure 1 shows a sample governance structure for a complex program.

Figure 1: Sample program governance structure

As we can see in Figure 1, unlike most projects, programs usually have a steering committee or other group that represents diverse interests and provides executive-level oversight. As the program evolves, this governing body ensures that it continues to align with the enterprise's strategic direction and makes decisions that may eventually filter up to the board of directors. Defining the role and decision-making powers of the steering committee is a significant part of the program governance effort and should be done with an eye toward facilitating rapid decisions and promoting a clear, unified direction.

Figure 1 also illustrates a typical program management structure, which is more complex than that of a project. Creating this structure involves defining specific roles with specific decision-making authority, and making clear to all who "owns" certain program functions.

Good governance is critical to program success. A poorly articulated management structure, overlapping roles and decision-making authority, and roles filled by the wrong people (or not filled at all) can prevent a program from achieving sustained momentum or bog it down with endless attempts to achieve consensus on every decision.

Program managementWhat is program management? Is it really management at all?

To answer these questions, let's begin by looking at an accepted definition of project management:

Project management is the planning, organizing, directing, and controlling of company resources… for a relatively short-term objective.1

It is clear from this definition that project management is concerned with the dynamic allocation, utilization, and direction of resources (both human and technical), with time — in relation to both individual efforts and product delivery schedule — and with costs, relating to both the acquisition and consumption of funding. As a corollary, it is safe to say that without the direction project management provides, work would have to proceed via a


series of negotiations, and/or it would not align with the goals, value proposition, or needs of the enterprise.

Within a program, these same responsibilities (i.e., allocation, utilization, and direction) are assigned to people at three levels in the management hierarchy; the higher the level, the more general the responsibilities. For example, at the bottom of the management hierarchy, project managers are assigned to the various projects within the overall program. Each manager carries out the management responsibilities we described above.

At the middle of the hierarchy is the program manager/director,2 whose major responsibility is to ensure that the work effort achieves the outcome specified in the business and IT strategies. This involves setting and reviewing objectives, coordinating activities across projects, and overseeing the integration and reuse of interim work products and results. This person spends more time and effort on integration activities, negotiating changes in plans, and communicating than on the other project management activities we described (e.g., allocating resources, ensuring adherence to schedule, budget, etc.).

Responsibilities of a program manager/director

● Accountable to executive sponsors for schedule, budget, and quality of all program elements.

● Leads high-level sessions for program plan and schedule development.

● Reviews/approves project plans for conformance to program strategy and program plan and schedule.

● Acts as the communications conduit to executive sponsors and program steering committee and conducts periodic briefings/status updates.

● Escalates decisions to executive sponsors as necessary.

At the top of the program management hierarchy are the program sponsor(s) and the program steering committee. Their major responsibility is to own and oversee the implementation of the program's underlying business and IT strategies, and to define the program's connection to the enterprise's overall business plan(s) and direction. Their management activities include providing and interpreting policy, creating an environment that fosters sustainable momentum for the program (i.e., removing barriers both inside and outside the enterprise), and periodically reviewing program progress and interim results to ensure alignment with the overall strategic vision.

These individuals receive periodic summary reports and briefings on funding consumption, resources and their utilization, and delivery of interim work products and results. Typically, they will focus on these reports only if there is significant deviation from the plan.

So, let's return to the questions we posed at the start of this section: What is program management? Is it really management at all?

If you think of management activities strictly as those we defined for project management, then the answer to the second question is "No," or maybe "Partly." At the project level, managers do still perform these activities, but the program manager/director addresses a different set of program goals or needs, which requires a different "bag of tricks" as well as a different view of what is happening and what needs to get done. And at the top of the hierarchy, the executive leaders who set goals and oversee the program certainly do not perform the same detailed activities as project managers.

Program financial managementThe financial aspect of a program includes the need to conform to internal (and sometimes external) policies and/or regulations for significant expenditures. It also includes development and use of program-specific procedures for making and reporting expenditures.

Overall costs for programs are typically significantly greater than those for projects. For example, projects that consume one to five man-years of effort might have an internal cost range of $250,000 to $1,000,000, assuming the resources are employees (not contractors) with an hourly charge-back rate of $100 to $150 per hour. A program to upgrade and rewrite the core software applications of a large financial services company might require between 750,000 and 1,000,000 work hours, a staff of 175 consultants and 225 employees, and expenses ranging between $160,000,000 and $200,000,000.

The costs are greater not only because the program is larger, but also because it entails more types of expenditures. In a project of the size we just described, most — if not all — the expenditures are for labor, from an accountancy perspective. The program costs would include labor (both internal chargeback and consulting fees, and travel and living expenses, including short-term apartment leases), hardware, packaged software applications (which may be capitialized and depreciated), work space (perhaps construction, too), and furnishings/equipment, such as computers, servers, printers, desks, chairs, cubicles, and so on. Enterprises have different ways to treat these expenditures, outlined in financial policies and procedures. Government agencies and regulated industries may also have laws or regulations regarding spending and expense reporting.

From an administrative point of view, the responsibilties associated with authorizing, recording, and reporting program expenditures go well beyond those typically exercised by an individual project manager. Typically, the office of the Chief Financial Officer (CFO) will be involved during the strategic definition and financial justification phases of a program. Financial analysts will construct and/or use complex financial models, see that the enterprise's financial policies are interpreted and applied correctly, and ensure that the program's financial impact is accurately represented to executives at key decision points.

The CFO's engagement will continue, with different responsibilities, throughout the program's lifecycle. The program office will typically include a role for a budget administrator who assists the program manager/director in ensuring conformance to financial policies and guidelines. A best practice requires the CFO to fill this role with a full-time or part-time financial analyst.

Early in the program, you should plan and conduct a checkpoint review of the financial management apparatus and identify needs and requirements that are specific to the program.


Implementing the program's financial practices may require nothing more than educating people about how to apply them. However, in some instances you may need to tailor and adopt policies, create new cost centers and/or a chart of accounts, and outline financial procedures and assign decision authority unique to the specific program.

In any case, the skills required to create and ensure program-wide application of sound financial practices are typically not required for a project effort. To succeed, program financial management demands early and active engagement on the part of the CFO and his or her staff.

Program infrastructureInfrastructure is a useful term to describe collections of roles, tools, and practices that organizations assemble and integrate in order to provide services and support for software development. To understand the infrastructure required for a successful program, let's first explore the management and administrative roles, tools, and practices that constitute the Program Management Office, or PMO. Then we will look at requirements for the technical environment and tools.

Administrative infrastructureOf course, simply creating and operating a PMO — which can assume many forms — differentiates programs from projects. Our discussion will focus primarily on PMOs that support a single program — one that will be disbanded at the close of the program effort. However, we should keep in mind that in some IT organizations, an Enterprise PMO is a permanent fixture, providing services to multiple (and changing) programs.

PMO roles

● Program office management● Resources coordination● Budget administration and procurement● Risk assessment● Work products tracking and review● Facilities administration● Contracts administration● Technical support liaison● Training coordination● Methodology and process support● Issues management ● Communications management ● Status reporting management

The PMO provides administrative and management support to the program manager/director and all other program participants. It also provides specialized staff expertise for specific work areas.

The PMO involves many roles covering numerous areas and activities (see sidebar). In addition to serving the program manager/director, the staff members, a group of senior specialists, fill essential program roles. For large, complex programs, the PMO helps establish and maintain appropriate work processes, controls, and reporting functions to keep management apprised of the program's progress. It also defines, plans, and completes various work efforts.

As an example, let's examine just one role in the PMO — facilities administration — and how it contributes to program success. Whoever takes on this role must identify, plan, and deliver all necessary facilities for either a program-specific or permanent PMO. To do this, the facilities administrator must:

● Work with the PMO manager and program manager to define what should be included in facilities and define and prioritize facility needs.● Develop and gain approval for a facilities plan. ● Manage execution of the facilities plan and associated deliveries, construction, and installation. ● Collaborate closely with the infrastructure and technical environment coordinator.

Let's compare the value of this role within a project versus a program. For a single, small project with a maximum of seven employees on the construction team, this role would add little value. The team members would likely have offices or cubicles and the ability to reserve meeting rooms through a reservation system.

But suppose you have a program for which mobilization will take four weeks. Over this period, 200 consultants are to become resident at the principal office campus, 260 IT staff will be assigned to the program, and the three project managers insist that their project teams be co-located for efficiency. There is a need for twelve dedicated photocopiers, five dedicated conference rooms, a space for the program office, and so forth. The daily billing rate for all 200 consultants is $360,000. So if the operation of these facilities is delayed by five days and the consultants cannot work on site — well, you can do the math. Clearly, someone must "own" the responsibility to set up the proper space and tools to get the job done.

In truth, we could devote an entire article to the work performed by the PMO — and that office does not even cover every responsibility. For now, let us just say that the infrastructure the PMO provides enables all the project teams involved in the program to be productive.

Technical environment and tools A program infrastructure also includes both hardware — for desktop and network devices for storage and communication — and software, including desktop software and shared platforms with development tools, modeling software, planning tools, communication tools (email, Internet browser, virtual meeting /collaboration programs, telecommunications programs), and software for document retention and reproduction.

An individual project, especially a pioneering effort, may introduce new tools or hardware partly in order to understand their capabilities and limitations. The project manager may become involved in technical support or infrastructure functions, to acquire, install, and/or "tune" the hardware and software. Typically, this will involve a small number of installations for a small number of IT staff. Periodic changes and/or additions to the development environment will affect larger numbers of IT staff, but these are typically defined and managed as separate projects.

Program technical activities, in contrast, usually include large numbers of staff from a variety of sources (internal and external) and various technology


backgrounds. As managers identify and staff component projects in the program, they must also specify, acquire, and install technology environments and tools for each project, which collectively form the program's technical infrastructure. This effort might encompass creating a new, remote development site or integrating two companies' technologies following a merger, for example.

This infrastructure effort should be treated as an internal program project (as opposed to an external project, which delivers components or results to clients). Managers should plan a well-defined, rapid, and brief lifecycle for creating the technology environment. The effort should include defining needs and requirements, setting a scope, and installing, testing, and implementing all technologies. If some tools will be new to some portion of the program staff, it may also be necessary to define a rapid-delivery training effort.

Managers should also consider how the infrastructure's hardware and tools will be used beyond the program's boundaries. If they felt compelled to select technologies different than those in the current enterprise IT architecture, then supporting and maintaining new software applications built with those technologies may require additional personnel, software, and training. Managers should always carefully evaluate the potential impact of their program technology selections upon existing IT architecture and resources (and perhaps future direction) before actually making the acquisitions.

Program planning For program planning, most managers will typically use a bottom-up approach that identifies and executes planning iterations for the program's individual component projects. First, each project manager constructs a plan that estimates and allocates resources required to deliver the project's products or results, using the same techniques and practices they would employ in planning a standalone project.

Then, in the next planning iteration, managers identify connections and dependencies among the program's projects, and refine and rework their project plans to integrate them with others. Often this integration effort requires adjustments to the products planned for each project, the numbers and types of resources required, and — naturally — the schedule. The managers' ability to continuously manage and adjust to inter-project dependencies is a significant determinant of program success. This ability is also a major differentiator between the requirements of project planning and program planning.

The program planOnce the individual project plans are integrated, it is time to initiate the program planning effort. What exactly is a program plan? American Heritage Dictionary defines a plan as "A scheme, program, or method worked out beforehand for the accomplishment of an objective: a plan of attack." But when we look at how we develop and use program plans, we discover that they do not fit neatly into this definition.

First of all, in contrast to the planning for the program's projects, the program plan typically is not developed through a series of iterations. Instead, the planning effort involves conducting a series of reviews of the individual project plans, and then creating a digest of their contents. During this process, conflicts between projects may become apparent and require resolution. A goal of the digest effort is to produce a concise, usable view of all program work, timeframes, and required results. A program plan describing 10,000 activities, for example, would not have these qualities.

You don't use the program plan to direct work and allocate resources. That is the purpose of the individual project plans. It may be helpful to think of the program plan as a seismograph that seeks to detect and measure the potential impact of any trembling in the ground underneath the program effort. As component projects proceed and individual project plans record completion percentages, expenditure of resources, and interim (or final) dates for work activities, the program plan integrates these measures and shows their collective impact. This enables managers to assess the program's progress against plan and detect potential problems. For example, if a client asks for additional functionality in a component that one project is building, that may delay the component's delivery to other projects and slow them down as well.

In short, the program plan's integrated representation of significant planned activities and results of individual projects provides managers with a window into the cumulative work effort of the program. Managers use it to verify that the program is moving in the right direction to meet business goals, identify where unplanned changes may be occurring and assess their potential impact, and to model and/or test the impact of possible adjustments and corrections.

Conclusion In this article we have just begun to explore the differences between project and program management. We have seen that programs require capabilities and resources that are not generally required in the project management space, and which correlate directly with the program's success.

In general, program efforts have a larger scale and impact than most project efforts. The outcome(s) of a program effort can have a significant impact upon business and product viability. These efforts can also consume significant amounts of funding — which can translate into hard choices about whether to continue or discontinue programs or certain aspects of them. For example, although the US space program of the 1960s put a man on the moon and created significant new products and engineering capabilities within the American economy, it cost taxpayers tens of billions of dollars, and precluded other government initiatives. Funding for this program was the result of many hard choices.

Program efforts, with their large staffs, typically develop greater momentum than standalone projects. This momentum helps programs accomplish major amounts of work (a good thing), but it can also make programs resistant to changes in direction. Lack of vision, changes in vision, and poor direction can lead a program to consume enormous amounts of money in relatively short time periods without providing real value or useful results.

Fortunately, applying sound techniques and practices specific to program management can enhance an effort's chances of success and reduce risk.


For enterprise-scale work efforts, these practices can enable an organization to pursue its business strategy and remain competitive.

References IBM Rational SUMMIT Ascendant, "The Program Management Method." Version 8.1, February 2004.

Office of Government Commerce (OGC): HMSO, "Managing Successful Programmes." Copyright 2003.

Deborah Kezsbom, et al., Dynamic Project Management. John Wiley & Sons, 1989.

Notes1 Deborah Kezsbom, et al., Dynamic Project Management. John Wiley & Sons, 1989.

2 In the UK, the Office Of Government Commerce (OGC) calls this role Senior Responsible Owner in its publication, "Managing Successful Programmes," explaining that this role is charged with : "… providing overall direction and leadership for the delivery and implementation of the programme, with personal accountability for its outcome." See References in this article for more information.

About the authorMichael F. Hanford is the chief methodologist for the IBM SUMMIT Ascendant methodologies and a member of the IBM Rational commercial methods content team. He has also worked as a methodology author, a manager for large consulting engagements, and a leader of enterprise process assessment and transformation efforts for IBM Rational and PriceWaterhouseCoopers Consulting (PWCC). Prior to joining PWCC, he was director of software engineering practices for Fidelity Investments Systems Company.



Comments?




Search for: within




Software Project Management - A Mapping between RUP and the PMBOK

Contents:RUP overview

Dimensions of RUP

RUP disciplines

RUP lifecycle

The RUP PM discipline

A RUP/PMBOK comparison

PMBOK overview

Dimensions of PMBOK

PMBOK knowledge areas and process groups

PMBOK lifecycle

PMBOK deliverables

PMBOK and RUP mapping

PMBOK to RUP meta-model mapping

Mapping PMBOK knowledge areas to RUP disciplines

Mapping PMBOK processes to RUP activities

Mapping PMBOK process outputs to RUP artifacts

Conclusion

Notes

About the author

Rate this article



Serge CharbonneauXelaration Software Corporation3 May 2004

from The Rational Edge: This paper compares the Rational Unified Process (RUP) with the PMI’s “Project Management Body of Knowledge” (PMBOK) and provides a mapping between best practices in the RUP project management discipline and best practices in the PMBOK.

Many organizations wish to standardize their software engineering practices as well as their project management (PM) practices, and two well-known processes are available to help in both these areas, respectively. The IBM® Rational® Unified Process,® or RUP®, offers a prescriptive approach for standardizing on software engineering best practices, and the Project Management Institute® (PMI®) Guide to the Project Management Body of Knowledge® (PMBOK®) offers a descriptive approach for standardizing on project management best practices. With both these approaches available to organizations, the question becomes: Are they compatible? The simple answer is, "Yes."

This paper provides a more elaborate answer to that question by mapping the RUP project management (PM) discipline best practices to the PMBOK best practices. Throughout this mapping, I will highlight the similarities and differences between them. Essentially, the RUP focuses on PM best practices in the context of software development and deployment projects while the PMBOK best practices are generic and applicable to management of projects in any application domain — from building a bridge to implementing new business processes in a company. So, from an application domain standpoint, the RUP PM discipline is a specific instance of the PMBOK's generic PM best practices.

The RUP PM best practices identified in this paper are those described under the PM discipline within RUP1; other best practices more or less related to PM are described under other RUP disciplines, such as business modeling, requirements, analysis and design, implementation, test, deployment, environment, and configuration and change management, and when necessary this paper refers to those disciplines as well. The PMI PM best practices identified in this paper are described in the PMBOK2.


RUP overviewRUP is a software engineering process that describes who does what, when, and how in a software development and deployment project. It has the characteristics of being use-case driven, architecture-centric, risk-driven, and iterative.

Let's consider each of these important characteristics. Throughout a project guided by RUP, functional requirements expressed in the form of use cases drive the realization of the application's executable architecture. In addition, the process focuses team effort on building the important behavioral and structural elements of the application (the architectural elements) before building the less important elements. Mitigation of the most important risk elements drives the scope definition of the early iterations of its lifecycle. And finally, RUP partitions the software development lifecycle into iterations that produce incremental versions of the executable application.

RUP implements the following software engineering best practices:

1. Develop iteratively2. Manage requirements3. Use component architectures4. Model visually5. Continuously verify quality6. Manage change

Dimensions of RUPRUP implements the best practices listed above within a two-dimensional process. One dimension describes "disciplines" while the other dimension describes "phases" within the lifecycle of the process. Figure 1 shows a high-level graphical representation of the process.

Figure 1: Rational Unified Process


RUP disciplinesRUP disciplines are clearly related to the six best practices, but more closely represent individual roles for members or subgroups within the full development team. These disciplines are:

1. Business modeling2. Requirements3. Analysis and design4. Implementation5. Test6. Deployment7. Project management8. Environment9. Configuration and change management

Within RUP, each discipline is expressed in terms of roles (who performs the task), activities (how they perform these tasks), and artifacts (what the activity achieves). A role defines the behavior and responsibilities of an individual, or a group of individuals, responsible for activities and artifacts. An activity is a task for which a role is responsible and may be asked to perform. It describes the steps required to create or update one or many artifacts. An artifact is an input and/or an output to an activity. Other elements supplement these three key elements, such as concepts, work guidelines, tool mentors, reports, artifact guidelines, templates, and checkpoints.

Figure 2 shows a graphical representation of roles, artifacts, activities and other supplemental RUP elements.


Figure 2: Roles, activities, and artifacts

RUP lifecycleAs noted earlier, the RUP lifecycle is iterative, and its lifecycle dimension is divided into four phases:

1. Inception2. Elaboration3. Construction4. Transition

Each phase has a clearly defined set of objectives and ends with a major milestone. The milestones at the end of each phase are:

1. Lifecycle objective at the end of Inception2. Lifecycle architecture at the end of Elaboration3. Initial operational capability at the end of Construction4. Product release at the end of Transition

The goal of Inception is to define the project scope. The goal of Elaboration is to build an executable architecture for the application. The goal of Construction is to flesh out the architectural skeleton with most of the application's capabilities. And finally, the goal of Transition is to transition the application to the end-user community.

Each RUP phase is further divided into iterations, each ending with a minor milestone.

The RUP PM disciplineOf the RUP disciplines noted earlier, we are concerned with the project management (PM) discipline. The RUP defines software PM as the art of balancing competing objectives, managing risk, and overcoming constraints to successfully deliver a product that meets the needs of both customers (those who require the software to be developed) and the software users.

The RUP PM discipline provides:

1. A framework for managing software-intensive projects2. Practical guidelines for planning, staffing, executing, and monitoring projects3. A framework for managing risk

This discipline focuses mainly on the important aspects of an iterative development process:

1. Risk management2. Planning an iterative project, through the lifecycle and for a particular iteration3. Monitoring progress of an iterative project, metrics

A RUP/PMBOK comparisonHere I should point out several areas of management that fall outside the scope of the RUP PM discipline, but which are covered by PMBOK practices:

1. Managing people: Hiring, training, coaching (maps to PMBOK Project Human Resource Management knowledge area)2. Managing budget: Defining, allocating, and so forth (maps to PMBOK Project Cost Management knowledge area)3. Managing contracts: With suppliers and customers (maps to PMBOK Project Procurement Management knowledge

area)


We will discuss PMBOK knowledge areas in more detail later. For now, simply note that three of the nine PMBOK knowledge areas have no equivalent RUP discipline: Human Resource Management, Cost Management, and Procurement Management. However the Human Resource Management Organizational Planning process maps to the "roles" aspect of RUP, as its purpose is to identify, document, and assign project roles and responsibilities.

Primary RUP PM artifactsNumerous artifacts are created within the RUP PM discipline. The main artifacts are listed here, with the number of instances created in a typical project shown in parentheses:

● Software Development Plan (one) ❍ Quality Assurance Plan❍ Risk Management Plan❍ Measurement Plan❍ Product Acceptance Plan❍ Problem Resolution Plan

● Business Case (one)● Iteration Plan (many)● Iteration Assessment (many)● Status Assessment (many)● Risk List (one)● Work Order (many)● Issues List (one)● Project Measurements (many)

We want to map RUP characteristics to those found in the PMBOK, I will delve a bit further into the artifacts listed above and characterize four of them:

1. The Software Development Plan is:

● Created in the Inception phase● Updated throughout lifecycle● Outlined as follows:

❍ Project Overview ■ Project purpose, scope and objectives■ Assumptions and constraints■ Project deliverables

❍ Project Organization ■ Organizational structure■ External interfaces■ Roles and responsibilities

❍ Management Process ■ Project estimates■ Project plan■ Iteration plans■ Project monitoring and control

❍ Other Plans

2. The Iteration Plan is:

● Created once per iteration● Outlined as follows:

❍ Plan❍ Resources


❍ Use cases❍ Evaluation criteria

3. The Vision is:

● Not a PM artifact (Requirements artifact)● Created in the Inception phase● Outlined as follows:

❍ Positioning ■ Business opportunity■ Problem statement■ Product position statement

❍ Stakeholder and user descriptions ■ Stakeholder descriptions■ User descriptions■ Stakeholder needs

❍ Product overview❍ Product features❍ Constraints❍ Other information

4. The Business Case is:

● Created in the Inception phase● Outlined as follows:

❍ Product description❍ Business context❍ Product objectives❍ Financial forecast❍ Constraints

PMBOK overviewNow, let's turn our attention to the PMBOK. The PMBOK describes a set of generally accepted practices that PM practitioners can use to manage all types of projects, including software development and deployment projects.

The PMBOK defines a project as "a temporary endeavor undertaken to create a unique product or service." It defines PM as "the application of knowledge, skills, tools, and techniques to project activities to meet project requirements."

Dimensions of PMBOKThe PMBOK presents PM practices in logical groupings. One dimension describes "knowledge areas" while the other dimension describes project management processes split into five process groups. Figure 3 shows a high-level graphical representation of all 39 PM processes.3


Figure 3: PMBOK PM processesClick to enlarge

PMBOK knowledge areas and process groupsThe PMBOK knowledge areas are:

1. Project Integration Management2. Project Scope Management3. Project Time Management4. Project Cost Management5. Project Quality Management6. Project Human Resource Management7. Project Communications Management8. Project Risk Management9. Project Procurement Management

Each PMBOK knowledge area describes project management knowledge and practice in terms of one or more processes. Each process is further described in terms of its inputs, outputs, and tools and techniques. Inputs and outputs are documents or documentable items. Tools and techniques are mechanisms applied to the inputs to create the outputs.

The 39 processes are organized into five process groups:


1. Initiating Processes2. Planning Processes3. Executing Processes4. Controlling Processes5. Closing Processes

Figure 4 shows a graphical representation of the five process groups.

Figure 4: PMBOK process groups

PMBOK lifecycleThe PMBOK does not prescribe any specific lifecycle for projects. It specifies that the project lifecycle should be divided into phases. The number of phases varies based on the project scope and the application domain. It identifies that four to nine phases is typical for any type of project.

PMBOK deliverablesThe PMBOK defines a deliverable as "a tangible, verifiable work product such as a feasibility study, a detail design, or a working prototype."

Some of the main PMBOK deliverables are:

● Project Plan (with supporting details)● Work Results and Change Requests● Corrective Actions and Lessons Learned● Project Charter (with constraints and assumptions)

The Project Plan is:

● Created in Project Plan Development process early in the project lifecycle ● Updated throughout the project lifecycle● Outlined as follows:

❍ Project Charter


❍ Project Management Approach or Strategy❍ Scope Statement

■ Project objectives■ Project deliverables

❍ Work Breakdown Structure (WBS)❍ Cost Estimates, Schedule and Responsibility Assignments for Deliverables❍ Measurement Baselines for Scope, Schedule and Cost❍ Major Milestones and Target Dates❍ Required Staff❍ Other Plans

Let's consider one of the Project Plan characteristics: the Project Charter. The Project Charter has its own characteristics, as follows:

● Formally authorizes a project● Created in the Initiation process early in the project lifecycle● Outlined as follows:

❍ Business Needs❍ Product Description

PMBOK and RUP mappingThe following sections provide mappings between the RUP and the PMBOK. Most of the time RUP elements don't map perfectly to PMBOK elements and vice versa. You should keep in mind that the mapping presented in this paper is how I perceive the way these two standards map to each other. It is certainly possible to produce a slightly different mapping.4

For the purpose of mapping the RUP with the PMBOK, the PMBOK is used as the baseline since it is the more generic of the two standards, and RUP is compared to it.

Shared characteristicsBoth the RUP and the PMBOK recognize that PM is an iterative undertaking. The PMBOK describes this in the following terms:

It is important to note that many of the processes within project management are iterative in nature. This is in part due to the existence of and the necessity for progressive elaboration in a project throughout the project lifecycle; i.e., the more you know about your project, the better you are able to manage it.

Table 1 provides a mapping between the main characteristics of the PMBOK and RUP.

Table 1: PMBOK and RUP main characteristics.


PMBOK to RUP meta-model mappingBoth the RUP and the PMBOK group activities into structural groups and temporal groups. The RUP has structural groups of activities called disciplines and temporal groups of activities called workflows. The PMBOK has structural groups of processes called knowledge areas and temporal groups of processes called process groups.

Table 2 provides a mapping between RUP and PMBOK meta-models.

Table 2: PMBOK to RUP meta-model mapping


Mapping PMBOK knowledge areas to RUP disciplines Table 3 provides a mapping between PMBOK knowledge areas and RUP disciplines.

Table 3: PMBOK knowledge areas to RUP disciplines mapping.


Mapping PMBOK processes to RUP activities Table 4 provides a mapping between PMBOK processes and RUP activities. It presents PMBOK processes grouped by knowledge areas using the following format: <PMBOK Section Number> <Knowledge Area> → <Process>. It presents the corresponding RUP activities using the following format: <Discipline> → <Activity>.

Table 4: PMBOK processes to RUP activities mapping.







Mapping PMBOK process outputs to RUP artifacts Table 5 provides a mapping between the PMBOK process outputs and the RUP artifacts. It presents the PMBOK outputs using the following format: <PMBOK Section Number> <Knowledge Area> → <Process> → <Output>. It presents the corresponding RUP artifacts using the following format: <Discipline> → <Output Artifact> (<Artifact State>) [<Artifact Section>].

Table 5: PMBOK process outputs to RUP artifacts mapping.














ConclusionBased on the comparison between RUP and PMBOK, there are no fundamental incompatibilities between the two standards. As highlighted in this paper, different terms are used to describe semantically similar or identical concepts, but nothing in RUP contradicts the PMBOK practices and nothing in PMBOK contradicts the RUP practices.

Notes1 See Rational Unified Process 2003.06.01.06. Also: Kruchten, P. The Rational Unified Process: An Introduction. Reading, MA: Addison-Wesley, Inc., 2000; and Royce, W. Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley, Inc, 1998.

2 Project Management Institute (PMI), A Guide to the Project Management Body of Knowledge (PMBOK), 2000.

3 Figure 3 excerpted from A Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition, a publication of the Project Management Institute, 2000. Reproduced here by permission from the PMI.

4 Editor’s Note: As suggested here, an alternative method for mapping RUP and the PMBOK is described in Bill Cottrell’s article, "Standards, Compliance, and the Rational Unified Process — Part I: Integrating RUP and the PMBOK," also published in this issue of The Rational Edge.


About the authorSerge Charbonneau is principal consultant and founder of Xelaration Software Corporation. Mr. Charbonneau’s expertise is in planning software engineering capability improvement initiatives and successfully realizing these initiatives. Mr. Charbonneau has skills and experience in project management, requirements management, object-oriented analysis and design, and process engineering. During the 5 years prior to founding Xelaration Software, Mr. Charbonneau worked for Rational Software where he assisted organizations in implementing the Rational Unified Process (RUP) with the Rational suite of tools. Prior to working for Rational Software, Mr. Charbonneau played different roles in companies developing systems for the aeronautics, military, telecommunications and medical industries.



Comments?




Search for: within




Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK

Contents:Relating RUP and the PMBOK

What is RUP?

What is the PMBOK?

Relating RUP and the PMBOK

Tailoring RUP to PMBOK best practices

Find what needs to be tailored

Capture and communicate the changes

Try this yourself

References

Notes

About the author

Rate this article



Bill Cottrell ([email protected])Software Engineering Specialist, IBM10 May 2004

from The Rational Edge: This article explains the relationship between IBM Rational Unified Process, or RUP, and the PMBOK, the “Project Management Body of Knowledge,” maintained by the Project Management Institute, or PMI. It is the first in a series of articles describing the relationship of RUP to industry standards, what compliance means, how to leverage standards to improve your tailored use of RUP, and how you integrate those standards with RUP to achieve business value.

Standards — how some people hate that word. And while I don't share their distaste, I do understand it; nearly every day, I have some reason to discuss the relationship of industry standards to Rational Unified Process®, or RUP®. Some think of standards as their nemesis. I think of standards as an opportunity for companies to better integrate their software development efforts with the business and legal processes defining much of today's corporate landscape. True, software teams may not be involved in most audits, inspections, certifications, or assessments, but more than likely, IT teams are heavily involved with the results in the form of financial, organizational, and/or business process improvements.

What drives us to pursue compliance with industry standards? Consider a competitive merger in which the acquired company may already be compliant with some industry standard and the acquiring company wants to achieve the same level of compliance, company wide. Or consider a company deciding to outsource some part of its business that is not a core competency. More than likely, the external supplier is using standards that may or may not be part of the hiring company's current business processes. Finally, consider a regulatory audit. Any deficiencies will no doubt require changes in business processes. That means software development could be affected. The list of drivers goes on, and all are cases for standards adoption.

Believe it or not, there are industry standards, guidelines, and, yes, processes that can help us all achieve business goals, resolve business process deficiencies, gain a competitive edge, do more with less, or simply provide the equivalent of a thesaurus for better communication.

Over the past two decades, I've seen — or been a part of — my share of process improvement projects, and I'm now convinced that industry standards and guidance are not about whether your company is compliant with them, but whether you can leverage them to improve your processes. Yes, it is sometimes important to have that banner of compliance hanging outside the office building, but the bottom line is, if your improvements don't add value, the improvements will be superficial.

RUP is designed to be your business process for software development. While RUP embodies many industry best practices included in industry standards, in general, it is not designed to be compliant with industry standards. But RUP can be, and is, implemented — with some tailoring — to help a company become compliant with industry standards. In other words, RUP is a vehicle to help achieve business goals, gain a competitive edge, or simply provide a better communication vehicle so industry standards can add value in your workplace.

One such standard or guide is the Project Management Institute's "Project Management Body of Knowledge®," or PMBOK®. The PMBOK "describes the sum of knowledge within the profession of project management"1. Its stated purpose is to "identify and describe that subset of the PMBOK that is generally accepted" and to "provide a common lexicon within the profession and practice of talking and writing about project management," but clearly some practitioners think of the PMBOK as their software project management process and procedures.


This article is the first in a series of articles to explain the proper relationship between RUP and industry standards, what compliance means, how to leverage standards to improve your tailored use of RUP, and how you integrate them with RUP to achieve business value.

If you are not familiar with RUP or the PMBOK, start by reading about each in the next section. Otherwise, head straight to the section entitled How RUP and the PMBOK relate to each other.

Relating RUP and the PMBOKTo understand how RUP and the PMBOK relate to each other, you must first understand their respective concepts and frameworks.

What is RUP?RUP is a risk-driven, use-case-based, and architecture-centric, iterative software development process. RUP embodies industry-standard management and technical methods and techniques to provide a software engineering process particularly suited to creating and maintaining component-based software system solutions. RUP communicates roles, activities, and artifacts organized by process workflows that guide project teams through software engineering disciplines under the purview of operational business phases and decision making milestones.

RUP's foundation consists of three key elements: the role, the activity, and the artifact, as shown in Figure 1. The role performs activities and produces artifacts. Each role is primarily responsible for a set of activities and artifacts. But all roles will contribute to other activities and artifacts. Roles, activities, and artifacts are used repeatedly during the execution of workflows. The workflows form a sequence of tasks unique to each of the nine software disciplines in the RUP iterative development software lifecycle framework (see Figure 2).

Figure 1: Key elements of IBM Rational Unified Process


Figure 2: RUP framework

The RUP framework is two dimensional, with axes indicating time and content. The time dimension is organized by phases, iterations, and milestones. The content dimension consists of software disciplines containing the workflows, roles, activities, and artifacts as they apply to that discipline.

You implement the RUP framework via a complementary toolset, the capabilities of which generally map to the types of activities and artifacts required (Figure 3).


Figure 3: The RUP framework is implemented via a complementary toolset

As shown in Figure 3, RUP consists of five distinct parts:

1. The RUP process framework. This is the knowledge base of industry-proven best practices that forms the heart of RUP.2. The process delivery tools. These are the tools that deliver the valuable process content to the practitioner when needed, in the form

and quantity they need.3. The Rational Process Workbench. This consists of RUP Organizer and RUP Modeler. RUP Organizer allows you to create simple

plug-ins that complement, without altering, RUP's underlying structure. RUP Modeler allows you to create structural plug-ins for RUP that change RUP's underlying meta-model.

4. The Configuration tool. Otherwise known as RUP Builder, helps RUP users configure a base RUP configuration with the plugins created in RUP Organizer and RUP Modeler.

5. IBM developerWorks. The Rational developer domain on IBM developerWorks (http://www-136.ibm.com/developerworks/rational) hosts an active community of RUP users and RUP partners that can help customers optimize their use of RUP.


What is the PMBOK?The PMI PMBOK is a basic reference for those interested in or already working in the project management profession. It contains a subset of the body of knowledge maintained by project management practitioners and academic institutions. That subset includes the generally understood best practices that are widely used for project management in a wide variety of industries. Like RUP, the PMBOK describes key elements and processes, and it defines a project management framework. But it does not provide a prescription for using them in the context of software development. Rather, it is a general guideline for project management in any industry. The PMI expects experts in their specific industries to apply these guidelines to their respective business processes.

The key elements include roles, project management processes, and artifacts. Just as in RUP, the role performs the process activities to produce artifacts.

The PM role, project management processes, and artifacts are grouped in the project management discipline as knowledge areas. The PM processes describe best practice details for each knowledge area. The PMBOK framework consists of process groups, knowledge areas, and project management (PM) processes2 (Figure 4). The knowledge areas group the PM processes by project management content. That is, we can categorize the content of the PM processes into one of nine knowledge areas. The process groups (initiating, planning, executing, controlling, and closing, etc.) organize the more detailed PM processes over time.

Figure 4: The PMBOK PM process matrix

If we illustrate the framework in a diagram (see Figure 5) showing level of activity for each process group based on the time and content dimensions, we see a relative weight of activity over the project lifecycle that somewhat resembles that of the RUP framework diagram (see Figure 2 above).


Figure 5: PMBOK framework

Relating RUP and the PMBOK Now that we understand the RUP and PMBOK concepts and frameworks, we can compare them to help us understand how they relate. We will compare their utility to determine how one framework fits with the other. Here is the comparison:

● The PMBOK describes guidelines based on industry best practices. RUP helps software development teams implement software industry best practices. While RUP is tool-independent, when you use it in conjunction with IBM's software development tools, you can significantly improve productivity, completeness, reusability, and more.

● The PMBOK describes a generic project lifecycle. RUP prescribes a generic software development lifecycle within a project lifecycle. ● The PMBOK describes guidelines for any size project. RUP can be tailored to implement any size software project.

In making the above comparisons, my point is that the PMBOK describes project management best practices and RUP prescribes — helps us implement — software development best practices, some of which are related to project management. This is a key differentiation that helps answer the question I am often asked: "Does the PMBOK fit into RUP, or does RUP fit into the PMBOK"?

The answer is "neither." Why? Because the PMBOK by its own definition is designed to be applied to your existing business processes. Therefore, we can implement RUP as our software development business process, tailor it to our company, a line of business, a department, a program, or some other organizational unit, then apply PMBOK best practices. So, how does all this fit together with respect to RUP and PMBOK utility? Let's look at a few pictures to try to explain.


Figure 6: The PMBOK framework is implemented during each iteration within a RUP project

Figure 6 illustrates how the PMBOK framework is implemented during each iteration within a RUP project. A RUP project uses PMBOK best practices in every iteration, in all four RUP phases (Inception, Elaboration, Construction, and Transition) as part of the project management discipline. That means we need to tailor RUP to the PMBOK key elements. While the PMBOK is a framework and guidelines, it implies some roles, activities, and artifacts; so, we will consider the PMBOK as an existing process and incorporate its best practices into RUP.

Tailoring RUP to PMBOK best practicesAt the risk of sounding too much like a commercial, tailoring RUP is now easier than ever with the use of the Rational Process Workbench. Once we know how and why we are going to tailor RUP, we can build plug-ins to configure into RUP. Unfortunately, we still have to apply some brain power to the accomplish the what and how part of task. It would be wonderful if all we had to tailor was the RUP Project Management discipline. Unfortunately, project management activities are embedded in more than just this discipline.

The first step is to find the things you need to tailor. Next step, figure out how to capture and communicate those changes.

Find what needs to be tailoredBelow, I outline the steps to find what you need to tailor. Teams should document the results of these steps in whatever manner they wish, but I will offer an example of a result in a simple here:

1. Decide what configuration of RUP to start tailoring. RUP comes in three sizes: small, medium, and large (called Classic RUP). Determining how to choose one of these three is beyond the scope of this article. But for example purposes, I will use the RUP Classic configuration (the full RUP). There will be more roles, activities, and artifacts to review for tailoring. So choose wisely.

2. Ensure that you are familiar with the details of PMBOK framework elements and the RUP key elements. I would not start this activity without having thoroughly read both the PMBOK and the RUP content (at least the role-based material) so that you retain some of the content from each.

3. This step will take you a long way in your understanding of RUP and PMBOK content. To tailor RUP with the PMI best practices we will need to build a map of PMBOK roles, PM processes, and outputs to RUP roles, activities and artifacts. But the mapping is not itself the


tailoring we require. It is only the first step. While I have seen a number of mappings of RUP and the PMBOK, I would suggest that anyone looking to tailor RUP with the PMBOK best practices might want to do their own mapping. First, it is not that difficult, because there are not so many roles, activities, and artifacts in the PMBOK. Second, the mapping effort will give you a deep appreciation and insight into the content of each framework. Third, there is enough subjectivity in a mapping that you would probably tailor any existing mapping anyway, just to create consistency with your environment. For these reasons, I recommend you do this mapping yourself and be confident that it fits your organizations project management paradigm and that nothing has been overlooked.

There are many ways you could build a map. I suggest you start with each RUP role diagram (there are about 30 in the full RUP configuration), each of which lists all the activities that that role must complete.3

1. For each RUP activity in that role (there are about 150 activities for all roles combined in the full RUP configuration), map it to a PMBOK Process Group (Initiating, Planning, Executing, Controlling, Closing). You will not have to spend much time on each. The title alone will give you a hint if there is anything project management related or not.

2. Repeat this step for each role and collect all the RUP activities for PM processes.3. Then compare the content of each PMBOK PM process for that process group in the PMBOK to the RUP activities associated with that

group.4. From that comparison, determine if you need to adjust any RUP input artifacts with any PM process inputs, RUP steps with PM process

tools and techniques, or RUP resulting artifacts (there are more than a hundred for all roles combined in the full RUP configuration) with PM process outputs. (Remember, this part of the process is very subjective, which is why you should do your own mapping.)

5. If you find that any changes are required, write them down.6. Repeat these steps until you covered all activities for all roles; that should include all artifacts, too.

For the purpose of this article, I will provide an initial mapping of all the PM Process Groups to the RUP Project Manager role and associated activities. This mapping is shown in Figure 7.

Figure 7: RUP - PMBOK mapping example

Now, let's examine the first PMBOK Process Group: Initiating. Initiating, in red, is mapped to three RUP activities: Developing Business Case, Initiate Project, Initiate Iteration (also shown in red). Each PM process is mapped to the RUP activities. I repeat that for each role. Table 1 shows


Initiating mappings to RUP activities; for the purposes of this article, I will only trace the Initiating mappings to RUP.

Table 1: PMBOK Initiating PM process group mapping to RUP activities

PMBOK process group RUP roles affected RUP activities affected RUP artifacts affected Changes to make

Initiating Project Manager Developing Business Case, Initiate Project, Initiate Iteration

Include company project selection methods using our portfolio analysis process by modifying those steps under Developing the Business Case.

Management Reviewer Project Approval Review Work Order Add RUP Work Order Artifact to the Resulting Artifacts list of the Management Reviewer and as input to the Initiate Project Activity.

Business Process Analyst Identify Business Goals Business Case Add our company project selection criteria as input.

Note that in Table 1, I describe some changes to be made where, in my opinion, RUP does not satisfy the intent of the PMBOK guidelines; note also that I show only the exceptions. If I were trying to show my management or an auditor that I am complying with the intent of the PMI Standard, I would probably have to include all the mappings of RUP key elements to PMBOK elements. Once I finish this approach for all PMBOK PM Process Groups in each RUP activity for each RUP role, I can decide how I will make those changes.

Capture and communicate the changesThe simplest way to capture and communicate the RUP tailoring is to build a RUP development case. The development case template is available in RUP to capture the process after you have tailored it, and you can place this development case on the project Website for reference. In it you will have links to the tailored process. Everyone can review the tailored material can be reviewed in a team meeting prior to the start of a RUP iteration.

I could take this process a step further by illustrating how to build a plug-in using RUP Process Workbench (RPW) customization tools. As noted at the beginning of this article, these tools are RUP Organizer, which lets you make common customizations that don't affect the underlying RUP meta-model, and RUP Modeler, which you use to make structural plug-ins. But the details of that process could easily double the size of this article. So I will end this discussion here.

Try this yourselfI've seen or participated in my share of process improvement projects over the last couple of decades. In doing so, I have witnessed no more than limited success when the industry standard is used as the process for the company, line of business, department, program, or some other organizational unit. I've also experienced attempts to map a company's process to standards and guidelines, and those performing the mapping were certain that the effort would show the way to compliance, maturity, or certification. While mapping a standard to a business provides helpful insight into the standard and the process, it is only part of the effort needed to integrate them. Case in point: RUP and the PMI PMBOK.

By following the techniques outlined in this article, I believe you can tailor RUP to include the PMBOK best practices. Specifically, at IBM Rational, we have found that we can adjust RUP input artifacts with PMBOK process inputs, RUP steps with PMBOK process tools and techniques, and RUP resulting artifacts with PMBOK process outputs.

Once we have found what needs to be tailored, we have a few options to make those changes available to the project team. We can build a development case document, use RUP Organizer, and/or use RUP Modeler.

References

● A Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition. Project Management Institute, 2000. ● Rational Unified Process, Version 2003.06.01.06. IBM Rational Software, 2003.

Notes1 A Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition. Project Management Institute, 2000.

2 Op. cit. Reproduced here by permission of the PMI.

3 Editor's Note: An alternative method for mapping RUP and the PMBOK is detailed in Serge Charbonneau's article, Software project management: A mapping between RUP and the PMBOK," also published in this issue of The Rational Edge.


About the authorBill Cottrell is a field software engineering specialist with Rational in the IBM Software Group. Twice retired, he is now doing what he enjoys: using his experience in information technology, software engineering, system engineering, project management, process improvement, and organizational change management to help Rational customers. Prior to joining Rational, Cottrell spent twenty-one years in the United States Air Force and ten years in commercial industries, where he engineered and operated systems for communication, manned space flight, and financial services. He is the founder and past president of the San Antonio Software Process Improvement Network and a PMI-certified Project Management Professional. He holds an electrical engineering degree from the University of Arizona.



Comments?




Search for: within




Matching project and processContents:

Problem 1: Using a process “as is”

Problem 2: Making the project fit the process

Do all men have three eyes?

What’s the solution?

Fake it!

Notes

About the author

Rate this article



Gary PolliceWorcester Polytechnic Institute3 May 2004

from The Rational Edge: In this month's column, Gary Pollice discusses the often overlooked necessity of tailoring a software development process to match the people, tools, and project type.

As Ward Cunningham reminded us in his keynote address at XP/Agile Universe 2003, in the software development world there is no such thing as an absolute best practice. Best practices vary according to the project’s context. But how do we define context, and what elements do we need to consider in formulating our own best practices?

In his book Software Engineering: An Object-Oriented Perspective, Eric Braude summarizes the elements of context as the four Ps: People, Process, Project, and Product.1 I would depart from this slightly and discuss context as People, Tools, Project, and Process.

People. Software development does not occur in a vacuum. We build software to satisfy the needs of stakeholders who may be clients, people from other departments within our organization, our managers, or anyone else who cares about the results of our development effort. Communication is a large part of the people component. Some methods, such as Extreme Programming (XP), suggest that a client representative work directly with the development team throughout the project to foster efficient communication. If the client cannot or will not make this commitment, then the project’s communication methods and context must be different. The space that people work in — private offices, cubicles, or open space — and team structure can affect communication and relationships as well.

Tools. The tools and platforms that a team uses represent another component of context. If a team is developing software that will only be used on Microsoft Windows platforms, the tools that team uses to develop, test, and deploy its products will be different from those of an organization that builds software for multiple computing platforms.

Project. Project type is also a key contextual consideration. Developing a new software system involves different challenges, freedoms, and constraints than performing maintenance on, or adding features to, an existing system. The amount of effort you must spend on different activities and language choices will vary by project type.

Matching project and process

Process. Based on my years of experience, process is by far the most problematic component of context — one that managers most often ignore. That might be because every project team follows some sort of process, whether it is formal or informal, standard or highly individual to the particular project, good or bad. However, this is the context element that managers should treat with the greatest care and thoughtfulness as they seek best practices for their particular projects. In the remainder of this article, we’ll examine some common problems that arise when managers do not pay enough attention — or pay the wrong kind of attention — to process. I suspect that most of you will be all too familiar with at least one of these problems.

Problem 1: Using a process “as is”One of the most common process violations is adopting a standard process without modification. This is a recipe for disaster. I’ve heard some managers say, “We’re working with a proven process, so why change it?” However, the issue is not about changing a successful standard process; it is about customizing the process.

The truth is, no standard process is going to work “as is” for your particular project. Moreover, even if you modify a process for your organization, it is highly unlikely that you can apply exactly the same process successfully to one project after another. That is why modern processes encourage you to modify them — first to work within the context of your own organization and then for each project you undertake. This is part of process improvement.

Some organizations make things even worse by trying to follow a standard process to the letter. While working for Rational Software, I was assigned to help an organization adopt Rational Unified Process,® or RUP,® on its first project. When I joined them, the project team was not making much headway. Although they had completed many process artifacts, they had no software to show for all their time and effort, and they were pretty unhappy with RUP. It took me only a few minutes to discover the root of the problem: The managers in this organization had decided that since they had acquired RUP, then, by golly, they were going to do RUP — all of it! Following each instruction and completing each artifact, they figured, would give them the best chance for success.

But that’s not how a process works. If you don’t take time to customize RUP to fit your project (and RUP is explicit about the need for customization), you have almost no chance of success. That is because the process becomes all important, and the project and product become secondary. Fortunately, although it took me awhile to convince the team to make changes, the client and I were able to formulate a version of RUP that fit the project. When the team focused only on the artifacts that would help it reach its business goals, the process helped them move forward quickly.

Another time I was assigned to help a large company adopt Extreme Programming (XP)2 for a project. As Kent Beck explains, XP works best for small development teams — approximately ten developers. But the project under consideration had about seventy developers, many of them contractors. Work was being done at several locations, and clients were distributed around the world. The company was concerned about lack of progress on the project and asked me to analyze the problem. Again, this didn’t take too long. The development manager was determined to use XP, regardless of the project’s size and needs. He had read a lot of success stories about XP and wanted to be on the leading edge of development practice.

The project characteristics made it impossible to follow most XP practices effectively, so the team members ignored what their manager told them and did whatever they thought was right. The problem was, there was no agreement on what was right. Chaos ensued. In this case, despite my efforts to rescue it, the project failed.

In both examples, team members and upper-level managers blamed the process — wrongly — for their problems. In reality, the fault lay with the managers who insisted on imposing an “as is” process without modifying its practices for the project.

Problem 2: Making the project fit the processAnother common process violation involves changing the project to make it fit the process. In such cases the team might have customized the process, but not necessarily for the project at hand. If team members used a modified process successfully on prior projects and grew comfortable with it, they become reluctant to move out of that comfort zone. Sometimes developers who have been successful using XP feel that if the practices don’t work on their current project, then there must be something wrong with the project. “We know the practices work,” they say. “Therefore, we must change the project.”


However, the fact is that every project has a “personality” that we must understand and cannot easily change. If we succeed in changing it, then it’s no longer the same project. Most often people try to modify part of the project so they can use their favorite technique rather than attempting to recast the whole thing. But these efforts rarely work.

For example, there are several excellent ways to specify requirements for a compiler: formal grammars, algorithms, and so on. Yet I’ve heard many discussions about how to specify a compiler with use cases. This happens when people who understand only one method for specifying systems — with use cases — go out of their way to “shoehorn” the compiler’s requirements into use-case form. Typically, they end up either wrapping a use case around the formal description or producing use cases that omit key specifications for the compiler. Either way, the requirements will not produce a working compiler.

Another troubling way managers try to alter projects to fit the process is by removing people who won’t go along with it. They value process over people. This has been true for managers pursuing agile methodologies, even though those methodologies clearly state that you should value people over process. As with RUP, managers should apply elements of methodologies such as XP selectively. People play a major part in determining a project’s personality; they are the most variable characteristic in the project’s context, and the process should be modified to suit them. For example, if pair programming does not feel comfortable or natural for your team members, forcing them to adhere to that work style would be counter-productive.

Do all men have three eyes?Trying to apply the same process for every project is like trying to use a hammer for every construction job. The hammer doesn’t work very well when you have to put a bicycle together. If you try to turn the bicycle into a doghouse (i.e., to modify the project), that will not work, either. What underlies both of these approaches are false assumptions.

If you have ever taken a logic course, you will recognize this syllogism:

All men are mortal.Socrates is a man.Socrates is mortal.

To determine whether the conclusion is sound, you must look carefully at the starting premise. Consider the following:

All men have three eyes.Socrates is a man.Socrates has three eyes.

We know that all men do not have three eyes, so we also know that the conclusion is false.

There are many subtle variations on this basic syllogism, and logicians must scrupulously analyze each premise to determine whether the conclusion is valid. We should take the same care in determining whether a practice is appropriate for a project. If we start by admitting that there are few, if any, universal truths about software development projects, then we can stop trying to make universal assumptions and find other ways of doing things.

What’s the solution?If the problem of process-project mismatch is so common, why aren’t we doing more about it? The most obvious reason is that most managers don’t really want to — until they have felt the full effect of a mismatch. It usually seems easier to use a process as-is or do things we know how to do, whether they’re appropriate or not, than to analyze what we should do and make necessary changes.

Software development is a knowledge-based discipline (or set of disciplines). To succeed you must continually improve your knowledge and apply it. You also have to apply a healthy dose of common sense. Experienced software developers — those who have worked on a broad portfolio of successful applications — have much common sense about how to build software. They have learned how to choose the right process and tools for a project. They have learned fundamental lessons about how to match techniques to the job at hand. Most important, really good developers have learned how to blend their common sense with that of others to build a synergistic project team.


Many organizations realize that they need to find a reasonably standard way of working that still gives individual teams the freedom to get their job done in the most efficient manner. Larger organizations need greater consistency and formality, as well as a wider range of communication methods than smaller organizations; they have more people with different backgrounds who need to understand and use the system. It’s not practical to ask the people in accounting to look at the code if they want to see what your system does.

Fake it!Almost two decades ago, software engineering thought leaders David L. Parnas and Paul C. Clements published a paper called “A Rational Design Process: How and Why to Fake It.”3 This paper had a profound effect on the way I approached software development. By that time I’d worked in several development environments within different companies. I knew what wonderful things you could do with the freedom to create great software, and I also knew how you could get mired in needless process. This paper gave me the key to unlocking a team’s potential in almost any environment.

The premise of the paper is simple. We all want a single process that works — a rational design process. However, we also recognize that we can never follow a process exactly. Things change, people — not machines — are working on the project, and so on. The authors liken the search for the ideal process to the search for the philosopher’s stone. We’re not going to succeed.

So they suggest that, rather than trying to find and follow the ideal process, why not make it look like you did? At the time this was a pretty radical approach, but the concept is quite simple and based on common sense. It works for two primary reasons.

First, it allows you to perfect your artifacts when they are most valuable: after the project is over. As the project proceeds, depending upon its size and formality, the requirements, design, and architecture will change. You can either sink a lot of time into updating, synchronizing, and republishing the associated artifacts, or you can do just enough to make sure the right people know about the changes. Then, if you’re using an iterative development approach, at the end of the project you can add a final iteration to update, organize, and synchronize the artifacts (usually documents) so that maintenance professionals can easily understand the system’s purpose and structure.

Second, it enables you to give process the right degree of emphasis. Most people who have a negative view of process are reacting to the amount of “useless” work it entails. The agile movement represents an effort to eliminate such work. But you must maintain a balance among the important contextual elements in your project — People, Tools, Project, and Process — so that the work can continue for future releases. Faking it provides a way to achieve that balance.

I urge you to read the Parnas and Clements paper. I have all of my students read it, and it might have a profound effect on you, too. If you can understand the singular formula for success that it promotes, then you will be well on your way to a long, successful career in software engineering.

Notes1Eric J. Braude, Software Engineering: An Object-Oriented Perspective. John Wiley & Sons, 2001.

2 See Kent Beck, Extreme Programming Explained (Addison-Wesley, 1999) and the “Manifesto for Agile Software Development” at http://agilemanifesto.org/

3 Published in IEEE Transactions on Software Engineering, February 1986.


About the authorGary Pollice is a Professor of Practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and M.S. in computer science.



Comments?




Search for: within




Book review: JavaServer Pages, second edition

Contents:

About the author

Rate this article



David WarnerSoftware engineer6 May 2004

from The Rational Edge: Warner reviews a book that covers topics such as basic Java coding, the JSP standard tag library, and database access, and supplements them with material for advanced practitioners on XML, advanced bean topics, servlets, creating tag libraries, and controllers such as Struts.

by Larne PekowskyAddison-Wesley, 2003ISBN: 0321150791 Cover price: US$44.99368 pages

This second edition of JavaServer Pages offers an excellent introduction to using JSPs to build dynamically driven Web pages. The book covers topics appropriate for both novices and experienced users, and both amateurs and professionals. It is scoped for both Web designers proficient with HTML and Java programmers hoping to gain insight into Web development. In addition to covering topics such as the JSP standard tag library and database access, the book includes a chapter on basic Java coding for beginners. More advanced practitioners will find material on topics such as creating your own tag libraries and Struts, a technology for building on top of JSPs. However, I do have one caveat for the novices: To get full value from JSPs, you will need more Java knowledge than this book provides.

JavaServer Pages opens with an introduction providing "A Brief History of the Web"; much of this will be old hat to most readers, but the introduction also includes an excellent overview of other technologies that you can use to create dynamically driven Web sites. This section provides enough context to help readers understand the motivations and decisions behind the JSP specification design.

After the introduction, Pekowsky dives straight into JSP basics with a chapter on "Simple JSPs." Like most subsequent chapters, the examples here center around creating a fictional Web site called Java News Today, which features "compelling, up-to-the-minute news" about "all things Java." This example site provides an excellent mechanism for explaining how to apply different techniques in a real-world scenario. It also provides enough guidance for readers to implement the Java News Today site themselves as they move from chapter to chapter, building on tips and techniques from previous chapters as they proceed. This opening chapter, for example, introduces readers to basic JSP tags used in the example Web site.

The next chapter covers the heart of JSPs: beans. Using an example, Pekowsky shows what a bean is, how to create one, and how to access that bean from a JSP page. Then, he uses beans to upgrade the Java News Today Web site.

After touching on the standard tag library in previous chapters, Pekowsky finally introduces the library in Chapter Four, which covers several important techniques, including:

Book review: JavaServer Pages, second edition

● Assigning dynamic attributes in tags.● Displaying expressions.● Formatting output.● Detecting browsers.● Repeating a section of a page.

The book provides more detail about these standard tags and many more in an excellent appendix. This volume can serve as a reference after you've learned about JSPs — or as a tutorial for those with minimal tag knowledge.

Pekowsky discusses another topic of interest to hobbyist developers: databases. Dynamic Web pages are of little use without a back end full of data to represent, and this book explains how to integrate database calls into JSP pages. First it discusses basic SQL syntax, and then how to leverage the standard tag library for reading and writing to a database directly from a JSP. It also covers populating JavaBeans from the database. In addition, many pages focus on adding database support to the Java News Today example Web site. Unfortunately, I think novice users will struggle with SQL even after reading these chapters; the few pages of SQL syntax they provide will not help readers learn much about this complex topic.

Pekowsky also could have devoted more space to helping novice users set up a Web server and database server. These are essential steps for using JSPs, but they have been relegated to the CD included with the book. Also, given the database server that's on the CD, I am not sure novice SQL users will be comfortable venturing beyond the book's examples and trying variations on their own. Although teaching readers how to use a Web server or database server effectively might be outside the scope of this book, these skills are necessary for getting JSPs to display database-driven content in the way the book describes. But this is a small complaint — in truth, abundant information on these topics is available online.

Chapters on more advanced topics are devoted to XML, beans, servlets, controllers such as Struts, and creating tag libraries. Novice programmers will be interested in a chapter devoted to Java programming. All chapters cover their topics well, but a lot of this material is in the "nice to know" category. This is not really a criticism: Many readers will come back to these later chapters as their JSP knowledge grows, and the book's value extends beyond an initial reading.

The book contains another useful appendix: This one offers advice on configuring a Web application. Although it provides enough information to get readers up and running, it does not supply enough to help novices through the frustration of trying to configure a Web application.

Despite the few shortcomings I've mentioned, this book provides a wonderful jumpstart for the novice JSP user as well as enough information on advanced topics to keep the gurus coming back to it. Although it is skimpy on some technical details, the book more than makes up for this with a thoughtful, detailed analysis of all the important concepts and techniques of modern JSP programming.

About the authorDavid Warner currently works as a software engineer for a large, privately-held corporation. He develops Web-based applications that utilize Java, Web Services, and Oracle databases. David is a graduate of Washington University in Saint Louis, where he earned both a B.S. and an M.S. in computer science.


Search for: within




Book review: The Seven-Day Weekend: Changing the Way Work Works

Contents:Transforming a workplace into a democracy

A vision for society

About the author

Rate this article



Manjeri R. DharmarajanIBM11 May 2004

from The Rational Edge: Manjeri Dharmarajan reviews a book describing a management philosophy for finding a work/life balance and creating a sustainable organization.

by Ricardo SemlerCentury, 2003ISBN: 0-7126-2383-3Cover price: US $22.95276 pages

In his best-selling book Maverick!, Brazilian businessman Ricardo Semler describes how he transformed his father's company, Semco, into a non-traditional workplace. In this sequel to that book, he traces Semco's foray into high-technology and how the company grew to become an organization with multiple businesses, 3,000 employees, and $160 million in revenue. This time, however, he focuses on how managers can help employees achieve a healthy work/life balance in order to create a sustainable company.

As Semler warns readers at the outset, his book questions everything we know about how to run a company. He turns most of our cherished notions about an effective workplace upside down, suggesting outrageous alternatives, and then tells us how these ideas have actually worked at Semco. His accounts will make even the most progressive managers shake their heads in disbelief.

Semler's main argument centers on the idea that our traditional weekend disappeared a long time ago. In times past, weekends allowed us time to be idle, think, and find a work/life balance. Now, in the age of laptops and mobile phones, we spend our weekends either working or thinking about work. We fill even our leisure time with things we must do, adhering to rigid schedules and leaving no time to relax and do nothing. This has created great stress for all of us.

As an alternative, Semler proposes a "seven-day weekend" — a completely flexible schedule that can reduce stress and restore balance to our lives by allowing us to decide each day how to divide our time between our jobs and personal lives. We should learn how to go to the movies on Monday afternoon or go to a park and feed ducks with our children. By having the flexibility to work and play when we want, he argues, we can extend our "reservoir of talent" and live a richer, more contented life. This is critical for us as individuals. As Semler reminds us, life expectancy is increasing and may soon exceed 100 years; many of us will continue to work well past the traditional retirement age. Success and money are only distant relatives, he reminds us.

Helping employees achieve a healthy work/life balance is also critical for businesses. Employees with balanced lives are happier and more productive. Our current workplaces, Semler contends, operate like militaristic boarding schools, treating employees like adolescents.


The military structure at traditional companies consolidates power in a few hands, creates a chain of command that eliminates uncertainty, and makes the rules of behaviour clear to all. But it also stifles freedom and creativity.

If democratic principles are good for other parts of our society, Semler argues, shouldn't they be good for the workplace? Why shouldn't we treat employees like adults and trust them to do the right thing? And this is what he did as head of Semco.

Transforming a workplace into a democracySemler describes several steps he took to usher in democracy at his workplace:

● Give up control (e.g., no organization charts, dress code, fixed offices or policies; complete flex-time for all workers, including those on assembly lines).

● Share information (e.g., make all salaries public and invite everyone to attend board meetings; Semler even shares profit calculations with customers).

● Encourage self-management (i.e., force people to think independently, question everything, and solve their own problems; manage by doing nothing yourself when problems arise).

● Discourage uniformity (e.g., rotate jobs, allow extreme flexibility in work and pay).

Semler describes numerous incidents that illustrate how these principles led to Semco's success. For example, at one point he discovered that a particular division was spending too much money on supplies. Rather than limiting supplies, managers let the employees deal with the problem themselves. They set up a competition: The group that used the most supplies had to buy coffee for everybody else. Within a short time, the group that lost came up with a plan to limit its use of supplies. Other groups adopted the same plan, and the company reduced supply consumption by 21 percent overall.

The most critical incident happened when Brazil suffered a recession in the early 1990s. Workers met to plan Semco's future. They tried everything to avert layoffs and closures: selling spare parts on the road; cancelling maintenance, security, and cleaning contracts, and doing all the work themselves; assigning everyone a shift to drive a company truck or work in the company kitchen.

Because Semco managers had been sharing information with employees all along (every check required a management and union signature), everybody already knew the numbers. And the employees reached a consensus: They voted to shut down a factory and let 200 people go, with generous severance packages. Although Semler opposed this move, worrying about the emotional shock of padlocking a factory, and believing that if the company could hang on for a few more months, things might improve. But he was overruled, so he complied with the workers' vote.

In some instances, of course, democratic decision making can lead to problems. ERM, an important client, became upset when Semco missed a project deadline. A junior engineer had sent samples to a lab that was not certified, and the lab had made a classification mistake that resulted in a delay. Semco's UK partners demanded that heads roll and controls be put in place to prevent a recurrence. But Semler decided that the best approach was to do nothing, claiming that the situation would remedy itself. After much persuasion, Semco managers convinced their partners and the client that people learn from mistakes; employees would exert enough peer pressure to ensure that the same mistake would not recur. Better for Semco to screw up once or twice a year, Semler reasoned, than curb the energy, creativity, and drive that freedom inspires.

A vision for societyThis is one of the most original and thought-provoking books I have ever read. Although the language is accessible and the colorful stories about Semco make for easy reading, it took me a long time to read the book, as I was constantly stopping to ponder another of Semler's "crazy" concepts. Also, as Semler is a big believer in serendipity, he disdains structure and advocates a rambling route through life. This book reflects that belief: Ideas, stories, and observations are strewn through the book seemingly at random.

Although for some it may provoke frustration, I recommend this book to both managers and non-managers alike. As I see it, the challenge for all of us is how to apply Semler's ideas and beliefs in our present settings. Not all of us are lucky enough to


inherit a company, and sharing salary information in our current jobs would probably get us fired. However, I will continue to look for ways to follow some of Semler's suggestions and bring more freedom to my workplace. I believe that doing so will make me and my co-workers happier and more productive.

In addition, like Semler, I think this freedom can make a difference in our society. Encouraging people to take risks and be comfortable with change will transform not only the way we work, but also the way we live. As Semler argues, it can take us from the knowledge revolution to the wisdom revolution.

About the authorManjeri R. Dharmarajan currently manages the IBM Rational PurifyPlus development team in Bangalore, India. He has fifteen years of experience in software development and has spent the last five years as a manager. He did take his children to the movies last Thursday afternoon.



Comments?



Documents

© Copyright IBM Corporation 2004 ......developerWorks > Rational > Issue contents Editor's notes —May 2004 For more than two decades, the Rational organization, now part of IBM,