2. PRESALE

1
2. PRESALE PROJECT MANAGEMENT
The Life Cycle of A Large System Integration
Project
2
PRESALE

• Business Plan
• Customer Relationship
• Solution and Technology
• Process

3
BUSINESS PLAN (1)
Creative product or penetrating existing
market FEASIBILITY STUDY Market
analysis (marketing person or outsourcing) govern
ment 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
4
BUSINESS PLAN (2)
Revenue M US
Revenue
Investment
10
9
8
7
6
5
4
3
2
1
Time
10th year
1st year
2nd year
3rd year
4th year
5th year
5
CUSTOMER RELATIONSHIP

• Top managements customer visit to show support
• Take customer to site visit
• Build friendship

6
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

7
PRESALE PROCESS

• Objectives
• Establish solid customer relationship to build up
  trust
• Introduce companys 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 customers 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

8
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
• Issuance of RFP (Request For Proposal). Once
  issued, no customer contact any more.
• Purchase RFP
• Bid opening Declare price for each vendor
• Review and evaluation Couple of months
• Bid closing Announce winner

• Contents of RFP
• International open bid, deadline is set
• Two sections business and technical

9
BIDDING (2)
Participants PM CM Chief Engineer Business
Director Accountant Engineers Marketing and
sales Legal Administrators
leads the team leads the business team lead a
technical team pricing and signature hardware
and software customer relationship legal terms
and consulting administrators tasks
Time Approximately two-three months
10
BIDDING (3)

• 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

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

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

12
THE LIFECYCLE
ACTUAL DURATION Total of 28 months
Program Management
Project Management
Risk Management
Requirement Management
2 yr
2 mo
12 mo
3 mo
2 mo
3 mo
5 mo
1 mo
Presale
PPP Plans
Requirement
Implement
Installation And Testing
Design
Acceptance
Delivery
End
Operation Backup
M1 Planning
M2 Collection Analysis
M5 Testing
M6 Delivery
M4 Implementation
M3 Design
6 MILESTONES
Participants Business, Marketing, Sales,
Program Manager, Contract Manager, Subcontractor
Manager (s), Project Manager, Hardware/Software
Engineers, Customers and End-users
13
THE MANAGEMENT SPECTRUM

• Four Ps
• People
• Product
• Process
• Project

14
KEY ELEMENTS TO SUCCESS

• MANAGEMENT
• Requirement
• Risk
• Schedule (milestones)
• Cost

• TECHNOLOGY
• Technology
• Domain knowledge
• Experiences

• CUSTOMER
• Culture
• Relationship

• METHODOLOGY
• Right process

• CUSTOMER
• Culture
• Relationship

• METHODOLOGY
• Right process

• MANAGEMENT
• Requirement
• Risk
• Schedule (milestones)
• Cost

• TECHNOLOGY
• Technology
• Domain knowledge
• Experiences

15
THE PEOPLE(1)
Needs of Human Being
prestige
success
reputation
achievement
rich
safety
shelter
Life
16
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

17
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 Defined leaders for tasks and subtasks Defined leaders for tasks and subtasks
Decision and approach are made by consensus Decision are made at group level, implementation at subgroups (Team) Top level problems are managed by a team leader
Horizontal communication Vertical communication Vertical communication
Best for difficult problems High morale job satisfaction Too much communication Good for simple problems Better for high modularity More efficient Good for simple problems Better for high modularity More efficient
18
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
19
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

20
THE PEOPLE (6)
Coordination and Communication Formal,
impersonal approaches Plan, tech memo, milestone,
schedule, and deliverables Formal, interpersonal
procedures Quality assurance, status review, and
code inspection Informal, interpersonal
procedures Group meeting for info dissemination
and problem solving Electronic
communication Email, E-bulletin board, video
conferences Interpersonal networking Informal
discussion with people inside/outside team
6 5 4 3
2
Discussion with peers
Documents Project milestones Error tracking
reports
Design reviews
Req. reviews
Status review
Electronic mail
Group meeting
Code inspection
Value of coordination technique
Public bulletins
Source code Repository data
Project control tools
2 3 4 5
6
Use of coordination technique
21
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

22
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

23
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

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

25
THE PROCESS (2)

• Model selection based on which process model is
  most appropriate for
• The characteristics of the project
• The customers and parishioners
• The project working environment
• Common framework activities
• Customer communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Customer evaluation

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

27
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

28
PROJECT CONSTITUTION
TYPICAL CONTENTS Project formal name Program
manager and contact Project manager and
contact Project target and deliverable Project
time table Project resource, budget, vendor
Constitution
Resource
Team
Manager
Initiator
Definition
Origin
29
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