project management rup

8/8/2019 Project Management RUP

1/57

Process Improvement SeriesCCGROUP

Corporate Consulting Group

Project Managementas in Rational Unified Process

Farid ALVI


2/57

Process Improvement SeriesCCGroup

Agenda

9:00 Opening Address

9:05 Project Management

9:30 Project Management Office

10:00 Rational Unified Process Life Cycle

11:00 Tea Break

11:15 RUP Life Cycle, continued

13:00 Lunch Break

14:00 Project Management: Hands on exercises with tools & templates

15:30 Tea Break

16:00 Hands on exercises, continued


3/57


Disclaimer

The ideas presented here may seemchallenging to the current understanding.

.. Kindly bear it with us.

All information provided will be backed up

with testimonials, if required.


4/57


What is a project ?


5/57


What is a project ?

A project is a temporary endeavor undertaken to

create a unique product or service.Temporary means that every project has a definite beginning and a definite

ending.

Unique means that the product or service is different in some distinguishing

way from all similar products and services.

Projects are often critical components of theperforming organizations' business strategy

Projects are performed by people, constrained bylimited resources, and planned, executed, andcontrolled.


6/57


Project Manager


7/57


Project Management Project Management is the art of:balancing competing objectives,

managing risk, andovercoming constraints

to successfully deliver a product which meets the needs of both customers (thepayers of bills) and the users.

The purpose of Project Management is:To provide a framework for managing projects.

To provide practical guidelines for planning, staffing, executing, and monitoringprojects.

To provide a framework for managing risk.

Important aspects of an iterative development process:Risk management

Planning an iterative project, through the lifecycle and for a particular iteration

Monitoring progress of an iterative project, metrics


8/57


Benefits of Putting aProject Management Office in Place

A project management office (PMO) is an organizationalcommitment to sound project management principles.

Microsoft

werPoint Presentati


9/57


RUP Life Cycle


10/57


: ModelRUP Life Cycle


11/57


Life CycleObjective Milestone

Life cyclearchitecture milestone

Initial OperationalCapability milestone

Productrelease

From a management perspective, the lifecycle of the Rational Unified Process

(RUP) is decomposed over time into four sequential phases, each concludedby a major milestone;

each phase is essentially a span of time between two major milestones.

at each phase-end an assessment is performed to determine whether theobjectives of the phase have been met.

A satisfactory assessment allows the project to move to the next phase.

: Phase MilestonesRUP Life Cycle


12/57


A project using iterative development has a lifecycle consisting of several iterations. Aniteration incorporates a loosely sequential set of disciplines, in various proportionsdepending on where in the development cycle the iteration is located.

Iterations in the inception and elaboration phases focus on management, requirements,and design activities; iterations in the construction phase focus on design, implementation,and test; and iterations in the transition phase focus on test and deployment.

Iterations should be managed in a timeboxedfashion, that is, the schedule for an iterationshould be regarded as fixed, and the scope of the iteration's content actively managed to

meet that schedule.

RUP Life Cycle: Iterative Development


13/57


RUP Life Cycle: Planning the Phases

A typical initial development cycle for a medium-sized project should

anticipate the following distribution between efforts and schedule:

10%50 %30 %10 %Schedule

10%65 %20 %~5 %Effort

TransitionConstructionElaborationInception


14/57


RUP Life Cycle: Planning the Iterations

The first iteration of a new product is usually the hardest. There are many newaspects a first iteration must achieve besides producing a product: Forexample,

putting in place the process, team-building, understanding a new domain,

becoming familiar with new tools, and so on.


15/57


RUP Life Cycle: Evolution Cycles

One pass through the four phases is a development cycle; each pass throughthe four phases produces a generation of the product. Unless the product"dies," it will evolve into its next generation by repeating the same sequence ofinception, elaboration, construction and transition phases, but this time with adifferent emphasis on the various phases. These subsequent cycles are called

evolution cycles. As the product goes through several cycles, newgenerations are produced.


16/57


Risk


17/57


Risk: Classes and Attributes

Risk is a variable that, within its normal distribution, can take a value thatendangers or eliminates success for a project.

In plain terms, a risk is whatever may stand in our way to success, and iscurrently unknown or uncertain.

Success is meeting the entire set of all requirements and constraints held asproject expectations by those in power.

We can further qualify risks as direct or indirect:

Direct risk: a risk that the project has a large degree of control over

Indirect risk: a risk with little or no project control

Attributes of a risks:

Probability of occurrence Severity, Impact on the project

The two can often be combined in a single risk magnitude indicator:High, Significant, Moderate, Minor, Low.


18/57


Risk: Management

The key idea in risk management is not to wait passively until a risk materializesand becomes a problem or kills the project, but to decide what to do with it. For

each perceived risk you decide in advance what you are going to do.There are 3 main possible routes:

Risk avoidance: reorganize the project so that it cannot be affected by thatrisk.

Risk transfer: reorganize the project so that someone or something elsebears the risk (customer, vendor, bank, another element, etc.)

Risk acceptance: decide to live with the risk as a contingency. Monitor therisk symptom, and decide on a contingency plan of what to do if the riskemerges.

When accepting a risk, you should do 2 things: Risk mitigation: take some immediate, pro-active step to reduce the

probability or the impact of the risk

Define a contingency plan: what course of action you should take if the riskbecome an actual problem.


19/57


RUP Project Management: Framework


20/57





21/57




22/57


Identify and Assess Risks

Identify Potential Risks

To make an inventory of what can go wrong with the project

Analyze and Prioritize RisksTo combine similar risks (to reduce the size of the risk list).

To rank the risks in terms of their impact on the project

Identify Risk Avoidance and Mitigation StrategiesTo reorganize the project to eliminate risks

To develop plans to mitigate risks, that is to reduce impact of these risks

Identify Risk Contingency StrategiesTo develop alternate plans

Revisit Risks during and at the end of an Iteration

To ensure that the risk list is kept current throughout the project

Microsoft Excel

Worksheet

Risk Plan


23/57


Develop Business Case

Describe the Product To create a concise definition of the product to be built.

Define the Business Context To define the environment in which the product will be deployed

To define the market for the product

Define the Product Objectives

To clearly state the product objectives

Develop the Financial Forecast To develop projections of project cost and revenues

Describe the Project ConstraintsTo define the constraints on the project

Describe OptionsTo present some options for the product and the project, and describe their

effect on the financial forecast and project constraints

Microsoft WordDocument

ProjectCharter


24/57


Initiate a Project

Assign Project Review Authority (PRA)The Project Review Authority (PRA) is an organizational entity responsible

for overseeing the project

Assign project managerA project manager with appropriate skills and experience is identified and

approved by the project board

Assign project planning teamThe planning team is identified, approved and assigned by the project

manager

Approve product acceptance criteriaTo define some objective criteria that will be used by the customer to

determine when the artifacts delivered by the project are acceptable


25/57


26/57


Plan Phases and Iterations Estimate Project To estimate the magnitude of work required to deliver the project.

To select the optimal schedule that satisfies project constraints

Define Project Phase Milestones and their goals To define the points at which project progress is formally assessed. To allocate estimated effort and costs to each phase

To define the criteria by which phases are assessed

Define Number, Length, and Objectives of Iterations Within

Phases To determine how many iterations will be planned for each project phase. To determine the relative allocation of work across iterations.

To determine the objectives for each iteration

Refine Milestones Dates and Scope

To refine estimates based on the information available at the end of inception phase

Determine Project Resource Requirements To define the numbers / types of resources required for this project, allocated by phase/iteration

Develop Project Close-Out Plan To develop the plan for an orderly termination of the project


27/57


Define Project Organization and Staffing

Define Project Organization

To define the organizational structure of the project in terms of positions,

teams, responsibilities and hierarchy

Define Staffing RequirementsTo define the numbers, type (skills, domain), experience and caliber of staff

required for the project


28/57


Define Monitoring & Control Processes

Define project "indicators Project "indicators" are pieces of project information that give a picture of the health of

the project's progress against the development plan

Define sources for project indicators The projector indicators, in most cases, will be consolidated project measures

calculated from more granular primitive metrics

Define procedure for team status reporting To describe the process for booking time against work packages, reporting the

completion of tasks, achievement of project milestones and reporting of issues

Define procedure & thresholds for corrective action

To define threshold (or trigger) values/conditions for each of the defined projectindicators

Define procedure for project status reporting To describe, when and where scheduled and un-scheduled PRA Reviews will occur

CC


29/57


Compile Development Plan

Develop DP project management content

Early in the Inception Phase, the information included will be fairly high-leveland coarse grained

By the end of the Elaboration Phase the content of the SDP should be very

detailed

Develop enclosed project management plansTo develop other plans covering metrics, requirements, risk, problem/change

management etc.

To ensure these associated plans have been prepared, and that they are

properly referenced and attached to the SDP document

Coordinate development of supporting plansTo integrate plans describing project standards and how various supporting

processes (for example, configuration management) are to be handled

Microsoft Word

Document

MPP File

DevelopmentPlan

DevelopmentSchedule

CC


30/57



CC


31/57


Develop Other PlansDevelop Risk Management PlanDefine risk management procedure & tools

Create initial risk list

Assign risk management team

Decide strategies for managing top 10 risks

Define risk indicators for top 10 risks

Set schedule for risk reporting and reviews

Develop Measurement PlanDefine the Primary Management Goals

Validate the Goals

Define the Subgoals

Identify the Metrics Required to Satisfy the Subgoals

Identify the Primitive Metrics Needed to Compute the Metrics

Write the Measurement Plan

Evaluate the Measurement Plan

Put in Place the Collection Mechanisms

Microsoft ExcelWorksheetRisk Plan

CC


32/57


Develop Other Plans

Develop Quality Assurance Plan

Ensure Quality Objectives are Defined for the Project Define Quality Assurance Roles and Responsibilities

Coordinate with Developers of Referenced Plans

Define Quality Assurance Tasks and Schedule

Develop Problem Resolution Plan Define Problem Resolution Procedure(s)

Select Tracking Tools and Techniques

Assign Problem Management Team(s)

Set Schedule for Problem Management Activities

Develop Product Acceptance Plan Define customer and project responsibilities

Document the product acceptance criteria

Identify artifacts and evaluation methods

Identify Required Resources

Define product acceptance schedule and problem resolution process

CC


33/57



CC


34/57


Develop Iteration Plan

Determine the Iteration Scope

To select a set of use cases or scenarios to be considered during theiteration.To select a set of non-functional requirements which must be handled during

the iteration

Define Iteration Evaluation CriteriaTo define the evaluation criteria for the iteration results / products

Define Iteration ActivitiesTo define the set of activities to be performed during iteration, Based upon

the goals of the iteration

Assign ResponsibilitiesTo assign the identified activities to project team members

CC


35/57


Acquire Staff

Map Staff Skills to Roles

Form Teams

Train Project Staff

P I S iCC


36/57


Initiate Iteration

Iteration Kick-off Meeting

Assign staff to work packages

Acquire and assign non-personnel resources

Issue work orders

P I t S iCC


37/57


Assess Iteration

Collect Metrics

Assess the Results of the Iteration

Consider External Change

Examine the Evaluation Criteria

Create Change Requests

Process Improvement SeriesCC


38/57


Prepare for Phase Close Out

Check Status of Required Artifacts

Schedule Configuration Audit

Conduct a Phase Post-Mortem Review

Distribute Artifacts to Stakeholders

Complete Lifecycle Milestone Review Action Items

Process Improvement SeriesCC


39/57

Process Improvement SeriesGroup

Prepare for Project Close Out

Update Project Close-Out Plan and Schedule Activities

Schedule Final Configuration Audit

Conduct a Project Post-Mortem Review

Complete Acceptance Action Items

Close Out the Project

Process Improvement SeriesCCG


40/57



Process Improvement SeriesCCG


41/57


Monitor and Report Project Status

Capture work status

Derive progress indicators

Derive quality indicators

Evaluate indicators vs. plans

Prepare Status Assessment / Report



42/57


Schedule and Assign Work

Allocate Change Request to an Iteration

Assign Responsibility

Describe Work and Expected Outputs

Budget Effort and other Resources

Set Schedule

Re-plan

Issue Work Order



43/57

pGroup

Handle Exceptions and Problems

Evaluate exceptions and problems

Determine appropriate corrective actions

Issue Change Requests and/or Work Orders



44/57

pGroup

RUP Project Management: Workflow



45/57

p





46/57

Workflow Detail: Conceive New Project On the basis of the initial Vision,

risks are assessed and aneconomic analysis, the Business

Case, is produced. If the ProjectApproval Review finds thesesatisfactory, the project is formallyset and given limited sanction (andbudget) to begin a completeplanning effort. Note that, bydefinition, this initial Vision iscreated outside the project (perhapsby a separate business modeling orsystems engineering activity), not bythe subsequent Develop Visionwithin the project. This latter activityadds substance to the initial Vision,

validates and refines it. The projectbegins with this workflow detail, soany artifacts that are input mustalready exist - i.e. the project musthave some organizational andbusiness context.



47/57

Workflow Detail: Evaluate Project Scope and Risk

The purpose of this workflow detailis to reappraise the project'sintended capabilities and

characteristics, and the risksassociated with achieving them. Asthe capabilities and risks are betterunderstood, the business caseshould be updated, to ensure thatthe project continues to be worthinvesting in, in its current form, or ifa change in direction is needed



48/57

Workflow Detail: Plan the Project

The major effort in creating theseartifacts comes early in theinception phase; thereafter, when

this workflow detail is invoked at thebeginning of each iteration, it is torevise the Development Plan (andits enclosures) on the basis of theprevious iteration's experience and

the Iteration Plan for the next. TheProject Manager will also collate allother contributions to theDevelopment Plan and assemblethem in Activity: CompileDevelopment Plan

All enclosed plans and sections ofthe Development Plan should beevaluated through internalwalkthroughs and reviews beforethe Project Planning Review occurs



49/57

Workflow Detail: Plan for Iteration / Next Iteration

The Project Manager should workclosely with the Architect to definethe iteration's contents. The Iteration

Plan should be evaluated internally,through walkthrough and review,before being presented for theIteration Plan Review, in particular:

to assess the clarity of expression

of the evaluation criteria for theiteration

to reach agreement internally thatthe planned artifacts can be builtwith the effort and time available

to ensure that the results of theiteration will be testable orotherwise demonstrable; that is, theiteration will have a tangibleoutcome



50/57

Workflow Detail: Manage Iteration

This workflow detail contains theactivities that begin, end and reviewan iteration. The purpose is to

acquire the necessary resources toperform the iteration (Acquire Staffand Initiate Iteration), allocate thework to be done and finally, toassess the results of the iteration.

An iteration concludes with anIteration Acceptance Review whichdetermines, from the IterationAssessment, whether the objectivesof the iteration were met.



51/57

Workflow Detail: Monitor & Control Project This workflow detail captures the daily,

continuing, work of the Project Manager,covering:

dealing with change requests that havebeen sanctioned by the Change ControlManager, and scheduling these for thecurrent or future iterations;

continuously monitoring the project interms of active risks and objectivemeasurements of progress and quality;

regular reporting of project status, in theStatus Assessment, to the ProjectReview Authority (PRA), which is theorganizational entity to which the ProjectManager is accountable;

dealing with issues and problems as they

are discovered, through the Activity:Monitor Project Status or otherwise, anddriving these to closure according to theArtifact: Problem Resolution Plan. Thismay require that Change Requests beissued for work that cannot be authorizedby the Project Manager alone.

Microsoft Excel

Worksheet

ChangeRequest



52/57

Workflow Detail: Close Out Phase In this workflow detail, the Project

Manager brings the phase to closure byensuring that:

all major issues from the previous iteration

are resolved the state of all artifacts is known (through

configuration audit)

required artifacts have been distributed tostakeholders

any deployment (for example, installation,

transition, training), problems are addressed

the project's finances are settled, if thecurrent contract is ending (with the intent tore-contract for the next phase)

A final phase Status Assessment is preparedfor the Lifecycle Milestone Review, at whichpoint the phase artifacts are reviewed and, ifthe project state is satisfactory, sanction isgiven to proceed to the next phase



53/57

Workflow Detail: Close Out Project

In this workflow detail, the ProjectManager readies the project for

termination

A final Status Assessment is prepared forthe Project Acceptance Review , which, ifsuccessful, marks the point at which thecustomer formally accepts ownership of

the product. The Project Manager thencompletes the close-out of the project bydisposing of the remaining assets andreassigning the remaining staff



54/57

References

The Rational Unified Process An Introduction. Addison-Wesley. PhilippeKruchten 1998.

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

A Quantitative Approach to Software ManagementThe AMI Handbook.Addison Wesley Longman. K. Pulford, A. Kuntzmann-Combelles, and S.Shirlaw 1995.

Software Risk Management: Principles and Practices, IEEE Software, Jan.1991, IEEE, pp.32-41. Barry W. Boehm 1991.

Object SolutionsManaging the Object-Oriented Project. Addison WesleyLongman. Grady Booch 1995.

Software Leadership. Addison-Wesley Longman. Murray Cantor 2001.

Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6,Pittsburgh, PA, SEI, June 1993, 24p. Marvin J. Carr, et al. 1993.

Software Engineering Risk Analysis and Management. New York, NY:McGraw-Hill. Robert Charette 1989.



55/57

References continued

Making Hard Decisions: An Introduction to Decision Analysis. DuxburyPress. Robert T. Clemen 1996.

Improving Software Economics in the Aerospace and Defense Industry,Technical Paper TP-46, Santa Clara, CA, Rational Software Corporation, 1995.Michael T. Devlin and Walker E. Royce.

Introduction to Simulation and Risk Analysis. Upper Saddle River, NJ:Prentice-Hall. James R. Evans and David L. Olson 1998.

"Risk Management for Software Project," IEEE Software, 11 (3), May 1994,pp.57-67 Richard Fairley 1994.

Principles of Software Engineering Management. Harlow, England: AddisonWesley Longman. Tom Gilb 1988.

Object-Oriented Metrics, Measures of Complexity. Prentice Hall PTR. Brian

Henderson-Sellers 1996. Assessment and Control of Software Risks. Yourdon Press. Capers Jones

1994.

Software Engineering Risk Management. Los Alamitos, CA: IEEE ComputerSociety Press. Dale Karolak 1996.



56/57

References continued

Rapid Development. Redmond, WA: Microsoft Press. Steve McConnell 1996.

User's Guide for Microsoft Project 98, Microsoft Corporation, 1997.

How to Run Successful Projects. New York, NY: Prentice-Hall International.Fergus O'Connell 1994.

A Guide to the Project Management Body of Knowledge. The ProjectManagement Institute: Newton Square, PA, 19073-3299, USA. 1996.

Measures for Excellence: Reliable Software On Time, Within Budget. Yourdon

Press. Lawrence Putnam & Ware Myers 1992.

Software Project Management: A Unified Framework. Addison WesleyLongman. Walker Royce 1998.

Quantitative Risk Analysis: A Guide to Monte Carlo Simulation Modeling. JohnWiley & Sons. David Vose 1996.

Object-Oriented Design Measurement. John Wiley & Sons, Inc. Scott Whitmire1997.

A metrics suite for object-oriented design, IEEE Transactions on SoftwareEngineering, 20(6), 1994. Chidamber and Kemerer 1994.



57/57

Corporate Consulting Group

B-56, Block 5, Karachi 75300, Pakistan.Phone 092 21 498 6949, Email: [email protected]

project management rup

Documents