How to successfully buy a digital service development project - #2

There are many things to consider when purchasing software tailored to your purposes. In our previous blog, we shared a check list of aspects you should think about right at the start of a project.

This is the second part of the blog series. In this article, we will explain how your insight grows during the development process, and why you should take this into consideration in your working approaches including the tendering process.

Challenges in the traditional model

In a traditional setting, a software development project is launched with a preliminary survey followed by defining requirements. The aim of the preliminary survey phase is to explore what is available in the market and what there is demand for. At this stage, there is a tendency to take shortcuts and base the view of user needs and market situations on personal assumptions rather than research data.

This stage is followed by a requirement definition process producing heavy documentation on the assumpted features. Documented requirements tend to be more or less based on educated guesses.
If the system in question is even somewhat extensive, the process will typically take from a few quarters to years. After this, the defining process is declared complete, and a competitive tendering process is launched based on the definitions. The supplier that offers to do the work at the lowest price gets the job, and you will end up with a new  system after one to several years.

Does this sound like the recipe for success? Unfortunately, this approach has not proven to be successful in producing custom software. There are many bumps in the road, and the model is based on an illusion that you will never encounter surprises or needs for changes. 

There is no such thing as perfect requirement definitions

It is practically impossible to perfectly define all requirements in advance. There is a huge number of things to consider, as you are bound to encounter special cases and a variety of exceptional situations. This challenge is not made any easier by our limited capacity as human beings. It is difficult to form an understanding of extensive plans and, as the number of issues to consider grows, human errors and deficiencies are unavoidable. And most of all your premade assumptions of what end users really value could prove wrong, if so the effort has been a waste of time and resources.

You must also keep in mind that today’s world is undergoing changes at a breath-taking speed. Competitors are active, market situations are rapidly changing, and technologies become outdated. Implementing a project specified a year ago is likely to be a waste of time and money, at least in part.

“When you are planning to purchase customized software as a fixed-price project, your biggest obstacles are the requirements set at the initial survey and definition stages. If these turn out to be incorrect or lead to suboptimal results, it is very difficult (or expensive) to change your implementation later.”

An agile model enables you to respond to changes and leads to better results

You will gain insight during the development project

During an agile development project, we will investigate, specify and implement the project one piece at a time. This enables us to take benefits from the increase of our understanding before we define the next part. This also enables us to respond to any needs for change and find the solutions that work best.

Software development is a creative process, which could be compared with, say, writing this blog article. Initially, my intention was to write about how we gain more insight during a development project. However, as the writing process went on, it became clear that there was a need for providing more background information and also reason to discuss the problems of a preliminary defining process. Application development is a similarly creative work process, and a highly successful system can only be refined to its final form through iterations.

Three aspects enabling use of insight:

1.Partnership model

Commercial purchase terms must be based on the amount of work performed to make room for changing contents as the project is progressing. This model retains the client’s role as the product owner, resulting in full authority to decide on what to do with it.

2. Agile methods

An iterative development process that involves constantly and simultaneously defining the features implemented at the following stage is optimal for responding to the changes identified as more insight is gained. Transparency in all activities is one of the key principles of agile development, and the client should also ensure that this is accomplished.

3. Modern system development models and tools (DevOps)

DevOps aims at automating the software packaging, quality assurance and deployment processes, resulting in a more transparent and high-quality development process. To provide the client with smooth access for testing and deploying new versions, the development team must have the latest DevOps at its disposal for both deployment and testing automation purposes. Having good DevOps practices  in place also reduces dependability from a single provider.

Agility does not exist at a fixed price

You might see some companies advertising their software development services that follow an agile model at a fixed price. You should not believe this, as suppliers must also ensure the profitability of their business and therefore you can’t have changes for free.

In practice, a partnership model with a fixed price guides the supplier to minimize the number of hours spent on a project. This involves limiting the changes and improvements made to your requirements. While such a supplier will work to meet the original requirements, the final product will often be adequate at best from a features perspective. Projects with a fixed price also often compromise on the technical quality of the implementation.

Purchasing an agile project is nothing to fear

Some clients seem to be scared of pricing based on completed work. This fear is unfounded as long as you retain control of the content of the project and your in-house product owner is actively involved in the project. In fact, when you purchase a project based on actually performed work, you get a better opportunity for closely managing your budget and where it is used.

When you are making an agile purchase, make sure that:

• All activities and costs are transparent.
• As the client, you should make all decisions on content and manage the team’s time and budget use
• As the client, you should hold all rights to the project output, also DevOps-related outputs (testing and releasing automation)
• Choose the used technology so that it is widely available and many suppliers have competence required for operating it
• Retain rights to cancel the work at a short notice if the results fail to meet your expectations, and require that the supplier is required to familiarize its successor with the project
• For the purpose of technical work, make sure that the team also includes members with a solid experience. You should also ensure that the development team is using up-to-date automated testing and code analysis solutions, and that the results of them are there for everyone to see (for ensuring technical quality).

When the above things are in order, you will be able to make use of the insight gained during the project and keep cost management in your own hands.