Corporate project management model

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.

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

Relationship Management Diagram

Relationship Soliciting Diagram

Relationship Soliciting Diagram Continued

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

Inception Phase: Customer -Related View

Elaboration Phase: Customer -Related View

Inception Phase: Customer -Related View Continued

Construction Phase: Customer -Related View

Project Close-Out: Customer -Related View

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