IT Investments: How to Avoid Financial Disaster

Everyone has heard a horror story about an IT project that ended up costing twice as much as expected and delivered half as much as promised. As a general rule, managers hate any cost overrun, regardless of the type of investment. But let’s face it, IT projects have the worst reputation. Some see them as a financial black hole.

Being the financial director of an IT development company, I thought I knew it all, until the day I actively participated in an internal IT enhancement project for my own department… and got a lesson in humility. At the very outset of the project, I jotted down all the answers to the needs of my department. I had the typical profile of someone bound to fail.

My experience taught me what managers must take into account to ensure the success of their IT project.

Defining needs

The apparent simplicity of this step is deceptive. Defining needs is the most critical phase of any IT project. At this stage, easy answers are the worst enemy. In my project, one of the tools for which I had to define needs was our timesheet system. However, instead of truly listing our needs, I went straight to proposing solutions, which was premature at that stage of the project, as the project manager had to inform me. Indeed, sometimes, a solution doesn’t answer an actual need.

I was sent back to the drawing board to produce a new list of actual needs. This list was looked at critically and many of the “needs” were questioned: “Luc, is this actually necessary?” I thought I knew precisely what we needed, which wasn’t really the case. My conversations with the project manager and programmers led me to scratch out many unnecessary requirements and to whittle down my list to a shorter set of truly value-added requirements.

Questioning needs and requirements is essential at this stage. Needs must be discussed and analyzed critically with all stakeholders. A very precise definition of needs is the key to your project’s success.

Return on investment

A mobile application can be ideal for some projects, and a waste of time for others. Similarly, a $10,000 investment can be a complete failure while a $1,000,000 one can be very successful. Everything is relative, there are no rules, as they say… and it’s true. The main thing is to assess return on investment (ROI) realistically, not optimistically.

ROI assessment should be an intrinsic part of any IT project. How else are managers to assess the quality of an investment? And don’t keep your ROI assessment confidential; in fact, you should share it with your IT partner, to give them a better understanding of what’s at stake, as well as a view of the big picture. This way, your IT partner can help you make better technological choices or suggest alternative solutions to improve your return on investment.

Setting a budget

The more limited the resources — and they always are — and the more numerous the needs — which they often are — the more remote the chances of success. Hence the importance of knowing the return on investment at the outset, and determining the budget accordingly. When the ROI is positive but resources are scarce, one option to consider is obtaining financing from a banking institution.

Ideally, when contacting a technology partner, you should be giving them a nominal budget. This way, they can tell you very quickly whether your expectations are realistic given your budget. When budgets are inflexible, managers must make choices. Would a system that meets only 80% of your needs but fits your budget be acceptable? Only the manager can answer that question.

Choosing your partner

Though price is an important factor, it shouldn’t be the only factor. When some bids are significantly lower than others, it probably means that at least one bidder hasn’t properly evaluated the development effort or technical challenges involved. Do not hesitate to question bidders on specific aspects of their bid in order to test the credibility of their offer and ensure that they fully understand every aspect of your specifications. If you enjoy nasty surprises, by all means choose a partner that hands in an offer of service based on a shoddy cost analysis.

A good trick is to compare bids in terms of hours instead of dollars. Sometimes, the overall price difference between two bids is the result of a higher hourly rate, which can be justified by specific expertise or greater experience. Also consider the compatibility of your corporate culture and that of your future partner’s. Not only does your partner have to be credible, but they also have to be able to maintain a harmonious, efficient working relationship with your company. Remember that you’ll have to work together for months, and if everything goes well, for years, on different projects. Affinity goes a long way to building long-term relationships.

Agile Mode

The fact is that IT projects constantly evolve over the course of their development. In order to succeed, the IT partner has to constantly adapt to the client and to change. This means that, ideally, projects should be developed in “Agile” mode, i.e. producing a deliverable every 2 to 3 weeks (at the end of each “sprint”). These deliveries are a chance to meet with the partner, to take stock of the progress of work and to re-evaluate needs. Providing deliverables early and often greatly reduces the risk of ending up with a program that, at the end of the line, doesn’t really meet one’s needs. Better yet, it will allow you to make on-the-fly adjustments and to even change the entire direction of your project should you discover that needs were poorly defined at the outset.

Fixed price or hourly rate?

IT development projects are overwhelmingly billed on an hourly basis. If you want a fixed price, you’ll have to have very detailed specifications and you will be allowed few or no changes along the way. Furthermore, you cannot have the latest technology, since technological uncertainty will have to be kept to a minimum.

Unfortunately, some companies accept fixed-price projects even though the specifications are poorly defined. Some even submit a very aggressive price, undercutting the market just to win the contract. But the client does not stand to gain from a partner that spends twice as much time as expected on a fixed-price project; in fact, this just breeds a frustrating business relationship and the quality of service inevitably suffers.

If you’ve carefully analyzed your needs, calculated your return on investment and chosen a credible partner that is compatible with your corporate culture, and if you are able to work in Agile mode, your best bet is an hourly rate. And thanks to Agile development, you’ll quickly find out if your technology partner is interested in developing a long-term relationship with you, based on trust.

Here’s hoping that my advices will be useful to you in future IT projects!