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 Approaches
Gathering project requirements
Design the software
Write the code to implement that design
Test it
Roll it out
Two major problems:
a lot can change during the window of isolation where the programmers and users have little interaction.
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
Corporate IT projects falter at:
Fail to gain traction with their intended business users
Do not get the requirements right
Curbing scope creep
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
Accountability without micromanagement
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
What benefits?
a project’s measurable organizational value (MOV), which must come from line functions (i.e., the business side rather than the IT unit)
A MOV statement for any IT project must have:
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?