Now there’s a downer of an opening question if ever there was one to an IT sales person.  All fresh faced, enthused by all the great news he had to impart and more than a dozen reasons why his company was successful and should be the vendor of choice.

He had managed to secure time with all the right people in the company who would be involved in the project - from those who approve the expenditure, to those who would be involved hands on – a dream team to get to spend time with.  No one had pulled out last minute.  He had all the people he needed as his audience. This was going to be a great meeting; well at least it looked that way until this particular opening question was posed.

“Sorry?” he asked hoping, naively it turned out, that the person in the room, who appeared impassive and keen to hear the answer, might just have been making a joke to break the ice.

“I know you are going to share with us all the very good reasons and examples as to why your company can help us with this new IT project; however it would be good for my team to hear a little about the failures you have experienced in similar scenarios to ours.  As you can well imagine, we want to avoid them from the outset.”

There was no malice in the question. It was very fair but the IT sales person was a little thrown off balance.

Quickly he gathered his thoughts. Strangely thankful for having had some hair-raising, to say the least, experiences in his career, he decided the best way forward was always to engage with the prospective customer honestly and openly – although he suspected his boss would nearly faint when hearing how the meeting started.  OK, he thought, I have to walk out of here with my credibility and integrity intact and ensure I have the next meeting secured. Here goes, he thought, remembering the mantra, WIN/WIN is not only the most desirable outcome, it’s the only one!

Well this was more than a WIN/WIN opportunity in the offing.  It was a giant and valuable re-affirmation of the challenges we all face no matter which side of the table we are on and for two main reasons.

Firstly, no one wants to fail BUT, yes that’s a big BUT, failure can be measured in so many ways and it’s not always clear at the outset what the potential success/failure measurement might be.  However, for certain it will vary from one person’s perspective to another depending upon their involvement in the project.  And that’s why understanding failure is an essential learning tool.

Secondly, and probably the most challenging is that communication or lack thereof, is the real enemy.

In 2012, McKinsey research found that 50% of IT projects with budgets over 15 million USD ran 45% over budget, 7% were behind schedule and that these delivered 56% less functionality than predicted.  At least half the time achieving less than 15m USD in benefits involved a final spend of 59m USD!  Smaller projects fared slightly better but not significantly. Sobering stats to say the least.

Whatever the numbers, it makes you realise that with all the resources available to large projects, teams working on smaller projects need to be clever in their approach if they are to avoid a similar outcome.

In the business of integration, connectivity and timely, secure financial transaction processing, we have a duty I believe, to ensure that time and effort is not wasted on making the same mistakes we have seen in the past. We’ve been at this game for years - we have to pass on our experience.

Take a few minutes to consider the reasons for project failures you have witnessed and add value to your conversations by recounting some specific scenarios; although keep the identity of the organisations to yourselves please!

Help those you engage with understand some very specific examples of what they should avoid in order to ensure their projects succeed. 

As one Corporate Treasury said recently “We don’t have all the answers and we don’t want to fund an expensive learning experience if there are very good reasons for us to go down different paths to get the right solution for our business.  Whilst we have all heard “failure is not an option”, the reality is that it sure is a hell of a good teacher!”

Here are some generic reasons why projects fail. Perhaps nothing you may not already know, but it might prompt us to consider wrapping around these reasons some very specific examples so that our corporate treasury teams can understand some of the pitfalls to avoid when planning projects related to connectivity/integration and embracing cloud technologies for improved transaction processing.

Preparing for a vendor evaluation discussion is all about less haste and more speed. So both sides need to ask themselves :

• Are we starting with clearly defined objectives and goals?
• Do we have sufficient user input from all parts of the organisation touched by the project?
• There needs to be an understanding of the essential approvals/sign-off process and project documentation
• Validation of the wider organisational involvement and commitment
• Definition of roles, responsibilities, highlighting any potential shareholder conflict
• Timeframe reality check, considering any other priorities of team members
• Maintain a consistent two-way flow of information with all stakeholders
• Scope creep – it will happen. How best to identify the signs quickly and address these?
• Understand cost- and schedule overruns and implement mechanisms to manage these effectively
• Implement a change control process
• Leave adequate time for testing
• Ensure a handover process at the end of the project and remember to celebrate success

I accept that as professionals we never stop learning, and it’s my belief that we can certainly avoid wasted time, effort and cost if we take time to consider the lessons that others have learned and make good use of them!