On the first night of every Requirements Analysis course I teach at Georgetown University, I ask my students to discuss why technology projects sometimes fail. Over time, we’ve identified seven common causes of project failure.
Before you start a project, we suggest reviewing this list so that you know what risks to minimize and problems to anticipate.
Why IT Projects Fail
Communication Issues
You know what happens when a couple doesn’t communicate well with each other. Things get ugly. Fast.
Now, imagine when the large cast of characters involved in a project—the project team, project manager, business analyst, developers, users, and other stakeholders—have communication issues. Talk about ugly!
Communication is the most important soft skill required for project management. Almost everything to do with a project’s success or failure—including business objectives, project goals, user needs, system requirements, success factors, and constraints—has to be communicated well for a project to succeed.
Major project players must communicate effectively with each other and with the executive sponsor, stakeholders, and vendors. Luckily, simple tools are available to help a team identify key communication needs. For example, the RACI matrix spells out who must be consulted and informed about different aspects of the project.
To prevent communication snafus, make sure these conditions exist:
- Stakeholders must understand the scope of the project—what’s in it and what’s not.
- The project team must understand their roles and responsibilities.
- The executive sponsor and stakeholders must be kept up to date on the project’s progress.
- The business analyst must verify that system requirements were communicated accurately and understood by both parties.
- Both project managers—the vendor’s and the association’s—must meet regularly to ensure the project continues to move forward and both sides’ expectations are met.
Many troublesome issues, like a lack of trust or dysfunctional team behavior, are prevented by good communication practices.
When change is occurring, communication must be timely, persuasive, and empathetic. The person who’s communicating—the project manager or the executive sponsor—is essentially selling something. They must persuade staff to attend meetings, adopt technology, and become invested in the project. They must let staff know about anticipated changes in responsibilities, workflow, reports, and the member experience. Don’t underestimate the importance of regular communication.
Poorly Managed and Written Requirements
Sorry to say, but your project is doomed if the requirements collection and analysis process is poorly managed or if requirements are poorly documented. The system you end up with won’t deliver value or meet your organization’s true needs.
A competent business analyst identifies, analyzes, verifies, and documents accurate and thorough requirements. But if you take the DIY approach to requirements, you could run into trouble.
Avoid these DIY requirements analysis scenarios:
- Stakeholders who should be involved in the requirements process are left out, and their needs are ignored.
- Staff creates a long list of “needs” but doesn’t prioritize them or segment them into “needs” vs. “nice to haves.”
- Users insist on functionalities that require expensive and time-consuming customization and then rarely use those functions.
- Requirements focus on user interface features, not on what users must actually accomplish with the software.
- Requirements are never approved by stakeholder representatives.
- Requirements are ambiguous or missing information, so developers have to guess—and end up guessing wrong.
When one of these scenarios occurs, your budget and timeline suffer. You also have a difficult time “selling” the system to users who should have been consulted during the requirements process.
Unclear Business Objectives
You can’t build a project on a shaky foundation. The project team and stakeholders must understand and commit to the project’s goals. These goals must align with the organization’s strategic direction.
Everyone must understand the real problem(s) the technology will solve and, therefore, the purpose and value of doing the project. You must communicate this value proposition to all stakeholders, or you’ll have trouble later getting them to attend project meetings or adopt the system.
The team must have a clear picture of what success looks like and what their marching orders are. Working on a project without a clear business objective is like driving without a destination. Even if you’ve built a Tesla to drive around in, after a while, someone’s going to ask if you have any idea where you’re going.
Project Planning Issues
DIY project management is a risky business. Smart people are often resourceful enough to figure out the basics of project management and lucky enough to not make any serious errors. But not always. Poor planning skills can wreak havoc on a project.
Watch out for these project management problems:
- The appropriate initial discussions don’t take place, so stakeholders and user classes aren’t accurately identified, and project team roles and responsibilities aren’t assigned and clarified.
- Sufficient staff resources aren’t secured.
- Without the leadership and guidance of a business analyst, no one on the team knows how to develop a plan to analyze requirements, verify them, and get stakeholders to prioritize them.
- A change management plan isn’t developed and communicated.
- Risks that could hinder progress or bust the budget aren’t identified.
- The project team simply accepts the vendor’s development method without a true understanding of the impact because they have no idea which project management method—agile or waterfall—would be best for their organization.
Without an experienced project manager in charge, projects stumble along, often springing unpleasant surprises on the project team and stakeholders. Projects need competent leaders if they are to meet business goals.
Now You Know
You can approach your next project from a greater position of strength now that you understand these four common causes of technology project failure:
- Communication issues
- Poorly managed or written requirements
- Unclear business objectives
- Project planning issues
But three more causes remain—I’ll describe those in Part 2 of this series.
This blog was originally published in September 2016 and edited on 9.14.23.
Talk to Our Experts
Looking for more information? Have questions? We’re here to help!
Drop us a line, and we’ll get in touch right away.
