Please enable JavaScript.
Coggle requires JavaScript to display documents.
Antidotes to Business Failure of IT Projects - Coggle Diagram
Antidotes to Business Failure of IT Projects
1.Discovery of Purpose
IT projects traditionally follow a sequence of activities i.e. “Waterfall” Approach
gathering project requirements
design the software (including its
architecture)
write the code to implement that design
test it
finally roll it out
Many corporate IT projects falter at these two points
they either don’t get the
requirements right
fail to gain traction with their intended business users.
Two major problems of “Waterfall” Approach
First, the waterfall approach erroneously assumes that a project team can identify
business users’ latent needs at the outset
The project team is likely to give the users what they asked for but not
necessarily what they needed
Second, a lot can change during the window of isolation where the programmers
and users have little interaction
If a new requirement is discovered during the window of isolation then the waterfall approach requires redoing which may cause
huge cost.
2.Curb Scope
The biggest threat to IT projects almost always is trying to do too much, often too
fast or with too few resources.
tame a project’s scope by using the 80/20 rule, the heuristic that 20% of a
project’s features can meet 80% of its business needs.
Non-IT managers can help identify the 20% by
classifying each major project requirement into one of the following four categories
MoSCoW classification
Must-have requirements
Should-have requirements
Could-have requirements, but not critical
Won’t have this time, but maybe later
The must-have requirements are the 20% requirements that a project must
prioritize
Such prioritization focuses the project team and ensures that line
functions do not make impossible demands
3.Accountability without Micromanagement
Non-It managers must hold team accountable for delivering business benefit
There are two ways to judge a project’s success:
Was it executed well in terms of it schedule, budget, and quality?
Did it deliver the desired business results— measured by an operational business
metric?
Many IT projects falter in the second aspect when non-IT managers are not
involved at a few critical junctures.
The third contribution from non-IT managers is holding the project team accountable
for delivering desirable business benefits
Such benefits are a project’s measurable organizational value (MOV), which must
come from line functions
Begin with the intended impact and emphasize desirable outcomes, not features
Any
MOV statement deserves a cold,hard look at how it will further your firm’s
operational strategy.
This value has to be measurable and to your organization
MOV statement for any IT project must have four elements
Intended impact. What operational, strategic, or financial impact will the project
have?
Promise. Will it help do something better, faster, or cheaper?
Change metric. What is the unit for measuring impact (e.g., dollars, percentages,
or time)?
Time to impact. What is the time to impact after project completion, measured in
years or months?
Good example: Project X will increase inventory turnover in our US stores by 1.6?days
within two years
Bad examples: Project X will?.?.?.
create ubiquitous new channels to target mobile customers through real-time
analytics.
strengthen our ability to deliver an industry leading experience to customers.
lower distribution costs by 10%.
lower IT costs by 10?percent by rationalizing our global platform.
implement the Obamacare law.