The reality of why IT projects fail…well at least on the path to why they fail…

Yesterday I was thinking about a customer problem all day. I know that the problem can be solved but a couple of folks asked some questions that got me thinking about the long and short term answers. Sometimes in the world of technology the short fix, isn’t the best answer. Well the same is true in life so that isn’t unexpected.

Reality is most customers are driving towards an answer. They bring in consultants with the intent of shaping and delivering enterprise solutions that are effective. They have teams they call enterprise architects, and enterprise architectures teams. These teams lay out the reality of the business problems in front of the organization and map those to available and future technologies. I’ve seen the most beautiful maps of enterprise software solutions in the offices of EA’s. Maps that you look at and you realize that the EA team has spent hours determining not only what is deployed now, but what could be deployed with minor modifications, moderate modification or with a major reworking. Each of the images they have, drawn on neat lines that come together in multiple places. The desktop of users, the desk of the security team and the infrastructure team.

The answer is already there. But it isn’t there. The reality of technology portfolios is that they are not clean and the minor modification bucket is very small. Most organizations live in the moderate to massive modification bucket. The more complex a solution appears, the more likely it will be painful to move it to another platform.

If the solution is simple but integrated to multiple other solutions, it will be hard to move. Finally, the worst one of all, applications that aren’t touched because they have 3 users only to find out the three users of that application are the CEO, COO and CFO of the company and you better get that application moved, tomorrow.

Not trying to change the world with this post. I am not even trying to change IT, just pointing out the thinking process most customers have to go through as they consider change. Change is a huge issue and a great boon of technology.

The thing, I find often in talking to IT departments is they don’t understand always the impact of what they are doing. I used to interview developers and I passed on every single one that didn’t have an answer to the question. What is the business value of the application you built in your last job? You see that is the answer, the value question. Do you as a developer, or an architect or a team leader in the IT department understand the value of what you are doing. If your business makes money selling cars, do you understand how your supply chain works? Who are your primary parts vendors? What is your JIT delivery line look like?

Too much emphasis is placed on actual coding skills, which are critically important but are not the be all and end all. Yes, knowing how to implement a cloud application is critical. But there are so many parts to that concept you cannot simply be an expert. Too much to know, so you go back to that EA drawing you saw in an office. With any luck that enterprise architect still works for the company. You ask him or her what they were looking for and what business problems were they trying to solve.

Funny how asking questions of people makes for a better overall solution.