P. 1
corporate-project-management-model1546

corporate-project-management-model1546

|Views: 28|Likes:
Published by Ravi Kumar

More info:

Published by: Ravi Kumar on Apr 28, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

Distributed Project Delivery Model

based on Rational Unified Process
Introductory Presentation

© Soft Format, 2006

Introduction
The 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.

Plan of the workshop
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

Explanation to Diagrams
The 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

Contact Initiated

Relationship Management Diagram

Soliciting the Relationship Partnership Opportunity Cancelled
Relationship Established Yes

No

Soliciting the Contract Opportunity Lost
Contract Won

No

Yes

Signing the Contract Contract Lost
Contract Signed Yes

No

Managing the Relationship Contract Administration Service Delivery Management
Project Performed Yes No

Partnership Contract Close-Out
Partnership End

Soft Format

Joint Processes
Prospect Qualified

Customer

Relationship Soliciting Diagram

Prospect Marketing Qualification

Prospect Sales Qualification Prospect Identified

Establish the Contact

General Information about SF Vendor PreIdentified

Identify the Perspectives

Develop Business Vision

From Soft Format L : Business Vision

Justify Business Vision Customer Justified :
Business Vision

Shared Vision obtained

Develop Business Case

From Soft Format L : Business Case

Justify Business Case Customer Justified :
Business Case

Negotiate Business Case

Partnership Opportunity Identified

Developing the Relationship

From the Customer : Partnership Requirements

Planning relationship development

Align Business /Production Processes Align Legal Model Define Communication Model Define Communication Management Processes Align Other Business Specific Processes Define the Risk Management Approach

Relationship Development Plan

Adjust Business Process From Soft Format L : Partnership Model to the Customer Requirements Specific Requirements

Amend Business Process Model

Adjusted and validated : Business Process Model

Develop Relationship Basis
Relationship Basis Developed

Relationship Soliciting Diagram Continued

Soft Format

Joint Processes

Customer

Relationship Basis Developed

Prepare Organizational Environment

Prepared for Use : Business Process Model

Verify Organizational Environment Preparation

Prepare Organizational Environment

Prepared for Use : Business Process Model

Organizational Environment Prepared

Perform Pilot Projects

Pilot Projects Model

Manage Pilot Projects

Test Relationship

Pilot Project Assessment : Record

Partnership Identified

Assess Relationship Efficiency

Formalize Partnership

Partnership Agreement

Plan Relationship

Relationship Management Plan

Relationship Obtained

Project
In 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.

Iteration
Iteration 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. 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. 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.

Project Cycle
As 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
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.

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.

Elaboration Phase
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.

Elaboration Phase Objectives:
• • • • 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 Essential Activities:
• 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

Elaboration Phase Essential Artifacts:
• • • • Software Development Agreement; Software Requirements Specification (SRS); Software Architecture; Software Development Plan (SDP).

Construction Phase
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.

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:
• 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.

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

Transition Phase
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.

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:
• • • • • • • • • • 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. Final Product; Product Release Notes; Product Acceptance Record; Project Close-Out Records.

Transition Phase Essential Artifacts:

Project Team Structure

Inception Phase: Customer -Related View

Soft Format

Joint Processes

Customer Processes
Project Start

Develop Product Vision

Product Vision

Develop Request for Proposal

Request for Proposal

Estimate Product

Product Estimation

Negotiate to obtain shared vision on the product required

Revise Product Vision

Develop Project Business Case

Project Business Case

Negotiate on the Project Business Case

Agree upon Project Business Case

Project Feasibility Indentified

Elaboration Phase: Customer -Related View

Soft Format

Joint Processes
Business Case Agreed and Project Identified

Customer Processes

Assign Project Review Authority

Assign Change Control Board

Plan the Project

Project Business Case

Adjust Project Delivery Model

Develop the Software Software Development Development Agreement Agreement

Revise Software Development Agreement

Sign Software Development Agreement
Project Started

Soft Format

Joint Processes

Customer Processes
Project Started

Inception Phase: Customer -Related View Continued

C

Project Business Case

Develop the Software Requirements Specification

Product Vision

Software Requirements Specification

Negotiate and validate SRS

Validate SRS

SRS validated

Develop Software Architecture

Software Architecture

Software Development Agreement

Software Architecture Review discussion
Software Architecture reviewed and validated

Revise and adjust SDA

SDA Addendum 2 : Software Development Plan

Revise Software Development Plan

Software Development Plan Review
Software Development Plan updated agreed To Project Execution Stage

Soft Format

Joint Processes
Software Development Plan Agreed

Customer Processes

Construction Phase: Customer -Related View

Perform Software Development Activities

Status Review Meetings
Release Notes

Ready for Testing Software

Test System
Test Evaluation Summary

Change Management

Ready for Transition Software

Transit the Product

Product

Perform Acceptance Test

Review Results of Acceptance Tests
Corrections of errors/bugs needed

Correct Bugs and Errors

Decide on Iteration / Project Close-Out

Product Acceptance Record Product Accepted

To Project Close-Out Phase

Project Close-Out: Customer -Related View

Soft Format

Joint Processes
Product Accepted

Customer Processes

Product Acceptance Record Agree on Iteration/Project

Assess Iteration/Project
Iteration/Project Assessment

Perform Project Close Out Review

Revise Iteration/Project Assessment Documents

Perform Contract CloseOut Activities

Iteration/Project Closed

Next Steps
Discuss 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 LLC pr. Hrushevskoho, 30 Lutsk, 43005, Ukraine Phone: 380.332.770091 Fax: 380.332.776367 Email: o.kutsevych@soft-format.com www.soft-format.com

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->