Introduction
Critical Best Practices for
Project Delivery
Objectives:
Presented By: S. Elaine Walton
MBA, PMP, RCA, CQM
Copyright (c) 2009 Ms S Elaine Walton
Copyright (c) 2009 Ms S Elaine Walton
Why Project Management?
Introduction
†
The Chaos Report (1995) by Standish Group
„
†
„
†
IT executive managers. (365 respondents)
Large, medium, and small companies across major industry
segments
Key Findings
„
„
„
3
the landmark study of IT project failure.
Scope of the Study
„
Copyright (c) 2009 Ms S Elaine Walton
2
31.1% of projects canceled before they ever get completed.
52.7% of projects will cost over 189% of their original
estimates.
average is only 16.2% for software projects that
are completed on-time and on-budget.
Copyright (c) 2009 Ms S Elaine Walton
4
Fundamentals
†
Fundamentals
General Project Life Cycle:
Common characteristics of a Project:
¾
Projects are temporary
¾
Unique product, service or result
¾
Progressive elaboration
Source: MPMM.com
Copyright (c) 2009 Ms S Elaine Walton
5
Fundamentals
Copyright (c) 2009 Ms S Elaine Walton
6
Fundamentals
V-Model SW Life Cycle
Phases of IT Project Life Cycle:
Note:
†
Requirements Drivenstarts with user needs
†
Needs are decomposed
into system concepts and
specification (left side)
†
Integration, Verification,
and Validation directly correlate
to decomposition activities
Source Singh, IEEE/EIA 12207 Software Life Cycle Processes
Copyright (c) 2009 Ms S Elaine Walton
7
Copyright (c) 2009 Ms S Elaine Walton
8
Fundamentals
Fundamentals
Bohem’s (1988) Spiral Model
†
Key steps
Note:
Starts with concept
Cost increases as project progresses
Review increases as project progresses
†
†
†
„
„
„
„
„
Copyright (c) 2009 Ms S Elaine Walton
9
Copyright (c) 2009 Ms S Elaine Walton
IT Project Eccentricities
†
†
Continuous technology change:
†
†
Implementation Projects:
„
External - Market driven
Internal – Development driven
Continuous technology change
†
†
Balancing Act
Copyright (c) 2009 Ms S Elaine Walton
10
IT Project Eccentricities
HW/SW Development Projects:
„
Concept
PM/Development Planning
Execution
Controlling
Closing
External – Supplier
Internal customer demand
Balancing Act
11
Copyright (c) 2009 Ms S Elaine Walton
12
Systems Approach
†
Systems Approach
“Systems” refers to the interaction
between seemingly separate functions
†
History
„
Systems have, of course, always existed
◦ Think of the
“Butterfly effect” –
the sensitivity of
chaotic systems to
small perturbations
“the whole is greater than the sum
of its parts” – Aristotle
†
Copyright (c) 2009 Ms S Elaine Walton
13
Systems Approach
Copyright (c) 2009 Ms S Elaine Walton
14
Systems Approach
Summary Message:
For our purposes
The Systems Approach is a logical and
disciplined process of problem solving
which:
¾ Requires an understanding of relationships
between subsystems
¾ Dynamically integrates all activities into a
single system
¾ Seeks optimal solutions and strategies
Copyright (c) 2009 Ms S Elaine Walton
The basic philosophy is that systems have a
purpose, and the goal of the system is to remain
robust, so all actions within the system are
directed toward that goal
15
Think “SYSTEM”
= “Holistic Approach”
Copyright (c) 2009 Ms S Elaine Walton
16
Common IT Project Challenges
†
Common IT Project Challenges
†
Project takes on a life of its own
„
†
Often through the best of intentions,
projects grow to the point where they are
no longer viable. This is ultimately the
responsibility of the manager to control.
Copyright (c) 2009 Ms S Elaine Walton
„
17
Common IT Project Challenges
†
†
†
Copyright (c) 2009 Ms S Elaine Walton
†
†
†
Potentially related to the previous issue,
this may also be a result of a drop in
interest in the project.
Copyright (c) 2009 Ms S Elaine Walton
Programmers and engineers are notorious
for this. They get excited at the prospect
of working on a project, and underestimate
the amount of work necessary to
incorporate the promised features, or
miscalculate the current state of
technology.
18
Common IT Project Challenges
Project takes on a life of its own
Over promising
Under delivery
„
Project takes on a life of its own
Over promising
†
Project takes on a life of its own
Over promising
Under delivery
Unreasonable expectation or business case
„
19
A project which has been oversold to the
client as being of greater benefit than it really
is. This is a real danger in many projects, and
is one that may have repercussions that fall
directly upon the project manager.
Copyright (c) 2009 Ms S Elaine Walton
20
Common IT Project Challenges
†
†
†
†
†
Common IT Project Challenges
Project takes on a life of its own
Over promising
Under delivery
Unreasonable expectation or business case
Immature/changing technology
„
This is one of the reasons that it is important
to be a part of the planning stage. It is
management’s duty to question and expect
justification for the technology that will
underlie the project.
Copyright (c) 2009 Ms S Elaine Walton
†
†
†
†
†
†
†
†
21
Related to, but separate from the issue
above, this can slow down the planning
phase, as well as create conflict, quality, and
productivity problems during production.
Copyright (c) 2009 Ms S Elaine Walton
22
Common IT Project Challenges
One of the great challenges for a manager is
maintaining control and authority.
Copyright (c) 2009 Ms S Elaine Walton
†
Project takes on a life of its own
Over promising
Under delivery
Unreasonable expectation or business case
Immature/changing technology
Technology choices
„
Project takes on a life of its own
Over promising
Under delivery
Unreasonable expectation or business case
Immature/changing technology
Technology choices
Client retains authority to approve/reject low
level designs
„
†
†
Common IT Project Challenges
†
†
†
†
†
†
†
†
†
†
Project takes on a life of its own
Over promising
Under delivery
Unreasonable expectation or business case
Immature/changing technology
Technology choices
Client retains authority to approve/reject low
level designs
Destructive Role
„
23
These are people who take on roles that are
destructive to the project…
Copyright (c) 2009 Ms S Elaine Walton
24
Common IT Project Challenges
Destructive roles
Not aligned with business strategy
†
†
†
Should be discovered in business case
Requires that you completely understand
the business strategy
Must be discussed with stakeholders
Source: Kersner (1984)
Copyright (c) 2009 Ms S Elaine Walton
25
Common IT Project Challenges
Not aligned with business strategy
Not integrated with business processes
Not integrated with business processes
†
†
Potentially more complex than the above
case
Can easily occur when working for an
outside client
Involves long term strategy discussion
Copyright (c) 2009 Ms S Elaine Walton
26
Common IT Project Challenges
Not aligned with business strategy
†
Copyright (c) 2009 Ms S Elaine Walton
Security issues
†
†
†
†
27
Work product
Knowledge
Process
You must protect your team, company and
client
Copyright (c) 2009 Ms S Elaine Walton
28
IT Axioms
†
†
Identified Issues for Case Study# 1
90% rule – 90% of the project is done in half
the allotted time, yet the project is still late.
Objectives:
• Identify list of issues
• Apply your experience
Brooke’s law: Increasing resources late in an IT
project will make the project even later.
Copyright (c) 2009 Ms S Elaine Walton
29
Case Study# 1
Copyright (c) 2009 Ms S Elaine Walton
Key Success Factors for IT Projects
„
To be discussed
„
„
„
„
„
„
„
„
„
Copyright (c) 2009 Ms S Elaine Walton
30
31
Obtain clear and quality customer requirements
Control scope creep
Adequate progress and technical review
Proper testing
Test in the production environment
High standard of quality assurances
Conform to industry standards and best practices
Timely communication
Careful project time estimation
Provide sufficient budget
Copyright (c) 2009 Ms S Elaine Walton
32
Why Problem Solving?
Problem Solving Steps
„
„
„
„
„
„
„
Copyright (c) 2009 Ms S Elaine Walton
33
Mind Set of Problem Solving
„
„
„
„
„
„
„
„
„
„
Copyright (c) 2009 Ms S Elaine Walton
34
Specific Problem Solving Tools
Focus on the solved state.
Be clear about all your goals and objectives.
Expand your definition of “Define the Problem.”
Think of problem solving as a cover-the-bases
activity.
Draw diagrams and otherwise picture the structure
of the problem.
Take the concept of cause with a grain of salt.
Watch out for “disconnects.”
Be aware of your own blinders.
Develop your own system for solving problems.
Research the subject matter.
Copyright (c) 2009 Ms S Elaine Walton
1. Define the problem
2. Identify the potential causes
3. Identify alternatives for approaches to
resolve the problem
4. Select an approach to resolve the problem
5. Create implementation/action plan
6. Monitor and control the implementation
plan
7. Verify resolution and close out
35
„
„
„
„
„
„
Risk management
SWOT
PEST Analysis
Computer based tools
Expert Review
Customer Led Review
Copyright (c) 2009 Ms S Elaine Walton
36
Specific Problem Solving Tools
Specific Problem Solving Tools
„
Risk Management
†
Failure Mode Effect Analysis (FMEA)
Severity Level
Level
Copyright (c) 2009 Ms S Elaine Walton
37
Specific Problem Solving Tools
„
Occurance
Improbable
2
Remote
Very unlikely, less than 1 in 1,000,000
chance
Unlikely, more than 1/1,000,00 and less than
1/100,000
3
Occasional
Likely to occur, more than 1/100,000 and
less than 1/1,000
4
Probable
Probably will occur, more than 1/1,000 and
less than 1/100
5
Frequent
Frequently Occurs, more than 1/100 chance
Copyright (c) 2009 Ms S Elaine Walton
Minor injury not requiring medical attention
3
Serious
Temporary injury requiring medical attention
4
Critical
Permanent impairment or injury
5
Catastrophic
Death
38
Failure Mode Effect Analysis (FMEA)
Acceptance Level
Probability Level
Probability
Minor
Risk Management
†
Failure Mode Effect Analysis (FMEA)
1
2
No injury or temporary discomfort /
inconvenience
Copyright (c) 2009 Ms S Elaine Walton
„
Level
1
Specific Problem Solving Tools
Risk Management
†
Possible Description
ommon Term
Negligible
39
Copyright (c) 2009 Ms S Elaine Walton
As Low As Reasonably Practical (ALARP)
Intolerable
Broadly Acceptable
40
Specific Problem Solving Tools
„
Specific Problem Solving Tools
Risk Management
†
†
Risk Exposure Calculations
In verification & validation (V&V), the question
is always “how much is enough?”. Ghezzi &
McDermid (1989) provide some insight:
1st step:
determine your risk exposure (RE)
Risk Exposure Calculations
Step 2:
To help you determine the appropriate level of risk, risk
reduction leverage (RRL) provides further clarification:
Given: $ 1M software project,
0.3=Prob(0.5) * Loss(0.6)
Where there is a 0.5 chance of failure of
a loss that is a 0.6 before any investment
in V&V
0.1=Prob(0.2) * Loss(0.5)
If a $20k investment in V&V is spent
during R&D, probability is reduced to
0.2 and loss is reduced to 0.5
RE = Prob(UO) * Loss(UO)
Where:
Prob(UO) is the probability of an unsatisfactory outcome and
Loss(UO) is the amount of loss in the case of an unsatisfactory
outcome.
Both are measured on a Likert scale of 0 to 1.0
Copyright (c) 2009 Ms S Elaine Walton
0.05=Prob(0.1) * Loss(0.5)
41
Specific Problem Solving Tools
†
If a $150k investment in V&V is spent
during testing, probability is reduced to
0.1 and the loss is reduced to 0.5
Copyright (c) 2009 Ms S Elaine Walton
42
Specific Problem Solving Tools
Risk Exposure Calculations
Accepted
Step 3:
To help you determine the appropriate level of risk, risk
reduction leverage (RRL) provides further clarification:
Shared
Transferred
RISK
TREATMENT
Avoid
Copyright (c) 2009 Ms S Elaine Walton
43
Control
Copyright (c) 2009 Ms S Elaine Walton
44
Specific Problem Solving Tools
„
Specific Problem Solving Tools
Other Risk Analysis Techniques:
†
†
†
†
†
„
Decision Tree Analysis
Fishbone Analysis
Force Field Analysis
Brainstorming
Delphi Method
„
Risk management
SWOT
†
†
†
†
Strengths - Positive internal factors
Weaknesses – Negative internal factors
Opportunities – Positive external factors
Threats – Negative external factors
This technique is done before the project is begun, but
it is also a useful tool for creating a case to argue
for or against a proposed change, or determine the
nature of a situation.
Copyright (c) 2009 Ms S Elaine Walton
45
Specific Problem Solving Tools
Copyright (c) 2009 Ms S Elaine Walton
47
Source: Stuart et. al. (2002)
Copyright (c) 2009 Ms S Elaine Walton
46
Specific Problem Solving Tools
Copyright (c) 2009 Ms S Elaine Walton
Source: Stuart et. al (2002)
48
Specific Problem Solving Tools
„
„
„
Specific Problem Solving Tools
Risk management
SWOT
PEST Analysis (Political, Economic, SocioCultural and Technological )
†
†
†
„
Create a list of relevant factors that apply to your
situation;
Collect information that applies to these factors;
Evaluate and make conclusions
Copyright (c) 2009 Ms S Elaine Walton
49
Specific Problem Solving Tools
„
„
„
„
†
MindTools.com
50
This is a growing area of project management. Large
projects (particularly IT) require explicit and complex
models that go far beyond the mental model capabilities
of humans.
Examples of the tools:
†
COCOMO – COnstructive COst MOdel
†
CMMI – Capability Maturity Model Integration
†
CASE – Computer Aided Software Engineering
Examples of some commercial packages:
†
ESTIMACS – Computer Associates International, Inc.
†
Knowledge Plan – Software Productivity Research,
Inc.
†
SLIM –Quantitative Software Management, Inc
Create models or roadmaps that provide logical
environment in which a decision can be made
and validated.
Copyright (c) 2009 Ms S Elaine Walton
Copyright (c) 2009 Ms S Elaine Walton
Specific Problem Solving Tools
Risk management
SWOT
PEST Analysis
Computer based tools
†
PEST Analysis
51
Copyright (c) 2009 Ms S Elaine Walton
52
Specific Problem Solving Tools
„
Specific Problem Solving Tools
CoCoMo (and CoCoMo II)
†
†
Developed by Dr. Barry Boehm as a model for estimating
cost, effort and schedule for software projects
Applies to
„
Organic projects – small projects employing small
teams, following flexible requirements.
„
Semi-detached projects – intermediate projects with
mid-sized teams following relatively well defined
requirements.
„
Embedded projects – tightly defined projects with
clear, tight specifications
„
CoCoMo computes an estimate of development time,
effort and cost based upon the estimated lines of code
and platform.
Copyright (c) 2009 Ms S Elaine Walton
53
Specific Problem Solving Tools
„
†
†
54
Specific Problem Solving Tools
Compatibility Maturity Model Integration (CMMI)
†
Copyright (c) 2009 Ms S Elaine Walton
Developed in response to constantly late, over budget software
development projects.
Basis for many commercial packages.
Five levels of maturity (The pathway to improvement):
„
Compatibility Maturity Model Integration
(CMMI)
†
IDEAL approach to software process improvement
„
Initiating – the improvement program
„
Diagnosing – the current state
„
Establishing – plans for improvement
„
Acting – on the plans
„
Leveraging – the lessons learned
Source: Paulk, et. al
Copyright (c) 2009 Ms S Elaine Walton
Source: Paulk, et.55al
Copyright (c) 2009 Ms S Elaine Walton
56
Specific Problem Solving Tools
„
Specific Problem Solving Tools
CASE tools
†
„
Computer Aided Software Engineering
„ Automated development of software using a
strict engineering approach
„ CASE projects tend to be large, complex,
commercial products
„ Used to support analysis, design,
construction, and implementation stages
„ Integration of PM tools is a fairly recent
development (one of the Workbench
functions)
„
Source Wikipedia
Copyright (c) 2009 Ms S Elaine Walton
CASE environments:
†
Life cycle
†
Integration
†
Construction
†
Knowledge base
Used for:
†
Modeling business / real world process and data
flow
†
Development of data models in the form of
entity-relationship diagrams
†
Development of process and function
descriptions
†
Production of database creation SQL and stored
procedures
57
Specific Problem Solving Tools
The software process can be broken down into:
Activity, Goal, Problem, Event, Decision, Rule, Role
Here is a highly simplified, fairly high level view (the system can go to
much lower levels) of activities and rules followed by humans and
tools in a single process within the development a compiler.
Copyright (c) 2009 Ms S Elaine Walton
Specific Problem Solving Tools
„
„
„
„
„
Risk management
SWOT
PEST Analysis
Computer based tools
Expert Review
†
†
Copyright (c) 2009 Ms S Elaine Walton
59
Source: Jarzabek & Huang (1998)
Source Wikipedia
58
When a trouble issue has been identified, assemble
an expert panel who can review the issue and
recommend the best course of action. The panel
may consist of internal and/or external experts
with a cross section of relevant skills.
You can probably put together a strong expert
review panel while you’re here today!
Copyright (c) 2009 Ms S Elaine Walton
60
Specific Problem Solving Tools
„
„
„
„
„
„
Breakout Groups
Risk management
SWOT
PEST Analysis
Computer based tools
Expert Review
Customer Led Review
†
†
„
„
„
„
In a similar fashion, the customer may have
some important input on ongoing problems.
There are dangers to this approach, of course,
but there are also benefits to a well managed
panel.
Copyright (c) 2009 Ms S Elaine Walton
„
„
61
Case Study# 2 & 3
†
Process:
Read content
Open the floor for discussion
Identify the issues
Use your experience and points discussed
previously to resolve problems
Wrap up discussion and reassemble
Discuss outcomes with the entire group
Copyright (c) 2009 Ms S Elaine Walton
62
Runaway Project Remedies
To be discussed
Copyright (c) 2009 Ms S Elaine Walton
63
Copyright (c) 2009 Ms S Elaine Walton
Source: Smith (2001)
64
Wrap Up
Q&A
Copyright (c) 2009 Ms S Elaine Walton
65
Recommended Reading
†
†
†
†
†
†
†
†
†
†
†
†
Copyright (c) 2009 Ms S Elaine Walton
Recommended Reading
Reference List
†
Bashir, H. A. (2008). "Modeling of development time for hydroelectric generators using
factor and multiple regression analyses." International Journal of Project Management
26(4): 457-464.
Chachere, J., J. Kunz, et al. "Can you accelerate your project using extreme collaboration?".
Collyer, S. and C. M. J. Warren (2009). "Project management approaches for dynamic
environments." International Journal of Project Management 27(4): 355-364.
European Software Engineering, C., C. Ghezzi, et al. ESEC '89 : 2nd European Software
Engineering Conference, University of Warwick, Coventry, UK, September, 11-15, 1989 :
proceedings, Berlin; New York, Springer-Verlag.
Gelbard, R., N. Pliskin, et al. (2002). "Integrating system analysis and project management
tools." International Journal of Project Management 20(6): 461-468.
Hwee, N. G. and R. L. K. Tiong (2002). "Model on cash flow forecasting and risk analysis for
contracting firms." International Journal of Project Management 20(5): 351-363.
Jarzabek, S. and R. Huang (1998). "The case for user-centered CASE tools."
Communications of the ACM 41(8): 93 - 99.
Kerzner, H. (1984). Project management : a systems approach to planning, scheduling, and
controlling. New York, Van Nostrand Reinhold.
Lewin, M. D. (2002). Better software project management : a primer for success. New York,
John Wiley.
Montealegre, R. and M. Keil (2000). "De-Escalating Information Technology Projects:
Lessons from the Denver International Airport." MIS Quarterly 24(3): 417 - 447.
Morecroft, J. D. W. and J. Sterman (1994). Modeling for learning organizations. Portland,
Or., Productivity Press.
Copyright (c) 2009 Ms S Elaine Walton
66
67
†
†
†
†
†
†
†
Reference List
Pan, G. S. C. (2005). "Information systems project abandonment: a stakeholder analysis."
International Journal of Information Management 25(2): 173-184.
Pan, G. S. C., S. L. Pan, et al. (2004). "De-escalation of commitment to information systems
projects: a process perspective." The Journal of Strategic Information Systems 13(3): 247270.
Paulk, M., C. Weber, et al. "The Capability Maturity Model for Software." Software
Engineering Institute, USA.
Project Management, I. and I. Books24x. (2008). "A guide to the Project management body
of knowledge (Pmbok guide), fourth edition."
Stewart, R. A. (2008). "A framework for the life cycle management of information
technology projects: ProjectIT." International Journal of Project Management 26(2): 203212.
Stewart, R. A., S. Mohamed, et al. (2002) "Strategic implementation of IT/IS projects in
construction: a case study ".
Team, C. P. (2007) "CMMI® for Acquisition, Version 1.2."
Copyright (c) 2009 Ms S Elaine Walton
68
Discussion: Common Project Issues
†
Soft Skills for Project Managers
What are the common project
management issues in your organization
in the context of IT projects?
Mr Paul Mau
Senior Consultant
Copyright (c) by Mr Paul Mau
Poor Planning
‡
2
Scope Creeping
Roadblocks Encountered
‡ Number of outside locations to deploy products
increases project complexity and risk exponentially
‡ Unknown conflicts and timing issues delay project
‡ Unexpected staffing needs
‡ Unexpected equipment and supply needs increasing
cost of project
Copyright (c) by Mr Paul Mau
3
‡
Roadblocks Encountered
‡ Development never ends, product changes frequently
‡ Modifications to product during initial deployment
‡ Drastically increases your risk of failure
‡ Getting off the vendor upgrade path
‡ Unexpected increase in cost, effort and duration
Copyright (c) by Mr Paul Mau
4
Poor Technology Evaluation
‡
No User Involvement
Roadblocks Encountered
‡ Products selected do not work
‡ Products selected have never been implemented before
‡ The correct components were not budgeted or purchased
until later in the project
‡ Vendor goes out of business before project completion
Copyright (c) by Mr Paul Mau
‡
5
No Executive Sponsorship
‡
Roadblocks Encountered
‡ Products developed do not meet customer needs
‡ New business process reduces productivity
‡ Product design takes longer than expected
‡ Product is not accepted by the users
‡ Products developed do not provide a return on investment
or add value to the business
Copyright (c) by Mr Paul Mau
Other People Issues in a Project?
Roadblocks Encountered
‡ Project does not get the right level of support
when needed
‡ Project goes in fragmented directions
‡ Issue resolutions are slow to arrive, sometimes
causing a stoppage of the project
‡ Project lacks focus
‡ No leadership
No commitment
from team members
who have other
priorities
Conflicts among
team members
resulting in low
morale
A few team members
exercising undue
negative influence over
the team
What else????
Copyright (c) by Mr Paul Mau
6
7
Little or no formal
power for project
manager
Motivational
problems of
team members
Incompetent project
manager - Too bossy or
out of touch with the
team, or too focused
on technical tasks
Copyright (c) by Mr Paul Mau
Organizational
change resulting in
change of project
personnel
Unclear roles and
responsibilities
resulting in conflicts
and abdication of
responsibilities
Lack of
resources due to
insufficient
funding or
inappropriate
resource planning
No
leadership
8
Soft Skills for IT Project
Management
‡ Political
‡ Team
Political Savvy
Definition: Political savvy in the workplace represents the
totality of skills for successfully navigating the political
dynamics of an agency to accomplish one’s goals.
Savvy
Building and Development
Political savvy enables you to:
‡ The
Approaches of Negotiation
‡ Vendor
Management
Copyright (c) by Mr Paul Mau
‡
People who understand and use office politics to
their advantage are much more likely to succeed
than their politically naïve counterparts.
‡
Determine the requirements of each situation and
each person you face.
Copyright (c) by Mr Paul Mau
Parties
10
Project Sponsor
Internal
Achieve
Project
Objectives
Provide
Funding
Project Team
Customer
Project
Procure
Parties
Seller
Procure
Manager
Contractor
Use the networks you have developed as part of
your partnering efforts (which we discussed
earlier)!
Copyright (c) by Mr Paul Mau
Adapt your style, tactics and skills to the situation.
External
Political savvy means knowing not just how to build
networks, but how to use them.
‡
‡
Relationship of Key Stakeholders
To ignore office politics is to ignore those underlying
forces that account for the differences in success
between equally talented people.
‡
Get things done and know who to go to get things
done quickly and efficiently.
9
Political Savvy (cont.)
‡
‡
Buyer
Product /
Service
Team
Team
Product /
Members
Members
Service
Supplier
11
Copyright (c) by Mr Paul Mau
12
When Forming A Team…
†
†
†
†
Here are some suggestions for improving your teambuilding skills:
Look for individuals who are competent
Turn constraints into advantages
Plan for HR risk factors such as change of
personnel
Review the personality profile of the team
„
†
Team-Building Skills
MBTI; 4 Social Styles; …
†
‡
Provide constructive feedback in appropriate ways.
Critique ideas, do not criticize people.
‡
Offer individual or group positive reinforcement for positive
team behavior with reward and award (e.g., e-mails,
recommendations for awards)
‡
Offer staff development.
‡
Share leadership responsibilities when appropriate.
13
Copyright (c) by Mr Paul Mau
Process where competing sides give their view of the
issues, their positions, and exchange proposals
‡
There are three approaches to negotiation:
„ Soft negotiator – goal is achieving an agreement –
soft on both people and problems
„ Hard negotiator – goal is to win – hard on both
people and problems
„ Principled negotiator – goal is to reach a wise
decision – soft on people, hard on problems
‡
‡
‡
Third-party Intervention
‡
Copyright (c) by Mr Paul Mau
14
Vendor Management: THE
PROBLEM
Negotiation Concepts
†
Appreciate the 5 Stages of Team Formation – Forming,
storming, norming, performing, adjourning
Observe group mix and balance
Copyright (c) by Mr Paul Mau
†
‡
15
Vendors in control
‡ Relationship characteristics
‡ Utilizing their contract
‡ Time
Poorly written contract terms and conditions
Poor performance and responsiveness
No accountability or monitoring tools
‡ Financial
‡ Vendor
‡ Customer
Lack of management support
Copyright (c) by Mr Paul Mau
16
Vendor Management: Actively Manage the
Project
‡
A hands-off project manager is usually surprised when the
software is delivered
„ And the surprise is never a pleasant one.
‡
Constantly communicate project goals
‡ The vendor’s goals always differ from the clients
‡ Don’t expect the team to ignore the vendor’s goals
‡ Work with the team to establish the goals of the project as an
equal or greater priority
‡
It’s not enough to just have weekly status meetings with no
follow-up
„ Project managers need to know the team.
„ Just like an in-house project!
„ Conduct inspection & Review Regularly
Vendor Management: Design,
Programming and Software Quality
†
†
Copyright (c) by Mr Paul Mau
17
Don’t delegate the entire design and programming of the project
to the vendor
„ Establish design constraints early on.
„ If possible, design the software in-house, or in collaboration
with the vendor.
„ Monitor the code base using code reviews and project
automation.
Take responsibility for the quality of the software
„ Quality is not just another deliverable that can be bought and
paid for.
„ Don’t make decisions that undercut the QA team.
„ Ensure that adequate time and budget is allocated for test
planning and execution.
Copyright (c) by Mr Paul Mau
18
KEYS TO SUCCESS
†
†
†
†
†
Develop and implement an effective contract
Develop and maintain the relationship
Know your vendor
Evaluate and rate the vendors regularly
Manage the vendor
„
„
„
Paul Mau
Senior Consultant
Email: paul@knowledgecentury.com
Web: http://www.knowledgecentury.com
Blog: http://knowledgecentury.blogspot.com/
Measurements
Monitoring
TAKE ACTION
THANK YOU!
Copyright (c) by Mr Paul Mau
19
Copyright (c) by Mr Paul Mau
20