Projects frequently fail in businesses. Here are seven common reasons why IT projects fail and how you can avoid these pitfalls.
Having projects that fail is common in businesses. In one 2018 study, the Project Management Institute surveyed more than 5,500 companies and found that 15% of the projects they started failed. And these failures were costly — 9.9% of every dollar invested was wasted due to poor project performance.
Learning from other teams’ mistakes is one way to avoid failed projects. Here are seven common reasons why IT projects fail and how you can avoid making the same mistakes:
- Undefined Deliverables
While most project teams define the objectives for their IT projects, some teams do not define the projects’ deliverables. A common reason for this oversight is the belief that objectives and deliverables are referring to the same thing.
While objectives and deliverables are closely related, they are not synonymous. The objective describes what a team plans to accomplish with its project. Deliverables are things (e.g., reports, plans, processes, products) that the team will produce to enable the objective to be achieved. For example, suppose a project’s objective is to replace old printers with ones that will better meet the business’s needs. The deliverables might include a report detailing current and projected printer usage needs, an analysis determining whether it is best to buy or lease the printers, evaluations of at least three printer suppliers, a signed contract, installation of the printers, a training program for employees on how to use the new printers, and so on. A larger project might need separate objectives and deliverables for each phase in it.
Because deliverables often build on each other, they provide a roadmap that the team can follow to achieve the project’s objective. Deliverables also help the team more accurately estimate the time, resources, and funding needed to complete it.
- IT Project Too Large
Tackling IT projects that are too large in scope is a common reason why they fail. Large projects require large amounts of time, money, and resources to complete — all of which might be in short supply, especially in small and midsized businesses.
It is important to note that an IT project might start out with a manageable scope, but then “scope creep” sets in. For instance, if a team is working on developing an intranet site for employees, having an ever-growing list of “must-have” and “nice-to-have” features might expand the project’s scope to the point where it is unmanageable. While changes to a project’s scope are sometimes necessary, they should be kept to a minimum. Significant changes might necessitate the need for the team to revise its deliverables, schedule, and budget.
- Unrealistic Schedules and Budgets
Sometimes, teams do not realize how much time or money will be required to complete IT projects. Other times, they are simply too optimistic.
Not taking the time to get accurate estimates of how much time and money a project will require can result in projects being late and overbudget. Even worse, it could lead to poor-quality deliverables. If a project’s schedule is unrealistic, people might rush to get things done or take shortcuts. Similarly, people might cut corners if a project’s budget is too small.
Having well-defined deliverables will help in the creation of realistic schedules and budgets. It’s important to build in a little extra time and money, though, in case any surprises pop up.
- Not involving the Right People
An IT project can run into trouble if the people involved do not have the necessary skills and knowledge. For example, having a technician head a project because he is knowledgeable in the project area can lead to failure if that person has no experience in managing projects or teams. Conversely, if no one on the team is knowledgeable about the latest IT technologies, the team might not consider a technology that could potentially be a good fit for the company.
It is important to make sure that each person involved in the project is capable of completing their assigned role. It is also important to make sure that at least one person on the team has sufficient IT knowledge in the project area. If no one in the company has the necessary know-how, the team should consider bringing in an outside expert.
- No Central Repository for Communications
For a project team to be successful, its members must be able to communicate effectively with each other and with other people inside their companies. To do so, they need good communication skills as well as effective communication tools.
Besides holding team meetings, project team members often use email to communicate with each other. While this is an effective tool, the emails are stored in the members’ inboxes, making it hard for other people (e.g., a new team member) to access the information discussed in them. Plus, if a team member forgets to copy the entire team on an email, some people might be inadvertently kept out of the loop.
A better approach is to have a central repository for project communications. This could be as simple as having project members store copies of their project-related emails in a shared folder on the company’s network. Ideally, though, teams should use collaboration software that enables them to communicate and collaborate with each other and that stores their communications and work in a central location.
- Not Monitoring and Tracking Progress
It is important monitor and track a project’s progress in terms of deliverables met, costs, and schedule. If a team fails to do so, a small glitch could turn into a big problem later on.
While manually monitoring and tracking a project is possible, it would be time-consuming. A better solution is to use project management software. That way, the team will always know exactly where the project stands and how much time and money has been spent on it thus far.
- Not Enough Testing
IT projects often include deliverables such as IT systems and IT products. Failure to thoroughly test these types of deliverables can result in their failure once they are implemented.
The team should not wait until the end of the project to conduct the tests. Testing needs to start early and be done often. This will allow small problems to be fixed before they grow into significant problems that will take much more time and money to fix.