Does the choice of technology lead to project failure?

During my long and varied career I have been involved in a number of significant IT projects. As a software development manager for Prime Computer (remember them?) in the late 70’s and early 80’s I led large and varied teams focused on the next release of the Primos operating system. Later in my career, as a project manager in the Lottery Industry, I led massive rollouts for the UK National Lottery and many, many others around the world. More recently, at Sony, I oversaw a significant technology refresh including the closure of a series of small data centres and the creation of two large Internet facing infrastructures. Throughout all of this I can categorically state that I have never seen a large project fail simply due to the choice of technology. In my experience, projects fail because of poor communication, a lack of clarity around expectations and weak management.

I have always espoused the strategy of surrounding yourself with strong people with excellent communications skills because they have been around the block, seen others fail, maybe had one or two failures themselves and have learnt from their experiences. How often though do we see other options being pursued?

For example, the typical solution to delivery problems in an organisation is to implement more rigid project management that follows best practice and is implemented through a methodology. However, my view is that project management issues cannot be solved by a methodology alone. If the answer is that simple, why do a significant proportion of large projects continue either failing or not delivering as planned?

An alternate solution often offered is to buy industry standard, off-the-shelf, applications and realign the business to work with the software. Having seen the cost and disruption that results from introducing SAP, JD Edwards and PeopleSoft into organisations it is clear to me that this is no solution either.

In most large projects, software vendors are represented through an SI or Systems Integrator. The SI chooses the software and then plans and executes the implementation. It is in the SI’s interests for the project to delay or overrun because the client has so much invested in the success of the project that they can’t afford to fail so will ultimately pay extra to achieve completion. I have seen projects with an initial budget of $2M ending up costing in excess of $8M. Even after this, the SI was re-engaged for a subsequent project. Bizarre!

So, how do we break this vicious cycle?

We need an evolutionary model that is iterative and handles the fact that requirements and scope often change as the project unfolds and understanding develops. To achieve this, both IT and the Business need to learn to communicate and work more closely together. They need to become process centric. If the Business and IT are empowered to adapt to changing needs, without the baggage that goes with big projects, the first iteration does not have to contain everything and continuous improvement cycles become possible. Iterations will become faster and lead to a higher level of innovation. Projects will be aligned with business needs. We will have less people and fewer problems because everyone will have a clearer understanding of the project’s target, progress and cost leading to improved communications and a culture of openness.

Technology is not the cause of project failures. It is the people who chose over complex solutions and implement using big-bang that create the problems. Once we accept that we overestimate our ability to manage people in large projects and move to smaller iterative process centric projects we will see our success rates increase and overspends decrease.

About Peter Borner

Peter is an entrepreneur and successful business leader. Currently leading a consultancy firm specialising in technical diligence for M&A and advising global firms on IT consolidation and migration to consumption based costing through the use of Cloud Technologies.

, , , ,