Distributed Project Delivery Modelbased on Rational Unified Process

Introductory Presentation

© Soft Format, 2006

IntroductionThe purpose of this presentation is to provide a top-level glance on the project delivery model.

We can outline the following objectives:

to provide a general vision on the project lifecycle in accordance with Soft Format methodology;

to discuss a basic strategy of our cooperation between Soft Format and Customer within the specific project;

to form the background for subsequent adjustment of the project model for customer.

This workshop is a first meeting of a kind in the scope of the Relationship Management business process and should be held periodically in the course of our cooperation to adjust the project delivery model and assure the highest possible efficiency of the IT alliance.

The next slides provide information on both contractual and development models, introducing processes into which the parties are involved while working on projects implementation, and don’t cover the relationship management processes which are the subject for the specific discussion.

* - formalization level for all described processes and artifacts is subject to the Customer ’s preferences and requirements.

Relationship Management Model: General View

Soliciting the relationship

Project Life Cycle

Project Disciplines

Project Phases

Inception phase

Elaboration phase

Construction Phase

Transition Phase

Project Team Structure

Customer -Related view on the project phases

Plan of the workshop

Explanation to DiagramsThe provided schemes are the generalized representation of the project delivery model within the complex Relationship Management Model and due to their flexibility are subject to every Customer 's needs and requirements.

The diagrams are developed using the Business Processes modeling suite of Rational Rose and applying the UML notation rules for business processes modeling. For easier understanding of the diagrams please consider the following legend:

Business Activity - an activity performed by one of the parties within the business process

Business Transaction - an activity jointly performed by both parties within the business process and results in a certain decision made or validated

Business Entity - represents a significant and persistent piece of information that is manipulated by business actors and business workers.

Artifact - a physical piece of information that is used or produced by a software development process.

Milestone - a decision-making event in the project

Shows a sequence of activities in the process

Associates certain artifacts or business entities with certain activities

Rela

tionsh

ip M

an

ag

em

ent

Dia

gra

mSoliciting the Relationship

Soliciting the Contract

Relationship Established

YesNo

Partnership Opportunity Cancelled

Contact Initiated

Contract Won

YesNo

Opportunity Lost

Signing the Contract

Contract Signed

Yes

NoContract

Lost

Service Delivery Management

Contract Administration

Project Performed

Yes

No

Partnership Contract Close-Out

Partnership End

Managing the Relationship

Rela

tionsh

ip S

olic

itin

g

Dia

gra

m

Prospect Sales Qualification

Develop Business Vision

Shared Vision obtained

Relationship Development Plan

Planning relationship development

Establish the Contact

Prospect Qualified

Prospect Marketing Qualification

Prospect Identified

Vendor Pre-Identified

General Information about SF

Identify the Perspectives

From Soft Format L : Business Vision

Justify Business Vision Customer Justified : Business Vision

Develop Business CaseFrom Soft Format L :

Business CaseJustify Business Case Customer Justified :

Business Case

Negotiate Business CasePartnership Opportunity

Identified

Adjust Business Process Model to the Customer Specific Requirements

From Soft Format L: Partnership

Requirements

From the Customer : Partnership Requirements

Amend Business Process Model

Adjusted and validated : Business Process Model

Develop Relationship Basis

Relationship Basis Developed

Developing the Relationship

Align Business/Production ProcessesAlign Legal ModelDefine Communication ModelDefine Communication Management ProcessesAlign Other Business Specific ProcessesDefine the Risk Management Approach

Soft Format Joint Processes Customer

Relationship Basis Developed

Prepare Organizational Environment

Prepare Organizational Environment

Prepared for Use : Business Process

Model

Prepared for Use : Business Process Model

Verify Organizational Environment Preparation

Organizational Environment Prepared

Perform Pilot Projects Pilot Projects Model Manage Pilot Projects

Test RelationshipPilot Project

Assessment : Record

Assess Relationship Efficiency

Partnership Identified

Formalize PartnershipPartnership Agreement

Plan RelationshipRelationship

Management Plan

Relationship Obtained

Soft Format Joint Processes Customer

Rela

tion

ship

Solic

itin

g

Dia

gra

m C

on

tin

ued

ProjectIn accordance with PMBOK, project can be defined in terms of its distinctive characteristics:

“project is a temporary endeavour, undertaken to create a unique product or service”

Temporary means that each project has its start and its end.

Unique means that the product or service is different in some distinguishing way from the other product or service.

Because the product of each project is unique, each project involve a degree of uncertainty and should be progressively elaborated.

Iteration incorporates a loosely sequential set of activities in different disciplines and business processes, in various proportions depending on where in the development cycle the iteration is located.

Organizations performing projects will usually divide each project into several project phases and iterations to improve each management control and provide for links to the ongoing operations of the performing organizations.

Collectively, the project phases are known as the project life cycle.

IterationIteration incorporates a loosely sequential set of activities in business modelling, requirements, analysis and design, implementation, test, and deployment, in various proportions depending on where in the development cycle the iteration is located.

All projects have a set of risks involved. The earlier in the lifecycle you can verify that you've avoided a risk, the more accurate you can make your plans. Many risks are not even discovered until you've attempted to integrate the system. You will never be able to predict all risks regardless of how experienced the development team is.

In the Rational Unified Process, the interactive approach is very controlled; iterations are planned in number, duration, and objective. The tasks and responsibilities of the participants are defined. Objective measures of progress are captured. Some rework does take place from one iteration to the next, but this, too, is carefully controlled.

An iterative approach is generally superior to a linear or waterfall approach for many different reasons:

• Risks are mitigated earlier, because elements are integrated progressively. • Changing requirements and tactics are accommodated.  • Improving and refining the product is facilitated, resulting in a more robust

product. • Organizations can learn from this approach and improve their process.  • An iterative lifecycle provides management with a way of making tactical changes

to the product.• Reusability is increased.

Project CycleAs you see from the diagram, project life cycle encompasses 4 phases, such as inception phase, Elaboration Phase, Construction Phase and Transition phase.

Each project phase is marked by completion of one or more deliverables.

A deliverable is a tangible, verifiable work product (artefact) such as, e.g. Software Architecture, Software Prototype, Software Release.

The conclusion of a project phase is generally marked by a review of both key deliverables and project performance, to:

• determine if the project should continue into the next phase;• detect and correct errors cost-effectively.

Inception Phase

Inception Phase Objectives:

•To define project requirements;•To establish project software scope;•To assess project feasibility, identify risks and constraints for the project;•To identify project feasibility and decide on the project execution.

Inception Phase Essential Activities:

• To obtain stakeholders’ requests to the project and develop the product vision. Level of requirements formalization can vary depending on the project scope and Customer ’s preferences e.g. informal letter, RFP, etc. but must define what is intended to be in the product and what is not.

• To perform the estimation of the project on the basis of the shared vision negotiated with the Customer . • To develop, negotiate (adjust) and agree on the Project Business Case, which provides the justification for

the project; estimates potential risks; establishes its possible constraints and contains certain assumption about the project. It provides information on the project's economic worth and is used to determine whether the project should move ahead.

• To identify project feasibility on the basis of the agreed Business Case.

Inception Phase Essential Artifacts:

•Request for proposal (RFP);•Product Vision;•Business Case.

The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.  The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

Elaboration Phase

• To sign the contract and kick-off the project;• To specify the requirements to ensure that they are clear defined and agreed.• To develop a baselined candidate architecture. • To ensure that the architecture, requirements and plans are stable, well-defined and formalized and the

risks are sufficiently mitigated to predictably determine the cost and schedule for the completion of the development.

• To baseline the project estimation in terms of cost, effort, resources and schedule in form of the Software Development Plan.

Elaboration Phase Objectives:

Elaboration Phase Essential Activities:

Elaboration Phase Essential Artifacts:

• Software Development Agreement;• Software Requirements Specification (SRS);• Software Architecture;• Software Development Plan (SDP).

• To elaborate the project requirements by developing, negotiating and validating the Software Requirements Specification (SRS) which focuses on the collection and organization of all requirements surrounding the project in a formal document.

• To develop, negotiate and validate a candidate Software on the basis of the adjusted and validated SRS. Depending on the project scope and level of formalization, the Software Architecture can be presented either as a document (e.g. SDP, Software Architecture Proof-of-Concept) or as a UML model.

• To develop, negotiate and validate the Software Development Plan

The goal of the elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.

Construction Phase

Construction Phase Objectives:

• To develop the product as specified in the requirements; • To test the implemented product; • To transit it to the Customer ;• To test the final product on-site;• To accept the final product.

Construction Phase Essential Activities:

Construction Phase Essential Artifacts: • Release Notes;• Test Evaluation Summary;• Final Product (incl. Software, Release Notes and Test Evaluation Summary);• Acceptance Tests Records.

• To implement a ready for test system/application on the basis of the validated Software Architecture and SRS within the schedule and budget as defined in the SDP;

• To test the implemented system according to the Customer ’s requirements (tests to be performed are subject to the Customer ’s requirements and needs);

• To ensure a joint process of final product transition within the defined schedule;• To perform on-site final acceptance testing against the defined evaluation criteria;• To accept the final product on the basis of the SRS, SDP and Software Architecture.

The goal of the construction phase is clarifying the remaining requirements and completing the development of the system based upon the baseline architecture. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

Transition Phase

Transition Phase Objectives: By the end of the Transition Phase lifecycle objectives should have been met and the project should be in a position to be closed out. In some cases, the end of the current life cycle may coincide with the start of another lifecycle on the same product, leading to the next generation or version of the product. For other projects, the end of Transition may coincide with a complete delivery of the artifacts to a third party who may be responsible for operations, maintenance and enhancements of the delivered system.This Transition Phase ranges from being very straightforward to extremely complex, depending on the kind of product. A new release of an existing desktop product may be very simple, whereas the replacement of a nation's air-traffic control system may be exceedingly complex.

Transition Phase Essential Activities:

Transition Phase Essential Artifacts: • Final Product;• Product Release Notes; • Product Acceptance Record;• Project Close-Out Records.

• executing deployment plans; • finalizing end-user support material; • testing the deliverable product at the development site; • creating a product release; • getting user feedback and fine-tuning the product based on feedback; • making the product available to end users.

The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle. The end of the transition phase should have met the objectives and the project should be in a position to be closed out unless the contract defines other terms of the project close-out.

Project Team Structure

Project Start

Soft Format Joint Processes Customer Processes

Product VisionDevelop Product Vision

Product EstimationEstimate Product

Project Business Case

Develop Project Business Case

Negotiate to obtain shared vision on the product required

Negotiate on the Project Business Case

Request for Proposal

Develop Request for Proposal

Revise Product Vision

Agree upon Project Business Case

Project Feasibility Indentified

Ince

pti

on

Phase

: In

cepti

on

Phase

: C

ust

om

er

-Rela

ted

Vie

wC

ust

om

er

-Rela

ted

Vie

w

Business Case Agreed and Project Identified

Soft Format Joint Processes Customer Processes

Project Business Case

Plan the Project

Software Development Agreement

Develop the Software Development Agreement

Sign Software Development Agreement

Revise Software Development Agreement

Adjust Project Delivery Model

Assign Change Control Board

Assign Project Review Authority

Project Started

Ela

bora

tion

Ph

ase

: Ela

bora

tion

Ph

ase

: C

ust

om

er

-Rela

ted

Vie

wC

ust

om

er

-Rela

ted

Vie

w

Project Started

Project Business Case

Product Vision

Develop the Software Requirements Specification

C

Software Requirements Specification

Software ArchitectureDevelop Software Architecture

Negotiate and validate SRS

Validate SRS

Software Architecture reviewed and

validated

Software Architecture Review discussion

SDA Addendum 2 : Software Development Plan

Revise and adjust SDA

SRS validated

Revise Software Development Plan

Software Development Plan updated

agreed

Software Development Plan Review

To Project Execution Stage

Software Development Agreement

Soft Format Joint Processes Customer Processes

Ince

pti

on

Phase

: In

cepti

on

Phase

: C

ust

om

er

-Rela

ted

Vie

w C

on

tinu

ed

Cu

stom

er

-Rela

ted

Vie

w C

on

tinu

ed

Soft Format Joint Processes Customer Processes

Software Development Plan Agreed

Perform Software Development Activities Release Notes

Ready for Testing Software

Test SystemTest Evaluation

Summary

Ready for Transition Software

Status Review Meetings

Change Management

Transit the Product Product Perform Acceptance Test

Review Results of Acceptance Tests

Corrections of errors/bugs neededCorrect Bugs and Errors

Decide on Iteration/Project Close-Out

Product Accepted

Product Acceptance

Record

To Project Close-Out Phase

Con

stru

ctio

n P

hase

: C

on

stru

ctio

n P

hase

: C

ust

om

er

-Rela

ted

Vie

wC

ust

om

er

-Rela

ted

Vie

w

Soft Format Joint Processes Customer Processes

Product Accepted

Product Acceptance Record

Assess Iteration/ProjectIteration/Project

Assessment

Perform Project Close-Out Review

Perform Contract Close-Out Activities

Iteration/Project Closed

Agree on Iteration/Project

Revise Iteration/Project Assessment Documents

Pro

ject

Clo

se-O

ut:

Pro

ject

Clo

se-O

ut:

C

ust

om

er

-Rela

ted

Vie

wC

ust

om

er

-Rela

ted

Vie

w

Next StepsDiscuss step-by-step processes and procedures, which are required for managing the outsourcing production and adjust the relationship model to Customer requirements;

Choose the most critical processes for managing the relationship and held process-specific workshops to align the business processes and share knowledge;

Baseline the relationship management model;

Plan the relationship management and manage the relationship.

Contacts

Soft Format LLCpr. Hrushevskoho, 30 Lutsk, 43005, Ukraine Phone: 380.332.770091 Fax: 380.332.776367 Email: o.kutsevych@soft-format.comwww.soft-format.com