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
Antidote 1: Discovery of Purpose
IT projects traditionally follow a sequence of activities i.e. “Waterfall” Approach.
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.
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.
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 (i.e., at 1 before the shaded steps in begin). 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.
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.
Antidote 3: Accountability without Micromanagement
The third contribution from non-IT managers is holding the project team accountable
for delivering desirable business benefits.
Many IT projects falter in the second aspect when non-IT managers are not
involved at a few critical junctures.
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?
Such benefits are a project’s measurable organizational value (MOV), which must
come from line functions (i.e., the business side rather than the IT unit).
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.
A 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?
Details of how you will achieve the MOV do not belong in the MOV statement. If a
project’s entire MOV cannot be expressed in one line, its scope is too scattered. Try making your project MOV pass the tweetability test by fitting it into a short sentence structured as follows.
Project X will <promise> <targeted impact> by <change metric> within <time>.
Good example: Project X will increase inventory turnover in our US stores by 1.6 days within two years.
Antidote 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.
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.
The tricky question is which 20%? Non-IT managers can help identify the 20% by classifying each major project requirement into one of the following four categories, colloquially called the 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.