Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 7: MANAGING PROJECT - Coggle Diagram
CHAPTER 7: MANAGING PROJECT
Jargon Decoder
IT project failure
– Botched execution (flunks cost, schedule, or quality targets)
– Cannot deliver promised business benefits
Triple constrain
t: Cheap, fast, and good
80/20 rule
: 80% business needs are met by 20% of project features
Antidotes to failure
#1 Discovering latent business needs
Lean Discovery of Business Needs
Three foundational principles
of all lean methods
Lean Idea #1: Active Business Participation
C-R-A-C-K Business Team Members
• Collaborative
• Representative of biz users
• Authorized to decide
• Committed to business value
• Knowledgeable
Lean Idea #2: Short Iterations
Series
of iterative sprints,
2-6 weeks
apart
– Each iteration hands users a crude but functioning system with small subset of
functionality
– Integrally engage business users in a two-way conversation
– Marathon-> many sprints
Clears misunderstandings earlier <- cheaper to fix.
Uncovers latent needs.
– Zaps wasteful overengineering and gold-plated functionality
Lean Idea #3: Less Code
1. Software with more code is buggier
–
100-150
errors/KLOC +
50% best-case
bug squashing during testing
–
Translation
: A small (1 mil LOC) app with have
5,000+
bugs
– Bug fixing is
100 times
costlier after deployment
Lean Payoffs: Better, Faster, Cheaper
Assumes
:
Business users can’t articulate an IT project’s requirements.
Success only in their eyes
Antidote #3: Accountability without Micromanagement
Non-IT managers must hold team accountable for delivering business benefits
Four
elements:
Intended impact: Operational, strategic, or financial
Promise: Will it help do something better, faster, or cheaper
Change metric: dollars, percentages, or time
Time to impact after project completion (years/ months)
Antidote #2: Curb Scope
1 threat: Attempting too much, with too little or too fast
MoSCoW rule applied to requirements by non-IT managers:
–
M
ust-have
–
S
hould-have
–
Co
uld-have, but not critical
–
W
ont-have this time, but maybe later
Causes of failure
:
Imprecise business intent
Unnecessary complexity
Lack of explicit tradeoffs
A Dismal Track Record
Two of three IT projects fail
-
Half
never deliver intended
business
benefits
Larger
projects are
5-10 times worse
-Afflicts small and large firms, non-profits, and governments
worldwide
Problems
that derail IT projects are often
predictable and preventable
Previous Project
Suez Canal (1854-)
• 17,000 ships
• 1,000 million tons of cargo each year
• Egypt’s share: $6 billion a year
Lessons for IT projects
:
• “Obvious” technical merits on paper don’t get a project used
– Suez: Pirate-free, shorter, cheaper trip
• Expect no payoff until it’s used
London Electrobus II
•
100 years before Telsa
– Well engineered, 38-mile range, and ingenious battery swaps
– Gas engine was not yet inevitable; competition was horse buggies
•
The buses were
– 300% over budget, 3,000-pound battery, and 30/50 never completed.
– Cost, quality, and schedule <-flunked all three
Lessons for IT projects:
Simultaneously counting on
too many unproven technologies
risky.
Clever technology does not guarantee success
– A project
must outdo its real competition
<-not always obvious
– Electrobus: Not the automobile
but the horse
Doomed without complements (then and now, charging stations)
Hoover Dam (1930s)
• Completed two years early and under budget
• Managers created master plan but gave engineers discretion over their
work
• Lesson for IT projects:
Micromanage what but not how
Why Non-IT Managers Matter?
Good IT project management increasingly indistinguishable from
good business management
• Invariably has an IT
element
– Any strategic move
– Business model tweak
– Process improvement
IT project managers skilled at managing technical risks
• Only non-IT managers can prevent their
business
failure
– Under-delivering intended
business
benefits
– IT project managers ill-equipped to tackle this
• Non-IT managers’ contributions ->
the right system faster and
cheaper
Business Failure That Must Prevent
#1: Ambiguity of Purpose
Poor biz-IT communication = the
wrong
system
– Rarely faulty execution
• Latent needs
– For example: the RAID story
– Need that’s present but not yet visible
• IT cannot build what you don’t ask for
– Leads to feature-bloated, kitchen-sink over-engineering
– antidote comes solely from non-IT managers
• The cardinal sin is non-IT managers not articulating a
business
goal
#2: Unnecessary Complexity
• Cause:
Ballooning scope
<- one system tries to do too much
• As a project gets larger…
-Defects rise in proportion
– Integration problems compound
– Becomes incomprehensible to any one person
#3: Not Explicitly Choosing Tradeoffs
• A failure to make
one tradeoff
—fast, cheap, or good—explicit
– Trying to achieve all three often achieves none
• Non-IT managers must pick one to give up
– Driven by a project’s business objectives
– If time and money are scarce, curb scope
Rollout Strategies
2 Risks Beyond Non-IT Managers’ Control
Use of
immature technology
in a project
– Uncertainty not equal to ambiguity
– PM only tackles ambiguity but uncertainty requires real options thinking
Underestimation of time
and money
-Smaller commitments more likely to be approved
-Estimation is more an art than science
