3 Premium Ways To Prevent IT Project Failure

By Martin deMartini, Senior Vice President, Standardization, Y Soft
martin.demartini@ysoft.com

It is an unfortunate reality most IT projects don’t end well; in fact researchers found 68 percent end up marginal or outright failures. For software-related projects, only 16.2 percent are completed on time and on budget. If you are a large organization, that number drops to 9 percent. Many never realize the promised value or ROI.

Researchers from Gartner and The Standish Group surveyed IT staffers to find out and found the top three reasons for this and the results should come as no surprise:

• lack of complete requirements (13.1 percent)
• lack of user involvement (12.4 percent)
• lack of resources (10.6 percent)

Using print management and document scan automation software projects as an example, following are three ways to prevent IT project failures.

1. Ask the solution provider to describe the framework they use for deploying their product. If the sales person has a blank look on their face when you ask about their framework, that’s a huge red flag. Experienced providers know a framework can guide the relationship from the first phone call or meeting to the conclusion of the project. In essence, the existence of a framework is a sign the project has a chance of being well managed for a successful outcome.

As the number one reason for project failure indicates, the service provider (or the company) too often does not have a firm grasp on the complete set of requirements of the project. In print management and scan automation, many different departmental staffers may have different needs. Involving the right people in the conversation is crucial. It also involves understanding the customer’s technology needs and current print infrastructure as well as the expected value and/or ROI that is expected. Above all, the framework should be documented and transparent to all involved.

Bonus: a comprehensive framework that is documented and transparent should eliminate unrealistic expectations on the timing, costs, and value the project brings.

2. Don’t underestimate the need for change communications. Most IT software projects mean a change in how the user is doing something. In addition to the psychological disruption — and for some, any change can be viewed as a major disruption — there is usually a question of why. “Why do we need to change,” followed by, “Why didn’t anyone ask me, I could have told you a better way.”

Regardless of the reason for change, change communications should begin prior to the project implementation. Depending on the change’s impact, you might consider interviewing users on the current printing and document flow processes to uncover changes that the new system might present to users. By doing this, you can also begin to communicate the reason for the change, invite user input, and demonstrate the new user benefits. Users are resourceful and, if they do not feel involved, they are likely to find ways to go around the new system or be very slow to adopt it.

This is one element of change communications. It also includes documenting all the changes discussed in meetings regarding the project.

3. Plan and then plan again — the SAD mantra. With the proper framework in place, documented change communications, and realistic planning, the term unexpected surprises should not be in your vocabulary. A properly managed project should not have any surprises — good or bad.

We operate under the SAD (Surprises Aren’t Desirable) mantra: any unexpected event, even a positive one, is not desirable. With the proper communication, agreed upon project scope and regular customer meetings, all outcomes are predictable.

While a lack of resources is cited as the number three reason for project failures, it speaks to a larger issue, that of planning. I would argue proper planning would uncover the resources necessary for a successful outcome. For example, most deployment plans underestimate the time to get executive approval and support, for getting user input, accommodating for technical customizations and the actual deployment including training and down-time of systems while the update or change is happening. Planning will also help to identify the best time to interrupt existing systems for the least impact on the business.

The likelihood of project success will vastly improve when your solution provider works within a documented, proven framework, plans properly and involves the user as part of an overall change communications plan.