Arkisto: March 2012

Testing can Double the Profit of a Software Product

12. Marchta, 2012 | Kirjoittaja: Antti Niittyviita

A software project consists of three essential expenses. A short rhyme I made just now with love tells you what these three are all about.

What are little software projects made of?

What are little software projects made of?

Coding and testing and measuring technical debt,

That’s what little software projects are made of!

If you stop to think about a little, around one million euro, software project, its expense structure could look like this:

  1. Coding. 600k euro: The software developers have a need to get the software ready to be supplied. Developing all the wanted features in the software takes roughly the same amount of worktime and money in all cases. But you need to get the features in. You cannot escape this fact.
  2. Testing. 50k euro: Another essential expense in a software project is testing. Typically when you go for a hard profit in a software project, testing is the place where they cut the expenses. Most of the time, the testing expenses are around 5-10% of the development’s total expenses, when the recommended amount would be 20-40%.
  3. Technical debt. 350k euro: All software projects form technical debt. It consists of the bugs that are found in the end product and of problems that cause additional expenses in the form of reclamations, insurance guarantees and updates after the product has been supplied . In addition, it can cause losses of profit, when your reputation as a supplier gets tarnished.

When such a project produces a turnover of 1.200k euro, the profit is around the level of 200k euro (20%). A well made testing can, however, save the expenses during the entire life cycle of the project by a ration of 1:3.

With testing planned right, an additional investment of 100k euro to quality could help find even over 1000 bugs more during the project. The technical debt caused by these bugs would remain unborn and they could be fixed during the product development. With the additional investment, the total sum of expenses of these three is only around 800k euro, but what does that mean, then?

Well of course it means more money! The profit of the software product doubles and a product of higher quality is sure to sell even more!

Why do Public Sector’s IT-projects so often fail?

5. Marchta, 2012 | Kirjoittaja: Antti Niittyviita

Tietoviikko is pondering the topic of whether it is possible to refuse an IT-project on the public sector. They speak high words and say that we ought to have a good strategy for ict-acquisitions. I believe that IT-strategy workgroups do not find a solution to this problem.

Let this entry be a draft and a conversation opener, rather than an obvious fact. The point of this entry is to ponder why public sector’s IT-projects so often fail. First, I will briefly go through the reasons for why the sources’ IT-projects have succeeded or failed. Then, I will briefly explain the methods of competitive tendering for public IT-projects. It could be that those two things are linked.

By googling “Why software projects fail” one finds pages upon pages of reasons why IT-projects can go wrong. The lists may have different emphasis, but each one of them brings up the lack of end user perspective. That is, when the project is specced, tendered, ordered and accepted by some other party than the end users. In addition, the support of the management was very often lacking or even non-existent. It was essential to note that technological challenges or people’s “non-marketable” knowhow were not even close to being a significant factor.

What was characteristic of the projects that succeeded was, much like one could deduce from the previous paragraph, that the end users were a part of the project from the get-go. This serves to not only make a software that is more likely to work well, but also by making the deployment easier, since the software is familiar. Having end users along inevitably leads to the requirements of the project being increased, changed and taken out as the development goes forward. This requires flexible developers and project managers, who genuinely want to make the customer satisfied and the product excellent.

Public competitive tendering of IT-services goes pretty much the following way:

  1. Public unit decides that we need a System.
  2. Public unit might make a request for information, where potential suppliers are asked to comment.
  3. The requirements specifications for the System that is being acquired is done with the best talent and knowhow. End users might be asked to come along for the guesswork.
  4. The suppliers are tendered and the overall cheapest choice is picked.

The chosen Supplier has a specs, according to which the software has to be developed at a fixed price. Making changes is difficult, because it changes the Supplier’s scheduling and through it, the expenses – or alternatively the Public unit should increase their budget. This is quite difficult on the public sector, so they go by the original plan.

Therefore, public acquisitions are burdened by a structural problem of competitive tendering and competitive regulations. They make it mostly impossible for utilizing end users’ knowledge and knowhow as the project goes along. And as we noted earlier, this is the single most significant reason for IT-projects failing.

I am not very familiar with competitive regulations. If one could handle the tendering in a way where end users could be reasonably included in the project, we would not need changes to the law. Only more knowhow for making the purchases. One cannot handle the tendering for IT-systems with the same methods as one does with snow ploughing or installing heat pumps.

I open the discussion!