Please enable JavaScript.
Coggle requires JavaScript to display documents.
MANAGING PROJECT - Coggle Diagram
MANAGING PROJECT
ANTIDOTES TO BUSINESS FAILURE OF IT PROJECTS
DISCOVER A PROJECT'S TRUE BUSINESS PURPOSE
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
approach erroneously
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
lot can change during the window of isolation
the programmers and users have little interaction
requires redoing which may cause huge cost.
:The waterfall approach lacks the flexibility
This inflexibility can lead to a project’s obsolescence before completion.
LEAN PRINCIPLE
Lean Principle #1: Active Business Participation
actively involving throughout the project.
Prioritizes what they actually need, such as their latent needs
Should converge business users’ objectives
Combination of Business users and IT project team
Collaborative
Representative of users in their line function
Authorized to make decisions
Committed to delivering business value
Knowledgeable of their line function’s operations and business processes
Lean Principle #2 : Short Iteration
Do the project in a series of iterative sprints of two to
six weeks each.
Series of iterative sprints
2-6 weeks apart
Each iteration hands users a crude but functioning system with small subset of functionality
Engage business users in a two-way conversation(a constructive conversation with the project team)
Marathon ➡️ many sprints (This analogous to breaking a marathon into a series of 100m sprints)
Short iteration increase an IT project’s likelihood of delivering business benefits in 2 ways:
Clears misunderstandings earlier ⬅️ cheaper to fix
Uncovers latent needs
Lean Principle #3 : Less Code
principle bakes quality in and curbs costs in two ways:
Software with more code is buggier
The cost of fixing an error is about one hundred times greater after the software has been deployed.
For example, Toyota’s 2009 braking software glitch cost the company around $10?billion in repair costs.23
systems with less code are less buggy and cheaper to maintain.
Less code lowers upfront development costs
run between $15 to $40 per line of code.
Implemented using the 80/20 rule and short iterations
CURB SCOPE
The biggest threat to IT projects almost always is trying to do too much
tame a project’s scope
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
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.
prioritization focuses the project team
ensures that line functions do not make impossible demands.
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.
contribution from non-IT managers is holding the project team accountable for delivering desirable business benefits.
benefits are a project’s measurable organizational value (MOV)
must come from line functions such that the business side rather than the IT unit
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?
Begin with the intended impact and emphasize desirable outcomes, not features
ROLLOUT STRATEGIES
Direct cutover is the fastest
old system that is being replaced (if there is one) is simply turned off
the new one simultaneously turned on the rollout date.
The risk is that any bugs
or glitches in the system can have a widespread impact.
Technology glitches often lurk
Direct cutover is appropriate if the old system is unusable
Parallel rollout
the old and new system are simultaneously available to users
the old one is subsequently turned off on the rollout date.
approach provides a safety net for technology glitches
prolongs the rollout period
requires reconciling data from the overlapping period between the old system to the new system.
A phased rollout approach
introducing the new system in less-overwhelming
bite-sized chunks of functionality
phased rollout is preferable
business pressures to get a new system quickly up and running can make it less feasible.