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
Discover a project’s true business purpose
“Waterfall” Approach
Begin by gathering project requirements, then design the software (including its architecture), then write the code to implement that design, test it, and finally roll it out. The shaded part is the territory of IT specialists
Many corporate IT projects falter at these two points; they either don’t get the requirements right or fail to gain traction with their intended business users.
Two major problems of “Waterfall” Approach
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.
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.
The waterfall approach lacks the flexibility to hit a moving target and the mechanisms to incorporate feedback. The completed project then meets the business needs that the firm once possibly had in the past, not the ones it now has. This inflexibility can lead to a project’s obsolescence before completion.
Curbing scope creep
Threat: Attempting too much, with too little or too fast
You can 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
Which 20%?
MoSCoW rule applied to requirements by non-IT managers:
Must-have
Should-have
Could-have, but not critical
Wont-have this time, but maybe later
Must-do versus may-do in real options lingo
Accountability without micromanagement
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?
A MOV statement for any IT project must have 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)
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.