The Life Cycle of A Large System Integration Project

2. PRESALE &
PROJECT MANAGEMENT
PRESALE

Business Plan

Customer Relationship

Solution and Technology

Process
 BUSINESS PLAN (1)
Creative product or penetrating existing market
FEASIBILITY STUDY
Market analysis (marketing person or outsourcing)
government statistics
market (scale, competitor)
potential customers and their values
strong points and week points (predominance)
risk analysis
SHORT/LONG TERM OBJECTIVE
initial investment, mid-term investment
revenue, cash flow and sales channel
technology
product (series) planning
resource (facility, engineer, marketing, sales)
possible solutions, initial product effort and time to market
 BUSINESS PLAN (2)
Revenue
M US$
Revenue Investment
10

Time
1st 2nd 3rd 4th 5th 10th
year year year year year yea
r
CUSTOMER RELATIONSHIP

Top management’s customer visit to show support

Take customer to site visit

Build friendship
TECHNOLOGY AND SOLUTION

Experiences: past projects and technology/solution

involved

Influence the Request For Proposal (RFP)

Organize seminars for the customers

Philosophy of technology/solution selection

 PRESALE PROCESS
Objectives:
• Establish solid customer relationship to build up trust
• Introduce company’s successful history, experiences,
solutions and leading technology
• Help customer to build up the knowledge
• To know what the customers want and what they prefer
• To know customer’s budget
• To influence the RFP (Request For Proposal) as much as
possible

Participants:
• Marketing and sales
• Program manager, Sometimes business director,
• Engineers (system engineer and software engineer)
• Sometimes the business director, even president

Activities:
• Seminars and presentations
• Project sites visit
• Sometimes home site visit
• Leisure contact
 BIDDING (1)
Prequalification:
To reduce the number of bidders, so only qualified
venders will participate the bid.
• Business license
• Size, revenue of the company
• Similar experiences of comparable size project
in recent five years
• Solution summary

Procedure:
1. Issuance of RFP (Request For Proposal).
Once issued, no customer contact any more.
2. Purchase RFP
3. Bid opening: Declare price for each vendor
4. Review and evaluation: Couple of months
5. Bid closing: Announce winner

Contents of RFP
• International open bid, deadline is set
• Two sections: business and technical
 BIDDING (2)
Participants
PM: leads the team
CM: leads the business team
Chief Engineer: lead a technical team
Business Director &
Accountant: pricing and signature
Engineers: hardware and software
Marketing and sales customer relationship
Legal: legal terms and consulting
Administrators: administrators tasks

Time:
Approximately two-three months
 BIDDING (3)
Proposal Includes:
7 copies of the following items,
one copy with original signature
on every page
BUSINESS
• Legal certificate of the business
• Last three years’ financial reports
• Liability
• Certificate of CMMI level
• Matrix (line by line, yes/no)
TECHNICAL
• Assumptions
• Proposed solution, technology and
tools
• Effort estimation
• Management method, schedule
• Solution for every subsystem and
its info from the vendor
• Matrix (line by line, yes/no)
MATERIALS
• Price brakes down to parts
 BIDDING (4)
Contract Includes:
2 copies with original signatures on
every page

• Scope of services (RFP & Proposal)

• Price
• Payment schedule
• Hardware and software
• Confidentiality
• Rights on data
• Warranty
• Limitation of liability
• Indemnity
• No solicitation
• Arbitration (disputes)
• Jurisdiction (laws apply)
 THE LIFECYCLE
ACTUAL DURATION: Total of 28 months
Program Management
Project Management
Risk Management
Requirement Management
2 yr 2 mo 12 mo 2 mo 3 mo 5 mo 1 mo 3 mo
Presale

PPP Plans

Requirement

Design

Implement

And Testing
Installation

Acceptance

Delivery

End
Backup
Operation
M1 M2 M3 M4 M5 M6
Planning Collection Design Implementation Testing Delivery
Analysis
6 MILESTONES

Participants: Business, Marketing, Sales, Program Manager, Contract

Manager, Subcontractor Manager (s), Project Manager,
Hardware/Software Engineers, Customers and End-users
THE MANAGEMENT SPECTRUM

Four P’s:

People
Product
Process
Project
KEY ELEMENTS TO SUCCESS
TECHNOLOGY MANAGEMENT
• Technology • Requirement
• Domain knowledge • Risk
• Experiences • Schedule (milestones)
• Cost
CUSTOMER
• Culture METHODOLOGY
• Relationship • Right process
METHODOLOGY CUSTOMER
• Right process • Culture
• Relationship
MANAGEMENT
• Requirement TECHNOLOGY
• Risk • Technology
• Schedule (milestones) • Domain knowledge
• Cost • Experiences
 THE PEOPLE(1)
Needs of Human Being
prestige
success
reputation
achievement
rich
safety
shelter
Life
 THE PEOPLE (2)
People management maturity model: recruiting, selection,
performance management, training, compensation, career
development, organization and work design, and team/culture
development.

PM-CMM is a companion to the CMM model, which guides

organizations in the creation of a mature software process.

The Taxonomy of players:

• Senior managers
• HR
• Project managers
• Practitioners
• Customers
• End-users
 THE PEOPLE (3)
The Software Team Group

Team 1 Leader Team 2 Leader Team m Leader

Team Members Team Members Team Members

Three Management Styles [Mantei 81]

Democratic Decentralized (DD) Controlled Decentralized (CD) Controlled Centralized (CC)

No permanent leader, vary by
tasks
Decision and approach are
made by consensus
Horizontal communication
Best for difficult problems;
High morale; job satisfaction;
Too much communication
Defined leaders for tasks and
subtasks
Decision are made at group
level, implementation at
subgroups (Team)
Vertical communication
Good for simple problems;
Better for high modularity;
More efficient
Defined leaders for tasks and
subtasks
Top level problems are
managed by a team leader
Vertical communication
Good for simple problems;
Better for high modularity;
More efficient
 THE PEOPLE (4)
Four Paradigm [Constantine 93]

Closed paradigm
Traditional hierarchy, good for software products

Random paradigm
Loosely structured, depends on individual initiative, heavy communication

Open paradigm
Structure between Closed and Random, heavy communication

Synchronous paradigm
Rely on the natural compartmentalization of the task, little communication outside task
 THE PEOPLE (5)
Factors in constructing a team:
• The difficulty of the problem to be solved
• The size of the resultant program in lines of code or function points
• The time that the team will stay together (team lifetime)
• The degree to which the problem can be modularized
• The required quality of reliability of the system to be built
• The rigidity of the delivery date
• The degree of communication required for the project

To achieve a high performance team:

• Team members must have trust in one another
• Skill distribution must be appropriate to the problem
• Mavericks may have to be excluded from the team
 THE PEOPLE (6)
Coordination and Communication:

6
Formal, impersonal approaches Discussion with peers

Value of coordination technique

Documents
Plan, tech memo, milestone, schedule, and Project milestones
Design reviews
deliverables Error tracking reports
Req. reviews

5
Status review
Formal, interpersonal procedures Electronic mail
Quality assurance, status review, and code Group meeting
inspection Code inspection

4
Public bulletins
Informal, interpersonal procedures
Group meeting for info dissemination and Source code
problem solving Repository data
3
Project control tools
Electronic communication
Email, E-bulletin board, video conferences
2

Interpersonal networking 2 3 4 5 6
Informal discussion with people inside/outside Use of coordination technique
team
 THE PEOPLE (7)

• A jelled team is a group of people so strongly

knit that the whole is greater than the sum of
the parts, the probability of success goes way
up

• It is difficult to find a challenging and

interesting project, but not as difficult as
finding a jelled team, in which your creativity,
energy, and happiness can be maximized
 THE PRODUCT (1)
The dilemma of software project manager at the beginning of a
project: Quantitative estimations and an organized plan before
solid information is available (before requirement
collection/analysis)

Understand the overall characteristics of the product

Refer to past projects with similar scale, technology, and functions
Software scope at system level based on RFP and PROPOSAL,
which must be unambiguous and understandable at the management
and technical levels:

• context
• information objectives
• function and performance
 THE PRODUCT (2)
Problem decomposition
Example: a new word-processing product with unique features: voice
and keyboard input; automatic indexing and table of content;
automatic copy edit; page layout capability, etc.

Input:
voice learning
voice recognition
keyboard input

Automatic copy edit:

spell checking,
sentence grammar checking
reference checking
section and chapter reference validation
…
 THE PROCESS (1)
The software development process models:
select right process model that is best fit the
project for the team

• The Waterfall (linear sequential) model

• The Spiral (prototyping) model
• The Iterative (incremental) model

• The RAD model

• The WINWIN spiral model
• The component-based development model
• The concurrent model
• The formal method model
• The fourth generation technique model

• CMMI (Capacity Maturity Method Integration)

• SEI (Software Engineer Institute)
 THE PROCESS (2)

Model selection based on which process

model is most appropriate for:
1. The characteristics of the project
2. The customers and parishioners
3. The project working environment

Common framework activities:

1. Customer communication
2. Planning
3. Risk analysis
4. Engineering
5. Construction and release
6. Customer evaluation
 THE PROJECT (1)
Signs that indicate that indicate that a project is in jeopardy:

PEOPLE REQUIREMENT RISK FINACE

• None technical split in the team

• Software people do not understand their customer’s needs
• The project scope is poorly defined
• Changes are managed poorly
• The chosen technology changes
• Business needs change (or are ill-defined)
• Financial difficulties
• Deadline is unrealistic
• Users are resistant
• Sponsorship is lost
• Lack of skill sets in the team
• Avoid best practices and lessons learned
 THE PROJECT (2)

To manage a successful project is to manage problems, i.e.,

• to avoid problems
• to reduce the degree of difficulties
• to have a plan/solution before the problems occur.

Five-part commonsense approach [Reel 99]

• Start on the right foot
• Maintain momentum
• Track progress
• Make smart decision
• Conduct a postmortem analysis
 PROJECT CONSTITUTION
TYPICAL CONTENTS:

Project formal name

Program manager and contact
Project manager and contact
Project target and deliverable Constitution
Project time table Resource
Project resource, budget, vendor Team

Manager
Initiator

Definition

Origin
 FACTS OF PM
1995 vs 1998
• The cost of failed projects went down from $81billion to $75 billion
• Decrease in cost overruns from $59 billion to $22 billion

In 1998
• 26% of information technology projects succeed in meeting scope,
time, and cost goals
• 46 percent of IT projects completed over budget and past deadline
• 28% failed

2001 vs 1995
• Time overruns significantly decrease to 63%, compared to 222%
• Cost overruns were down to 45%, compared to 189%
• Required features and functions were up to 67%, compared to 61%
• 78000 US projects were successful, compared to 28000
• 28% of IT projects succeeded, compared to 16%

The Standish Group, “1998 CHAOS Report” & “CHAOS 2001”