I have worked on many large enterprise initiatives over the years. Some were successful and some were not. As an avid researcher of my trade, I have also read about many failures of large initiatives. Being the lessons-learned kind of guy that I am, I always try to understand what worked and what didn't so I can make sure that the next enterprise initiative can avoid failure. Whether you are implementing SOA, Enterprise Architecture, forming a PMO, introducing a new programming language, or merging with another company, I have seen a consistent pattern of failure that can be summed in the following 10 categories:
1. Poor Communication
Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this. Use a combination of town hall meetings, portals, blogs, group meetings, emails, wikis, bulletin boards, posters, and any mechanism you can think of to get the word out. In larger companies, this can be a full time job for somebody.
2. Underestimating or ignoring impact of change
This is another way of saying poor change management. People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout. The leadership, lead technicians, project managers, and all of the visible people in these projects must be positive forces and constantly promote the vision and the future state. I wrote a post called BPM, SOA, and the Swing Voters that discussed how important it is to stay focused and positive and not to show frustration. People will feed on the attitudes of those leading the initiatives. You must address resistance head on and address people's needs to help them turn the corner. For those who just refuse to buy in and become roadblocks, show them the door!
3. Lack of Leadership
IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed. I have seen some projects succeed where the leader was not technical but relied on strong technical people below them. I have never seen a large enterprise initiative succeed when the leader did not have people skills. Not having the business knowledge often kills projects because the projects tend to be done for the sake of technology and not for business reasons. In this case you can deliver the most impressive solution in the world, but the business might reject it because their needs were not taken into consideration. The leader must work just as hard if not harder then the people on the team. I have witnessed one "leader" assign his team a ton of work over the weekend and then left at 5pm on Friday and said "See you Monday". That created an all out revolt. The leader must have integrity or nobody will follow.
4. Lack of strong executive sponsorship
For these projects to succeed you must have somebody high up in the organization with a lot of clout. There will be many obstacles to overcome and key decisions to make. You need somebody strong to help make and enforce those decisions and remove major hurdles so the team can get the work done. This is a critical part of change management.
5. Poor project management
Scope creep is a project killer. Managing scope and requirements are the key to any project. Often, large enterprise initiatives have a ton of logistics that need to be identified and managed accordingly. These initiatives also tend to span multiple teams across various departments. The project manager must coordinate all this and effectively communicate to people at all levels. And don't forget risk management!
6. Poor Planning
This could also fall into a category of unrealistic expectations. Initiatives like SOA require a well thought out strategy. Many IT shops do not have the patience for this and rush into their project head first without a clue of how to actually accomplish their goals. When it fails they claim that SOA doesn't work. If you are going to take on a big culture changing technical project take the time up front to do the necessary research and create a roadmap. Then put a plan together to get you from initiation to implementation.
7. Trying to do it cheap
Another common mistake. Organizations want it all, but they don't want to invest the time and money. I have seen many projects get completed using this strategy, but they almost always run over budget, are late, are missing many features, and have many various quality or process issues due to the quick-n-dirty approach. Remember, the dirty stays around long after the quick is gone. Doing things cheap often costs more in the long run. I have witnessed many projects that didn't fund the appropriate number and types of resources. You wind up not creating documentation, not having the bandwidth to sufficiently test all of the use cases, not having time to architect it right, and you burn people out in the process. Another issue is that underfunded projects usually don't provide the team with the necessary tools to do the job and do not prepare the organization for life after rollout. Even worse, you may wind up picking the wrong vendor, whether it is software or professional services. Picking the wrong vendor can be disastrous.
8. Lack of technical knowledge
I'll use Enterprise Architecture as an example here. If the person leading an EA initiative does not have a solid understanding of architecture, application development, security, infrastructure, process, and the business, you might as well not even start this initiative. You can have all of the leadership and communication skills in the world but if you lack the technical know how you are doomed. Many enterprise initiatives are very expensive undertakings. Don't pick a leader with the "I stayed at the Holiday Inn Express" mentality. You wouldn't ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.
9. Lack of sound business case
You can get all of the other issues right but if your solution has no business context then you are wasting your time. I have seen this happen with many SOA projects. IT teams with great intentions go off into their ivory towers for months or years and come out with tons of great documents (usually outdated) and a nice service oriented architecture. Then they try to convince the business to use it. Good luck. Justify these initiatives with business drivers. I have beaten this horse to death on this blog (here, here, and here).
10. Poor vendor management
I have seen this happen far too many times. Somebody hires a high priced group of consultants and let's them run wild. Consultants goals are similar to your goals but that is not a good thing. Both the consultants and your goals are to make as much money as possible for the company. The difference is you are trying to maximize profits for your company and they are trying to maximize profits for their company. If you don't manage them closely they will succeed at their goal and you will fail at yours. Also, the consultants will not have to stick around to support what they build, but your team will. You should make sure that what they build meets your requirements, your standards, your needs, and your timelines.
I have a saying from my 20+ years of working on IT projects. It goes like this.
"I have worked on so many projects that I know all of the things NOT to do."
That's the easy part. Knowing what to do is much harder. I'll leave you with this post called EA, SOA, and Change which has a very successful formula for enterprise initiatives.
- Build strong business case
- Secure executive sponsor and top level buy in
- Create a Road Map
- Communicate the Road Map
- Empower Others to Act on the Road Map
- Start small, deliver early and often (agile)
- Expand, add incremental value