CHAPTER 7

Antidotes to Business Failure of IT Projects

Antidote #1: Discover a project's true business purpose (Discovery of Purpose)

Antidote #2: Curbing scope creep (Curb Scope)

Antidote #3: Accountability without Micromanagement

Waterfall Approach

Lean Principle

Rollout Strategies

Direct cutover is the fastest

Parallel rollout

A phased rollout approach

takes the parallel rollout one step further, gradually introducing the new system in less-overwhelming, bite-sized chunks of functionality.

the old system is being replaced (if there is one) is simply turned off & the new one simultaneously turned on the rollout date

although it preferable, business pressures to get a new system quickly up & running can make it less feasible

where the old & new system are simultaneously available to users for an extended period & the old one is subsequently turned off on the rollout date.

provides a safety net for technology glitches

it prolongs the rollout period

requires reconciling data from the overlapping period between old system to new system

risk: any bugs/glitches in system can have a widespread impact

technology glitches often lurk even if completed projects are pilot tested with a small group of actual users.

direct cutover is appropriate if the old system is unusable & if the new system is not mission critical to your firm's core operations

2 major problems of Waterfall Approach

STEPS: gathering project requirements - design the software (including its architecture) - write the code to implement that design - test it - roll it out.

many corporate IT projects falter at these 2 points:

don't get the requirements right

fail to gain traction with their intended business users

erroneously assumes that a project team can identify business users' latent need at the outset

a lot can change during the window of isolation where the programmers & users have little interaction

the project team is likely to give the users what they asked for but not necessarily what they needed

if a new requirement is discovered during the window of isolation, then the waterfall approach requires redoing which may cause HUGE COST

the biggest threat to IT projects almost always is trying to do TOO MUCH, often TOO FAST or with TOO FEW resources.

tame scope using 80/20 rule

MoSCoW classification

Should-have requirements

Could-have requirements, but not critical

Must-have requirements

Won't have this time, but maybe later

Non-IT managers must hold team accountable for delivering business benefits

a project's measurable organizational value (MOV) must come the business side

collaborative, involving all project stakeholders

ensures IT folks are evaluated first as business people

must balance what's ideal & realistic

4 elements:

Promise: will it help do something better, faster / cheaper?

Change Metric: dollars, percentages/ time?

Intended impact: Operational, strategic / financial

Time to Impact: after project completion (years/months)

Lean Idea #1: Active Business Participation

Lean Idea #2: Short Iterations

assumes 1: business user can't articulate an IT project's requirements // 2: success only in their eyes

Lean Idea #3: Less Code

to reduce the amount of software code in system

less code principles bakes quality in & curbs in 2 ways:

  1. Software with more code is buggier
  1. Lesser code lowers upfront development costs

to do project in a series of iterative spirits of 2 - 6 weeks each

integrally engage business users in a two-way conversation ( a constructive conversation with the project team)

marathon - many sprints

each iteration hands users a crude but functioning system with small subset of functionality

is actively involving through the project

CRACK characteristics:

Authorized to make decisions

Representative of users in their line function

Collaborative

Knowledgeable of their line function's operations & business processes

Committed to delivering business value

Lean or Waterfall?

The success rate triples if they are broken into smaller projects, where the benefits of lean approaches also become pronounced.

the lean approach- appropriate for custom-build business apps and for software embedded in products

the waterfall approach- appropriate for projects with clearly definable, stable requirement & proven technologies or in projects of large scale

Most IT infrastructure projects & implementation of purchased commercial apps are leading candidates for USING THE WATERFALL APPROACH.