Technology projects fail for a number of avoidable reasons. Those reasons are the main topic of discussion the first night of every Requirements Analysis course I teach at Georgetown University. Over time, my students and I have identified seven common causes of project failure.
In part 1 of this series, I described four common causes of technology project failure. Now let’s look at the remaining three.
Why IT Projects Fail
Lack of Leadership
When projects run into trouble, the project team and stakeholders lose confidence in the project manager and the project’s ultimate success. At times like this, you need an executive sponsor who has the project manager’s back and allocates the necessary resources to get the project back on track.
Projects require an executive sponsor who’s invested in the project’s success and acts that way. The sponsor ensures that appropriate resources are available, for example, the budget to hire a competent project manager and business analyst. The sponsor instructs department heads to make staff available for requirements meetings, testing, and implementation so the project manager doesn’t have to battle for those resources.
The executive sponsor can also play a role in change management. As needed, they can help the project manager gain support for changes in processes, workflow, and job roles. To overcome resistance to change, the executive sponsor and project manager must communicate regularly with staff to establish trust and help them understand the benefit of changes affecting them.
User Disengagement
When staff aren’t engaged or invested in a project, it’s usually because they lack key information. Here are some reasons why users never become engaged in a project or end up becoming disengaged over time.
Lack of clear value proposition. Staff must understand how the new system will benefit them as users, improve the member experience, and help the organization achieve its goals. But, take note: if the project lacks this clear value proposition, user disengagement is the least of your problems.
Lack of trust in the project team. If the project team is led by people who don’t have the necessary skills and experience, staff may stop trusting and listening to them.
Resistance to change. Staff may not fully cooperate if they don’t see the need for change. You have to listen to concerns, ask questions, and understand why they’re resisting change. When fear, anxiety, and ego are involved, you need communication and, especially, empathy.
Absent leadership. Project woes are exacerbated by the lack of an executive sponsor. An executive sponsor who only pays lip service to the project—never investing their authority and influence in it—is no better. Without the sponsor’s support, the project manager may have trouble securing the participation of staff in requirements meetings, testing, and training.
Schedule conflicts. Sometimes, staff attention is deservedly focused elsewhere. Project timelines have to take the association’s calendar into consideration. How will conference staff divide their time between project requirements meetings and their regular duties in the weeks leading up to the annual meeting? Staff may be disengaged because they’re overwhelmed.
Changing Requirements during the Project
‘Scope creep’—project managers everywhere detest those words. Scope creep is usually caused by requests for additional functionality and, therefore, additional requirements. As a result, the project falls further behind schedule.
One reason for changing requirements is a personnel change. A new influential stakeholder joins the project team and brings their own ideas about organizational needs.
Or, after requirements are documented, the project team learns more about the technology’s true potential. They find out it’s possible to do X with the new system, but they didn’t originally ask for that functionality.
You can prevent this scenario by having a business analyst assist your team with requirements analysis. Their responsibility is not only to collect and document requirements, but also to educate your team about the technology and all the opportunities it presents. They also bring to your attention other options for achieving your goals.
Make It Work—from the Start
Take the time at the start of a project to understand what can go wrong—do the necessary risk analysis. Know what can cause your project to start down the path to failure and what you can do to overcome those obstacles.
