I teach a system requirements and analysis class for Georgetown University’s Masters Program in Technology Management. I’ve taught the class for 9 semesters. We start each semester with a conversation about what requirements analysis means and why requirement gathering and management are so important to any system development and implementation project.
We also start the semester with an exercise in which teams come up with their top 10 list of the various reasons they have seen projects fail. We then process the reasons as a group and determine their root causes. Here are a few lessons learned from the collective wisdom of the class. There won’t be a test at the end, but don’t let your next project turn into a pop quiz that you’re unprepared for – or you might be doomed!
Leadership
The group feels that a lack of leadership will certainly sink a project. The class teams talked about the various forms of leadership that are necessary in any project.
Executive Sponsorship – Think about the last time you tried to implement an enterprise-wide system and there was a clear lack of interest or backing from an executive. Or, just as bad, there was lip-service from an executive talking about the importance of the project and how the organization needs to change its processes (and perhaps even its culture) to take advantage of the value of the new system – but in reality, nothing was going to change. This will (not ‘can’) sink a project. The executive who champions the project must be actively engaged and visible throughout the project lifecycle. This does not mean they need to be in every meeting and part of every decision, but they do need to be present more than at the kickoff meeting and the post-project debrief … most likely a debrief about why the project failed if this is just their second project-related meeting.
Project Leadership – Who ‘owns’ the project? If you can’t answer this, clearly no one owns it. One of the phrases we’ve introduced to our project planning meetings is accountability and authority need to sit with one person – the project owner. That doesn’t mean that all project decisions have to be made by one person, but it does mean that if someone is being held accountable for a project outcome, they have to have the authority to create and enforce change. Making a committee accountable leaves a void in authority and can cause a project to fail.
Communication
What is the project’s communication plan? Do you have one? There were many symptoms the class described of communication failure points. Some of them included:
- stakeholders not kept informed of the project status
- stakeholders with different information about the project status
- success factors are not clear
- roles and responsibilities are unclear to everyone (this also appeared under leadership and team composition)
- there is a project plan, but no one knows about it
- the ‘wrong’ information is communicated and the ‘right’ information is lost in noisy communication
There were other symptoms, but these were the most common comments. Communication isn’t something you can take for granted, nor can you take for granted that everyone knows how to communicate. It should be part of your project planning process. What do we need to communicate to whom and how are we going to communicate that information? One tool we lean on heavily to establish a communication plan is a RACI matrix. This site does a good job summarizing a RACI matrix and its value. As I’ve said to my class, the real value of the matrix isn’t the actual matrix; the value is all of the communication and conversations that go into creating it. The team will be on the same page with who is responsible for what and which stakeholders need to be kept informed at what level.
Resources
Resources come in many forms. Naturally, the conversation started with financial resources. Is the project properly funded? Whether it is a custom application that needs to be written or a commercial off-the-shelf product that needs to be configured, integrated, and rolled-out, financial resources will be necessary. Establishing a budget is key. One common comment during class was that too many projects start with the budget, and then determine the scope. True, almost all projects have financial constraints; however, during the planning phase of the project, an organization should research ballpark figures with respect to the potential project scope to ensure project feasibility and success.
Another resource that is often overlooked is a project management resource – a person at the helm. No matter how organized and detail oriented a person is, you can’t assume they will be a stellar project manager. There are tools, processes, and techniques that project managers use, aside from simply tracking tasks and a to-do list. Also, it seems common for a staff person with a set of full-time responsibilities to be assigned to be a project manager. This doesn’t work. Hiring an experienced project manager is key. Whether you outsource this function for the duration of the project or have a full-time project manager on staff who can take on the responsibility, we all agreed: a project needs a dedicated, skilled project management resource.
In addition to a project manager, a project also needs a knowledgeable business analyst. It is the business analyst’s responsibility to plan, collect, analyze, and manage requirements throughout the project lifecycle. Considering that the class is focused on the role and skills of a quality business analyst, I think it is unnecessary for me to reiterate that this is a critical resource!
Organizational Culture
Don’t let the brevity of the following paragraph fool you. Culture was a significant portion of our conversation – as it should be. The organization’s culture needs to be considered. Collaborative? Silos? Autocratic? Apathetic? Entrepreneurial? Change resistant? Early adopters? Risk averse? What are the cultural characteristics of the organization in question? This is a very important consideration for the project team to discuss. The answers will affect the communications plan, the RACI matrix, requirements gathering techniques used, and perhaps even the development methodology (waterfall versus agile) employed.
Naturally, other topics came up during our discussion. However, most of the symptoms of a failing project fit into these larger categories listed above. All of these can be avoided – so why aren’t they?
Flickr photo by margot.trudell
