Tony Corrigan, strategic consultant and founder of TenderScout
Collaboration and communication help avoid expensive mistakes in IT projects, without sacrificing the ability to change as the work progresses, says Tony Corrigan, strategic consultant and founder of online platform TenderScout, which helps SMEs win public-sector contracts.
In your experience, what’s the secret to successful IT projects?
The biggest failing of every IT project is that people don’t know what they want at the start. Estimates are always, always optimistic and the nature of IT development is that you don’t really understand what you’re trying to do until you’re in the middle of the process.
I’ve spent 10 years developing projects using the waterfall methodology and around 2003 I switched to Agile methods. Since then, I’ve found the closeness of fit between the buyer’s expectation and what the development team delivers is so much closer. It’s not cheaper, but you certainly end up with a happier customer and a more successful project. And you end up with a more accurate understanding of the cost, which is going to be more than you thought at the start.
What’s more important: to deliver on time and on budget, or to meet the terms of the project plan – knowing they may well change during the work?
Well, they always do change while you’re in the middle of the work. One of the things you find is, everybody’s a designer and when people see a user interface, they’re going to want to change it. Most people don’t understand the ramifications of the phrase ‘would you add another button in there’?
But if you develop in Agile methods, you can make changes in situ: changes that would have been left towards the end when it’s incredibly expensive to make the change. I’ve worked on projects when you realise the market has moved somewhere else (during the development): those are very expensive mistakes to make.
My own personal approach would be not to do quite so much pre-planning, but when developing project plans to assume things are going to change – essentially, to embed change into the project plan, so it’s part of the process. So then, you’re more than willing to take on the change without feeling it’s going to change your estimates.
Why do so many organisations get IT projects wrong?
Customers don’t know exactly what they’re looking for, and when working in technology, they can’t imagine what the solution is except in reference to another solution, which was developed for another situation or another market.
Each and every solution is specific to your needs or the customer’s needs, and you have to build that in. The development process is a learning journey. If you can make space for that in the project plan, it will be more expensive than you originally thought, but it will be less expensive than it would have been otherwise.
What are three easy things that can be done to improve outcomes?
You need to have a team that’s bought into the overall outcomes, and that’s not just the customer team, it’s the supplier team. If everybody’s working towards the same goals of achieving success, it’s more likely to happen. Establishing a collaborative working environment is the most important thing.
The second would be accepting a certain level of risk, and be willing to work together in overcoming the challenges that brings.
Have you seen any game-changing technologies (either ones that are already established, or just emerging) that could really help IT departments to be more effective, or is it more important to focus on the people and process rather than the cool tech?
I think it’s the people and the processes. When I started writing programs in the Eighties – I started very young – I remember transcribing Basic code into a Commodore 64. Now, if you want to develop apps, it’s drag and drop, and what it has tended to do is it increases our ability to deliver applications, but it misses point of right-sizing them to the market conditions or the business conditions. You do the wrong thing, faster.
The tools that are available are enablers, but they don’t define the context. Only people do that. Certainly, Agile is a process that’s been hugely beneficial to me and has helped me to manage offshore outsourced development teams hugely efficiently.
A lot of the Java-based technologies have come on leaps and bounds over the last 10 years. When they first emerged they were quirky and difficult to adopt in enterprises, but now they’re totally embedded.
Now, there’s so much software available as shareware and some of it is sensational stuff: people now can be creative and aren’t encumbered by the need to understand how registers work, or low-level programming. I don’t think you’d see Facebook and WhatsApp without ability to rapidly prototype and innovate.
IT departments often get a bad press as being the ones responsible when a project doesn’t work. Is this fair, in your opinion?
One reason why I’m such a big advocate of Agile methodologies is that it allows people to collaborate and it allows the implicit knowledge that people have to emerge. If you’re an IT department, and your customer is the greater organisation, you’re not going to understand how their processes work, so you end up with IT systems that partially work with the solutions.
What are some issues with IT procurement in the public sector, as you see them?
The reason that I started TenderScout in the first place is that I noticed a lot of great companies I worked with were not winning tenders. While you have got a lot of people great at writing programs, they’re not necessarily great at writing tenders, so you end up with a lot of the same old companies winning all the time. You find a lot of great companies that could deliver innovative solutions to the public sector that just don’t engage. So that was the catalyst for TenderScout.
Is the problem to some degree the tendering process itself?
The first thing is, technology has changed quite rapidly and if you’re working in a public-sector organisation, it’s not likely you’re going to be totally up to date with the technology. You’re finding that there are lots of innovative companies that are capable of delivering projects with benefit and cost savings, but public-sector organisations aren’t ready for them.
With public-sector organisations, having had challenges with data breaches in the past, and you’re asking them to invest in your cloud solution, then they’re not going to do it.
By the same token, a lot of IT companies assume more knowledge on behalf of the public-sector organisations than is there. So you’ve got that disconnect: buyers that don’t understand the range of options and suppliers who assume that they do, so they don’t explicitly call out the benefits.
About 10pc of companies actually write tenders, and only a small portion of those are IT companies. Across each sector, you’ll find most companies have a 10pc success rate. We have transformed that so that our clients are winning eight or nine of those tenders. A lot of what we do is de-risking the supplier to the buyer.
We are acutely aware of what buyers need to see in a tender, beyond the technology solutions. And very often it is that they have a quality process, issue and risk management procedures, strong contract management.
A lot of IT companies forget that people are buying from people, and you need to have really strong mechanisms for managing communications and customer expectations. Especially in an IT project, where small misunderstandings in perspective can lead to expensive changes down the line. We help companies put together those tenders that address those risk elements for the buyer. Because they’re not just buying the technology, in effect they’re ‘buying’ the whole technology organisation.
You’ve worked with the Innovation Value Institute: a lot of the membership comes from very large organisations; but are there concepts and methodologies that would suit an IT department in a small or medium-sized business?
The IVI has developed an IT capability maturity model, and that’s eminently transferable to any reasonably-sized IT organisation. I don’t know if it’s a cultural thing or not, but larger organisations are more ready to invest in culture and processes to make them effective. Smaller organisations tend to be focused on surviving, and their processes are ad hoc.
I know the mantra is to turn IT into a value centre from a cost centre. Even for small IT companies and nimble IT companies, the lesson is: if you can be methodical in what you do, then you will ultimately be more successful than those that don’t. And when it comes to tendering, that’s critical.
Procurement in Ireland has changed in the last couple of years. There’s a new chief procurement officer, Paul Quinn, and a lot of the procedures he’s introducing are about ensuring the public sector gets better value for money from providers. Contracts are becoming bigger and relationships are becoming longer, and if SMEs can’t step up to the plate, they’re going to find it very difficult to win business. It’s a real challenge for them.
Name a project you’re most proud of in your career, and why?
I think the thing I’m probably most proud of was in Westminster City Council, where I worked on a project to build the IT strategy for citywide management service delivery. The thing about that project was it brought together lots of different technology suppliers and required them to work collaboratively. It was building a wireless city – at the time of (wireless networking standard) 802.11b. It was the community spirit that was fostered and the willingness to collaborate. If I could emulate that in Ireland, it would be sensational. But I think the Irish SME is not as open to collaboration as their UK counterparts.
Apart from that, the thing I’d be most proud of is TenderScout. The idea came in 2008 but it was 2012 before I had all the pieces in place. You’re dealing with millions of unstandardised data sets, and we turn that data into decision-making tool for SMEs. I think it’s given SMEs a game changer and a leveller when it comes to competing with large organisations.
