Project Management in distributed project environment

1. Building Castles
on Sand:
Managing Change in
Distributed Project
Environments
Presenter:
Bohitesh Misra

2. Definition of Project Success
Classic definition of project success:
- in time,
- within budget, and
- delivering full scope.
C
o
s
t
/
B
u
d
g
e
t
Scope / Quality
T
i
m
e
/
S
c
h
e
d
u
l
e

3. Definition of Project Success
Classic definition of project success:
- in time,
- within budget, and
- delivering full scope.
What is the reality?
C
o
s
t
/
B
u
d
g
e
t
Scope / Quality
T
i
m
e
/
S
c
h
e
d
u
l
e

4. Project Success Factors
Based on data from the
CHAOS Report - The Standish Group 1995
Project Success Factors
15.90%
13.00%
8.20%
2.90%
60.00%
User Involvement
Clear Requirements
Realistic Expectations
Clear Vision & Objectives
All Others
Project Successful: the project is completed on time and on
budget, with all the features and functions originally specified

5. Project Challenged Factors
Based on data from the
CHAOS Report - The Standish Group 1995
Project Challenged: the project is completed and operational,
but over budget, late, and/or with fewer features and
functions than initially specified
Project Challenged Factors
12.80%
12.30%
11.80%
5.90%
5.30%
51.90%
Lack of User Involvement
Incomplete Requirements
Changing Requirements
Unrealistic Expectations
Unclear Objectives
All Others

6. Project Impaired Factors
Based on data from the
CHAOS Report - The Standish Group 1995
Project Impaired: the project is cancelled before completion
or never implemented
Project Impaired Factors
13.10%
12.40%
9.90%
8.70%
55.90%
Incomplete Requirements
Lack of User Involvement
Unrealistic Expectations
Changing Requirements
All Others

7. Success and Failure
Are we doing
something wrong?

8. Success and Failure
Are we doing
something wrong?
Or
Are we using the
wrong definition for
success?

9. A New Definition for Success
• Scope, time and cost are always changing throughout the
project to respond to reality changes or reflect a better
understanding of the needs.
• A project is considered as being successful if it delivers
perceived value to the stakeholders.
• Pleased stakeholders will ignore small delays, cost
overruns and even accept workarounds and minor
inconveniences.

10. A New Definition for Success
• Scope, time and cost are always changing throughout the
project to respond to reality changes or reflect a better
understanding of the needs.
• A project is considered as being successful if it delivers
perceived value to the stakeholders.
• Pleased stakeholders will ignore small delays, cost
overruns and even accept workarounds and minor
inconveniences.
A project is only as successful as the
stakeholders think it is.

11. Success Enablers
• Manage stakeholders expectations – goals, objectives,
requirements
• Manage project changes – based on the triple constraint
• Communicate, communicate, communicate

12. Sources of Changes
• The actual need was not
clear at project initiation.
• The needs evolved during
project execution.
• Missed requirements.
• New stakeholders /
decision makers.
• Organizational priorities
have changed.
• Environment changes.
• Legislation changes.

13. Managing Changes
• If project content is allowed to change freely the rate of
change will exceed the rate of progress.
• The ability to introduce changes in the project decreases in
time.
• The cost of introducing changes increases as more work
was already completed.

14. Managing Changes
• If project content is allowed to change freely the rate of
change will exceed the rate of progress.
• The ability to introduce changes in the project decreases in
time.
• The cost of introducing changes increases as more work
was already completed.
If changes are as sure
as death or taxes, what
can we do?

15. End-Users Satisfaction
• Traditional Change Control creates antagonistic groups:
change requesters and change approvers.
• End-users typically do not understand the “under the hood”
complexity and get frustrated by the process.
• Permanent conflict surrounding proposed changes.
• Negotiations rarely end up with win-win solutions.
• Significant time is spent in mitigating stakeholders’
expectations.
• Functional specifications, mock-ups, prototypes, interim
releases used to increase users’ confidence.

16. Enabling Project Success
• End-users need to be part of the team to achieve success.
• Users happiness is directly proportional with their ability to
exercise change.
• Change is the only constant throughout the entire project.
• Build processes based on change, not against change.
• Large teams, even in a single location, act as “virtual”.
• Remote end-users require specific processes.
• Distributed teams are the norm, not the exception.
• Use technology to cut across geographies.

17. Summary
• Project success is measured in stakeholders
satisfaction
• Enabling change ensures building what
users actually need, not what they thought
they want when the project started
• End-users are part of “us”, not “them”
• Use technology to enable distributed teams
efficiency