Copyright 2006 John AvellanetProject delivery makes IT organizations credible. When IT
?gets it right? at the project level, its ability to impact
the financial results of a company increases and its
leadership in providing strategic direction improves. Good
project delivery is the key to unlocking the door from the
back-office to the boardroom.
And yet, according to a recent survey by Accenture, only
29% of IT projects are considered successful. The average
cost overrun is 56%; the typical delay is 84%. After
decades spent learning and implementing project management
methodologies, measurements and controls, the success rate
of IT projects is no better than when a single computer
took up an entire room.
Now, despite the need for companies in the 21st century to
innovatively embrace technology to compete, CIO?s still
find themselves hearing second-hand about their company?s
strategy while line-of-business executives embrace the ?IT
as a commodity? philosophy.
For IT to contribute to a company?s bottom-line, IT
executive teams need to ensure project alignment with
business strategy. Projects, and particularly large-scale
programs of multiple projects, need to be run flexibly,
with an eye toward the larger business picture.
The following pages present six straightforward principles
? culled from our experience with Fortune 100 companies,
ten person firms, mid-sized businesses and not-for-profit
organizations ? to turn your project into a bottom-line
success.
ONE: Use Occam?s Razor
Big projects are seductive. They are also inherently risky,
costly, complicated and come laden with poor track records.
William of Occam, a 14th century logician, wrote ?Entities
should not be multiplied unnecessarily.? Albert Einstein
restated this as ?Everything should be made as simple as
possible, but no simpler.? Apply their advice. Break up
large projects into simpler, smaller projects or phases.
Delineate each phase by its ability to provide an immediate
and direct business benefit.
This approach has five benefits:
1. Requirements are simplified. With tighter constraints,
requirements gathering quickly centers on the most crucial.
Time-box the remainder as ?nice-to-have.? Done well,
requirements will be easier to understand, have clear
connections between them, and should be easier to complete.
2. A crystal clear focus is easily achieved when working on
smaller, simpler phases.
3. A succession of success can be built by rapidly
delivering smaller project phases for people to easily see
what they are getting for their money, time and effort.
4. Smaller phases are simpler to manage, perform quality
and compliance checks on, fix, tweak or debug, and modify
as environmental factors demand.
5. Phased projects are more easily paused (or halted
altogether) as business conditions change. Personnel can
then quickly pick up other activities.
TWO: Buffer Consistently
Critical Chain Project methodology suggests minimum 20%
buffers in your project schedule. Many Finance
organizations expect a 10-15% cost buffer over initial
estimates on major projects. And in his book Slack (2001),
Tom DeMarco points out that to be their most effective,
people need approximately 20% slack or downtime during
their workday.
Ironically, many project managers set up a 20% buffer in
their schedules and a 10% fudge factor in their budgets yet
leave their people a 0% buffer. Thus, before scope ?creep?
or other project changes or problems, the chances for
success have been cut by one-third.
Tackle this head-on with third grade math: prior to
establishing a budget or plan, assume a 6-hour workday (20%
buffer) at 15 project-focused workdays a month (after
factoring in vacation, illness, holidays, company meetings,
etc.); in other words, 90 hours of project work a month per
team member.
THREE: Prioritize the Soft-Side
Because projects are run for and by people, the primary
role of the project leader is managing the ?soft? people
issues. The mistake most IT organizations make is to use
the project leader to manage schedules, track metrics,
control costs, assign resources, handling reporting and so
forth. Instead, our experience has shown that successful
project leaders focus first on five tasks:
1. Run ?interference? for the project team(s). Projects can
quickly become politically complicated. By minimizing the
impact of politics on the project team members, the project
leader reduces the risk of delay and scope ?creep.?
2. Determine the right people to be involved, from project
team members to pilot users.
3. Make the final decisions on internal project issues.
When money, time and resources are constrained, management
by committee is not conducive to tactical success.
4. Focus on specific goal-oriented completion of the
project. Projects become imbued with changes, vague
expectations, egos, etc. by project members, customers and
project sponsors. The project leader must continually ask,
?why.? Press for specific answers on how the change, the
additional goal, etc. get the project closer to completion.
Ultimately, the business needs the project completed to
reap the benefits.
5. Perform quality checks at a regular interval on the
schedule, the budget and the expectations of everyone
involved. These are not detailed-oriented checks, but
rather 10,000-foot reviews. Pick 3 random items and delve
more deeply by probing with five or more questions each.
FOUR: Communicate to Ensure Accountability
According to Labformatics, one of the top reasons that IT
projects fail is lack of responsibility over the project by
both project teams and the customers. Take a page from the
nonprofit marketplace and utilize three communication
tricks to continually draw in end-users and sponsors.
First, build a simple, no frills website focused solely on
the project itself. The site should contain the following:
? project goal(s)
? personnel involved
? timeframes (and current status)
? costs and allocations (i.e. ?coding of purchasing
interface?)
? meeting minutes
? requirements documents
? project team checklists.
You can also post the original business case as well.
Second, regularly distribute a short e-mailed newsletter
with quick 8-12 word updates and links to the project
website for more information. At minimum, the project
update must address two ever-present questions:
? ?when are we getting the business benefits from this
project??
? ?how much is it costing us??
Consider using the ?5-15? rule: the update should take you
no longer than 15 minutes to write and take the reader no
more than 5 minutes to read.
Third, set up an unstructured blog environment for the
project team members. This is critical if your project is
being worked on by virtual or remote project teams, or is
in 24-hour shift mode. The goal of the team blog is simple:
keep everyone informed.
FIVE: Apply the Pareto Principle
In the 1800?s, Vilfredo Pareto discovered that a small
portion of any activity produces a majority of the results.
Now called the 80/20 Rule or the Pareto Principle, its
application in the IT world is essential to project
success. The Pareto Principle is intuitively being applied
when you hear the phrase ?good enough.?
In essence, if approximately one-fifth of the project will
produce about four-fifths of the benefits, then identifying
the essential one-fifth of the project will allow you to
quadruple your results.
There are two techniques to determine which efforts produce
80% of your results:
1. Ask your customers and your team, ?what of our efforts
are producing most of the results for you?? Be ruthless;
eliminate or postpone every trivial task that does not
directly contribute to the delivery of the business
benefits of the project.
2. Post the project goals in your office, in presentations,
on your project website, etc., and turn attention to them
at every question or change. Ask, ?how will this improve
our delivery of the benefits of this project??
SIX: Use Two Linear Betas
All good IT projects have a beta phase. The mistake many
project managers make is to set up a group of users or IT
personnel as a beta rollout group without keeping in mind
the ultimate project goals. To improve your results, set up
two sequential beta rollouts.
Beta 1 is strictly for IT personnel who support the various
departments that will be using the system (for instance, IT
department liaisons). They will provide your project team
with a mix of real-world testing and tweaking while gaining
valuable experience and comfort with the new system.
After the project team has had a chance to address the
issues from Beta 1, set up the Beta 2 group: users from
each of those departments. Preferably, select two users
from each department, one who has and one who has not
historically been friendly to IT projects. The latter
represents the one-fifth of users that provide you
four-fifths of your results.
Final Thoughts
The more projects you complete successfully, the more
credibility you gain. Delivering high levels of business
value will bring you, and your business, the success it
deserves.
Are you ready?
----------------------------------------------------
John Avellanet is the managing director & principal
consultant of Cerulean Associates LLC, a Virginia-based IT
management & compliance consultancy focused on helping
clients improve their bottom-line results with project
assurance, program management, and IT and compliance
strategies aligned with business initiatives.
