|
The successful design, development, and implementation of information technology
(IT) projects is a very difficult, complex, and, at times, daunting process. However,
although developing IT projects can be difficult, the reality is that a relatively small
number of factors control the success or failure of every IT project, regardless of its
size or complexity. There is nothing esoteric about those factors. The problem is not
that the factors are unknown; it is that they seldom form an integral part of the IT
development process.
Of course, the recognition and management of these factors does not ensure IT
project success. Understanding the factors and the part they play in successful
project management is one thing; appropriately managing them is something else.
In addition, there is a high potential for project failure in not recognizing the part
these factors play, or failing to appropriately manage them.
If these factors are so clearly important and well-known, why do they not form an
integral part of every IT project? The short answer is that they should. The issue
here is that because they are not used, too high a number of IT projects suffer some
degree of failure.
The phrase “IT project failure” often raises a specter of some colossal failure. For
example, the project never goes operational, or it is abandoned in midstream after
considerable expense. In addition, there are other, qualified IT failures, such as
projects that exceed their development time and expense estimates, but ultimately
become operational. There are also many projects that move to production status,
but do not meet the expectations of internal customers as defined in the project
specifications. And projects may be considered failures if the applications take too
long to process the data, or if they regularly fail in the operational environment.
In short, many organizations do not have a particularly good track record in IT
project success. However, many IT project failures can be eliminated or mitigated by
understanding and managing the nine project failure factors described in this article.
These factors should be recognized for the strength they can bring to every project,
and accorded the attention they deserve.
THE NINE FACTORS
The following nine factors can and do make or break IT projects:
1. Appropriate senior management levels of commitment to the project
2. Adequate project funding
3. A well-done set of project requirements and specifications
4. Careful development of a comprehensive project plan that incorporates
sufficient time and flexibility to anticipate and deal with unforeseen difficulties
as they arise
5. An appropriate commitment of time and attention on the part of those outside
the IT department who have requested the project, combined with a
willingness to see it through to the end
6. Candid, accurate reporting of the status of the project and of potential
difficulties as they arise
7. A critical assessment of the risks inherent in the project, any potential harm
associated with those risks, and the ability of the project team to manage
those risks
8. The development of appropriate contingency plans that can be employed
should the project run into problems
9. An objective assessment of the ability and willingness of the organization to
stay the project course
The reader will realize that none of the factors has anything to do with technology. In
addition, all the factors are straightforward, and can be easily understood by anyone
with a business backgro und.
Organizations that recognize and work to appropriately include the nine factors in IT
project development are taking an important step in moving to more consistent IT
project success. However, they will have to do more than recognize the factors’
importance. They must also understand the interlocked nature of the factors, which
together form a mosaic of strong project management. If IT project success is to
improve, the role and importance of each factor must be understood. A discussion of
each of the factors will provide information about how they affect IT projects.
1. SENIOR MANAGEMENT COMMITMENT
When it is clear that a particular IT project has the interest, the support, and the
commitment of the organization’s senior management, everyone involved in the
project will have a sharper focus. Almost all IT projects are expensive. In addition,
these projects present opportunities — some of them significant — that foster
organizational success. Poorly done projects can hamper the organization’s success;
some can even put the organization in jeopardy. Therefore, it is imperative that the
senior managers responsible for the areas affected by a particular project become
and remain involved. If, as often happens, the process is completely left to the IT
depart ment, the project is in trouble.
There are numerous examples of IT projects that have considerably benefited an
organization. There are also many examples of IT project failures that have seriously
disrupted an organization’s business. Beyond the issue of total IT project failures,
there are IT projects that are not true failures, but are less than successful. Those
projects never deliver what was originally promised and are sometimes simply
abandoned.
IT projects are sometimes conceived, funded, and built without appropriate seniorlevel
review and involvement. This should not be seen as a failure on the part of
senior management to approve a given IT project. In virtually all organizations,
senior management approval is mandatory when a project reaches a certain funding
level. In the majority of failed IT projects, such approval was undoubtedly granted at
a high organizational level. Therefore, the issue is not that IT projects go forward
without appropriate approval, but rather that the approval is too often automatic.
All too often, senior management approves IT projects that carry potentially serious
consequences for the enterprise, without clearly understanding the organization’s
exposure or risk. Of course, one can argue that IT management is obliged to
properly inform senior management of the project’s potential downside. However, in
the euphoria of getting the project approved, the project’s risks may be ignored or
glossed over. In fact, some organizations have a repeated pattern of project proposal
and subsequent failure, yet senior management remains aloof.
There is an important distinction between approval of and commitment to an IT
project. In IT projects that encounter difficulty, there is usually some point at which
members of senior management become involved, and their attention and
commitment are in place. However, this often happens at the wrong end of the
project.
IT projects beyond a set funding level, which varies by organization, should never be
seriously considered without senior management’s clear understanding of the
project’s perceived difficulties, risks, and benefits. Too many IT projects gain
approval based upon hype and an unrealistic calculation of the potential benefits.
Thus, senior management, with or without an IT background, should probe for the
facts. The project should be abandoned, or at least halted, until their questions can
be satisfactorily answered.
2. ADEQUATE PROJECT FUNDING
IT projects often require heavy financial investments if they are to be successful.
However, ample project funding is not in and of itself a panacea; access to large
sums of money does not ensure IT project success. Conversely, inadequate project
funding will lead to delivery of less than promised, if not outright failure.
Organizations must recognize that the time, hardware, software, and people
components that make up an IT project are expensive. They should therefore devote
ample time and attention at the project’s beginning to analyze and apply realistic
costs to the components. Although good project expense analysis may not produce
complete figures, the process should provide a reasonable understanding of the
expense associated with the project. Once a set of realistic figures is produced, the
organization should also build a reasonable amount of contingency funding into the
estimated project cost.
IT project funding should be seen as a continuing and flexible process. While a
reasonable estimate of project expense must be made to obtain initial approval, this
figure should not be considered the final project cost. After all, changes will be
incorporated into the project plan as it goes forward. These will undoubtedly involve
added functionality, which will in turn translate into increased project cost.
As the project moves forward, its implications will be better understood. As the true
scope of the project is revealed, the project manager can more accurately identify
project expenses. Therefore, costs must be recalculated at several checkpoints in the
project life cycle, and the new figures communicated to senior management.
Senior management should view the changing project costs in a positive light,
although they are more likely to rise than to fall. This is because a discussion of the
changing expense offers senior management an opportunity to probe why the
estimates changed. For example, the project sponsors might have requested
additional functionality, which increased the cost. At this point, senior management
has an opportunity to decide whether or not they want to fund these additional
project expenses or forego the added functionality. Otherwise, there is often de facto
approval of increased functionality (and project expense), without senior
management involvement.
Without interim project expense reviews, additional functions are often added,
raising project expense, but such additions are not revealed until the project is
completed, if ever. In addition, interim estimates provide an opportunity to reduce
the project scope, if necessary, to bring the cost to a more desirable level. This
might entail extending the project’s installation date, abandoning parts of the project,
or curtailing some of the features. Whatever the result of the project review, it
presents an opportunity to make project-expense-related adjustments in a
businesslike manner.
3. WELL-DONE REQUIREMENTS AND SPECIFICATIONS
It is absolutely critical to the success of any IT project that the organization develop
a clear understanding of what will be delivered and what will not be delivered within
the project’s scope. In fact, it is not unusual for the people who requested the
project to raise issues part way through it about functions that are not to be
delivered.
This sparks arguments between the project sponsors and the members of the IT
department, who both seek to assign blame for the apparent oversight. It represents
poor development work to make assumptions about inclusion or exclusion of items in
an IT project, and is bound to create confusion and disappointment, if not serious
project disruption.
Even if there are well-thought-out and documented project requirements and
specifications, unforeseen events will arise as the project moves forward. Sometimes,
minor additions can be made to the applications, requiring little time and expense.
However, the lack of inclusion of major items can render the project inoperable.
When this happens, there are two unattractive options. The project can be reworked
to include what was overlooked, which is likely expensive and time consuming, and
shows the IT department in an unfavorable light, even if it was not responsible for
the oversight. The other option is to abandon the project.
Not only must the project-related requirements and specifications be complete, they
must be reviewed by people familiar with the business issues the project is to
support. This review must be careful and thorough, to avoid subsequent IT
development difficulties.
All too often, when it is found that additions must be made to the requirements and
specifications in the later stages of the project, a workaround is attempted. In
addition to the time and expense of such a solution, it often does not work, or does
not work well. And, while strong project management requirements and
specifications do not ensure project success, they add considerably to the probability
that the project will succeed.
4. A COMPREHENSIVE PROJECT PLAN
IT project planning is not a waste of time, although many believe it is. In fact, there
is a very strong correlation between the length of time allocated to project planning
and the project’s ultimate success. Granted, IT planning can be overdone, but IT
installations seldom exhibit excessive attention to planning.
There are three benefits to be gained from strong project planning. First, planning
allows the planners to present a clear, well-documented, properly focused
understanding of the project. Second, the planning process raises questions that
would not otherwise be considered. There is often a rush to begin the project without
an adequate understanding of what will be done or the ramifications of the work.
The third planning benefit is that it builds confidence in the project and its processes.
As a result, when planning is finished, it is easier to confidently begin the project. In
a well-done versus a poorly planned project, then, the transition from project
concept to delivery will be easier and faster. Appropriate project planning is a
function of an organization’s strong IT project discipline. To succeed, IT management
must make it clear that planning is an important component of project management,
and that the required planning must be completed and approved before the project
moves forward.
5. COMMITMENT OF STAKEHOLDERS
The track record is poor in organizations where responsibility for IT projects rests
with the IT department. In fact, IT projects are, with limited exceptions, developed
and operated to meet the organization’s business needs and interests, rather than
those of IT. The organization is poorly served when people outside the IT department
can dissociate themselves fro m projects in which they have a vested interest.
Sometimes, IT projects of significant size are completed with virtually no internal
customer involvement. Their attitude might well be, “Show me the results when the
project is done.” If and when projects of this type are finally installed, they rarely
meet internal customers’ needs.
IT department managers should realize that IT has a vested interest in developing a
process that ensures strong internal customer involvement in its projects. A lack of
customer involvement virtually ensures eventual customer dissatisfaction with some
project aspect. If IT managers cannot get customers to share project ownership,
they set themselves up for eventual customer criticism.
Therefore, IT should not initiate or install any projects without the complete support,
involvement, and attention of the appropriate internal customers. It represents a
failure on the part of senior management if internal customers take no project
responsibility, yet complain about the project’s content and performance once it
moves into production.
Because business projects warrant the investment of large sums of IT time, effort,
and money, they should warrant a comparable investment on the part of the internal
customers who requested the project. It is senior management’s responsibility to
make certain that everyone affected by a particular IT project has a share in the
project’s ownership.
It will require fortitude on the part of the IT management team to halt development
of an IT project due to a lack of internal customer involvement. However, this is the
correct approach; otherwise, IT is exposed to excessive risk.
6. PROJECT STATUS REPORTING
It is not enough to simply provide regular project status updates; these updates
must be accurate. In fac t, IT project status reports are often overly optimistic. While
it might be more comfortable for departments to believe that steady project progress
is being made, it is more important that the reported status is realistic. IT projects
routinely fall into difficulty. One cause is in the failure to accurately report the real
project status in a timely fashion.
IT might provide inaccurate project reporting in the usually mistaken belief that lost
ground will be regained as the project moves forward. After all, no one will be the
wiser when the lost ground is made up and the project is back on schedule. However,
it is almost universally true that once a project falls behind, the situation will only get
worse without high-level involvement. And senior management will not provide the
needed help as long as it thinks things are going well.
As early in the project as possible, project status reporting should identify adverse
issues, as well as recommend how the difficulties can be overcome. Of course,
candid project reporting can create tension for both the project team and the
customer areas. Some degree of tension is desirable, because it will cause people to
consider issues early on which otherwise might not arise until later in the project.
And, while dealing with IT project problems and tensions can be difficult, ignoring
them will only make them more difficult.
Members of IT projects typically postpone the delivery of bad news, such as a delay.
When this happens, senior management might be alerted to the problem by some
other area, or the project manager might have to reluctantly admit to the project’s
delayed status. Both scenarios have a negative effect on senior management, on
everyone involved in the project, and on the project itself.
7. CRITICAL RISK ASSESSMENT
An organization’s senior management should complete and publish a careful analysis
of the project’s risks before it seriously considers approval. It is not enough to
recognize that the project has some risk, or to have a vague idea of some of the
possible project-related risks. Risk, as it applies to a particular IT project, must be
well-understood. More importantly, those who will suffer from the project-related
risks must be made as aware of them as promptly as possible.
Identification of project risk falls into two categories: the more usual and obvious
risks, and the risks that will be generated based upon the functions and
requirements of the particular project.
Usual and obvious project risks include:
§ The use of software that is new, or at least new to the organization.
§ The organization’s level of IT skill and knowledge. Obviously, a seasoned,
well-trained group of IT professionals will be more likely to master the project
development than less experienced people.
§ The track record of the IT department in successfully managing IT projects. IT
departments that have a strong development track record bring less risk to a
project, regardless of its size and complexity, than an organization with a
poor development record.
§ The size and complexity of the proposed project.
§ The willingness of the organization to properly fund the project.
§ The level of trust and respect between the IT members of the project team
and the internal customers on the team.
Risks associated with the particular project’s functions include:
§ The perceived importance of the project to the business of the organization.
Obviously, an IT project that carries heavy business implications will present
a considerably higher risk level than upgrading an existing system.
§ The ability and willingness of those outside the IT department who have
requested the project to become and remain involved throughout the life of
the project. In projects where the assistance of outside vendors is required to
bring the project to a successful completion, the level of dependency on that
vendor must be calculated and managed. The willingness and ability of the
vendor to perform as expected must be seriously considered. In addition,
circumstances within vendor organizations change. For example, part way
through the project, the vendor might decide to abandon the line of hardware
the project is using. Alternatively, a competitor might buy out the vendor,
lowering the vendor’s level of project support. Finally, the vendor might just
go out of business.
§ The quality of the project requirements and specifications. The higher the
quality of that work, the more probable the project will be a success.
§ The possibility of the loss of a key person on the project, either from IT or
from the internal customer side. If that person alone has knowledge critical to
the project’s success, his or her loss could deal the project a fatal blow.
Every IT project presents its own set of risks. A businesslike approach to project
management requires carefully considering and addressing these risks with internal
customers and senior management as part of the project’s approval process. If the
risk analysis leads to a decision not to move forward, it is much better for everyone
involved that the decision is made sooner, rather than later.
8. PROJECT CONTINGENCY PLANS
As a project moves forward, difficulties might well arise. Although the organization
might be highly confident that the project will succeed, it is prudent to consider the
possibility of some type of failure. Because such a possibility exists, the organization
should put a plan in place to overcome difficult situations if they should arise.
Some examples of IT project contingency planning include:
§ Recognition that the planned level of hardware resources to support the
project may prove inadequate when it is moved into production. One of the
common failings of IT projects, particularly in client/server environments, is
disappointing processing performance when the applications move to the
production environment. Although the hardware plan might seem adequate,
that might not be the case. Therefore, the project plan should have a
provision to increase hardware resources should the need arise. In addition,
senior management should be advised of this possibility.
§ Anticipation of “surprise” additions to the project’s functionality as it moves
forward. Too often, part way through a project, the project must incorporate
items that were overlooked, or changes in the business needs associated with
the project. This means schedule delays (with talk of “phase two”), and
additional project expense. In addition, other projects may be delayed, and
business initiatives dependent upon the successful completion of this project
may be delayed.
Project surprises are always a possibility, despite a strong set of project
requirements and specifications. It should therefore be a mandatory part of the
development process to recognize this possibility and raise the issue with the
appropriate people.
When an IT project is of paramount importance to an organizatio n, it makes good
business sense to consider the possibility of delay. In addition, an attempt should be
made to construct a plan to work around this eventuality.
Developing a project contingency plan should be linked to the issues of project
planning and project funding, as addressed earlier in this article. However, while
appropriate planning will identify many of the issues that may arise and that should
be built into the project, no amount of planning will anticipate everything that might
happen. If funding is flexible, senior management will already realize the possibility
of additional expense.
Obviously, the ideal is to generate a plan, the first time around, that is absolutely
precise with regard to expense and functions. However, that is virtually impossible in
a project of any magnitude. Believing that such a process is viable represents one of
the fundamental causes of IT project difficulty.
9. A WILLINGNESS TO STAY THE COURSE
All IT projects face some level of difficulty, and much of it can be mitigated through
sound management approaches. However, problems must be anticipated. As they
arise, people will try to find ways to reduce the pain associated with the project. At
this point, pressure will likely build to modify the project.
Some of the suggestions for doing so include:
§ A reduction in the features to be delivered. A phased approach to the project
can be introduced, designed to shift parts of the project from the current
schedule to some (often poorly defined) future date.
§ An approach that proposes that flaws or problems in the system be fixed by
some workaround process. This process offers a solution to the current
problem, but will often do less than what was specified in the original project
plan. The idea is that the problem should be fully and correctly repaired, but
there is no time to do that work now. The workaround is usually accompanied
by a promise to return to the problem at some later date and make things
right. When this occurs, the chance of correcting the problem at some later
date will be close to zero.
§ A willingness to reduce testing standards and controls to meet project
deadlines. Again, the stance is to wait to fix testing-related problems so that
the schedule is met.
§ Abandonment of the project.
§ Obviously, if a project is in difficulty, some steps must be taken to correct the
situation. These steps, and their ramifications on the entire project, should be
carefully thought out and considered. It is important that everyone involved
in the project realize that if there are project difficulties, there may be
pressure to adjust the original plan. The plan should be flexible enough to
allow adjustment, if needed. Organizations must avoid overreacting to
problems and adapting the wrong approach to solving them.
Those responsible for the project’s ultimate success within the IT department should
ensure the continuing support of the organization’s senior management for the
project. If the project is of sufficient importance to be initiated, it should be
adequately supported if things should go wrong. In obtaining senior management
support, project managers must be willing to present an accurate picture of the
potential difficulties inherent in the project. Insofar as is practical, senior
management must be given a realistic assessment of the potential for difficulty and
be willing to stay the course if things go wrong.
CONCLUSION
It is impossible to identify and manage all the potential difficulties and ramifications
associated with IT development projects. The larger the project, the greater the
probability of unforeseen difficulty. In large IT development projects, it can become a
massive task to coordinate the various teams working on the project.
If organizations attempted to find and resolve all project difficulties and potential
difficulties, it would keep projects from moving forward; this is sometimes referred
to as “analysis paralysis.” This chapter does not strive for perfection. Rather, it tries
to raise the awareness in IT installations and with the internal customer community,
that the better prepared everyone is going into a given project, the greater the
likelihood of a successful project.
While no one wants to be involved in an IT project that is less than successful,
virtually every organization has project failures. If available, methods should be
implemented to alleviate some of the difficulties and, as a result, improve the levels
of IT service and customer satisfaction.
Of course, the nine factors outlined here create more work. However, this additional
workload need not be a burden if the factors are understood and realized. When an
organization incorporates the nine factors into the normal IT project development
processes, the work required becomes less of a burden. If a relatively small amount
of extra time and effort can improve IT projects and increase internal customer
satisfaction, it is a small price to pay. | 
Disclaimer
