You may have read a bit in the news recently about the unfolding disaster with TAFE’s new student management system. Although the software at the heart of that rollout is one of our competitors, it isn’t with schadenfreude that I write this. Failures like this hurt the whole software industry. Tribal is but one part of the $750 million dollar Department of Education IT implementation; a project that was originally costed at under $450 million. Also included are new payroll systems, a K-12 student management project and new LMS platforms.

But let’s look at the TAFE student management project specifically. TAFE have decided to remove the Tribal system they deployed less than two years ago, and go back to market for another system. I’m not privy to this project’s details, but in my 25 years of developing software I can say that most implementation issues are a failure of project management rather than technical development.

All good software publishers work hard to maintain high quality development teams, with good QA (testing) processes and modern agile development planning and continuous deployment. That process is highly technical and you need good experienced people, but in a way that’s the easy part. Sure there are big decisions to make along the way: what languages, libraries and technical approaches do you take. But you make decisions and move on with the work. PHP is widely derided as a rubbish development language (and it is), but that didn’t stop Facebook from making it work for them. Unless you can’t maintain reliable services or have security flaws, technical decisions are rarely why a project fails.

But what is this project management thing? It is the ‘everything else’. When we pick up a new potential customers, the early meetings are all about highlighting the benefits of our platform. We want to close the sale and so we’ll talk up all the things we do really well. But what happens when some features the customer wants don’t match the product? There will always be something.

Some sales people will want to gloss over those because they just want to win the sale. And if the sales person isn’t involved after closing the sale, it really isn’t their problem. At ish, our sales people are also our account managers, and I think that’s a good model since continuity between sales promises and delivery is important to customers. And so what do you do when your product doesn’t match the customer requirements?

  1. You change the requirements. Sometimes customers confuse requirements with solutions. That is, they think they want a particular solution to their problem but when shown a different solution they could be equally happy. This can be a great solution since everyone is happy, but if you have a customer unwilling to embrace change then you have a problem, especially if the CEO is happy to have change but doesn’t bring all the staff along on that journey.

  2. You find a workaround. Maybe there’s another piece of software we glue into the project. Our survey tools are limited, so perhaps we integrate SurveyGizmo. This has become a more and more common approach in IT over the last 10 years: focus on your core strengths and do them really well, but allow lots of integrations. But some IT managers feel that the solution has failed if everything isn’t in one database which they can report on in one place.

  3. You promise to change the product. Perhaps you can add some developers to your team, or take them off something else. Perhaps the new features aren’t taking your product in the wrong direction and you are happy to add them in. This can be a dangerous approach if not planned out well. You need to really understand the customer needs and you really need to make sure they aren’t taking you in a direction the product shouldn’t go in. For the developer there is a lot of risk that you don’t understand the problem in your haste to land the customer. And for the customer, how do you know what you’ll end up with?

  4. Some customers will feel they are so big or so different, that off-the-shelf solutions will never be enough. So they might end up with heavily customised ERP solutions (PeopleSoft, SAP, etc) which look more like a custom software development project built over a core accounting system. They might never get another upgrade for the life of the project unless they are prepared to pay for its development, so 7 years later they need to start up another big IT project to catch up to where the rest of the world is. In my experience people think they are special more often than absolutely necessary.

Even if you are a small organisation, it is worth keeping the above concepts in mind. You still need to find the best software for your needs and whether your budget is $5000 or $5 million, you want an outcome you can live with. So you investigate what’s on the market and you interrogate the sales people at each company to see where the gaps lie between their product and your needs. But recognise that you may need to change your business processes and be realistic about whether those changes are acceptable.