Software development requirements

Give wings to innovation. Border WHY, WHEN and even WHAT, but leave the vendor free to define the best HOW. A good specification is halfway to a successful project.

Many specific software development, or “customization” projects specifications, are heavily focused on technology and resources. For example, the obligation to be in JAVA language, with a team of 50 programmers minimum, for 3 years long. They forget, however, hidden costs that some suppliers deliberately or inadvertently omit in their proposals.

The purpose of this document is to point some of these costs, and challenge those who have a responsibility to define development and implementation requirements, to avoid or minimize them in their procurement processes. The goal is to create more VALUE for the customer by opening the door to suppliers and projects, inspired by innovative methodologies such as DevOps, Lean IT or Hyper Agile / SCRUM. According to an article in the Financial Times, some of these approaches may be three times faster and with higher success rates than traditional development.

1. Rapid Prototyping

The supplier should be able to present a functional prototype shortly. This should show the basic technical characteristics (users, login process, menus, records, tables, reports,…) and the basic graphic layout.

The prototype elaboration timeframe should be quantified by the supplier so that the customer has an idea of ​​the efficiency of the development process.

Rapid prototyping can even serve, in the bid analysis phase, to assess the development efficiency of competitors. Eventually the customer may stipulate a value to reward or pay, to one or all competitors, in the preparation of a proof of concept.

2. Source Code

The solution provider should eventually be required to deliver the source code in a standard language, ready to be compiled freely, and regardless of who created the code. C ++, C # or JAVA will be the most commonly used options. This will give the customer the power of vendor independence (even if they do not make use of it) and autonomy in the future evolution of the solution.

The supplier should be able to price the source code of the solution to be delivered. Sometimes the source code is deliverable, but for astronomical values ​​or, if not standard, dependent on the licensing of a costly platform.

The source code should in any case always be properly documented to minimize treatment costs by other future programmers.

Since it is not possible to deliver the source code (as it is a product / market package) the supplier shall, as compensation, provide other guarantees. For example the price for unlimited lifetime licensing.

3. Unlimited Licensing

Many organizations start using a given software as a given number of users and suddenly, due to some legislative change, merger or association with other entities or by any other contingency in their ecosystem, they are forced to rapidly increase the number of its users. Usual per-user, per-CPU, or per-server licensing can limit time and costs or even block these changes, for budgetary reasons. In government institutions, for example, one could be stopped for a year, until the approval of the new annual budget and the entire administrative process of the purchase process. Therefore, software providers should be able to present in their proposals the cost of licensing for unlimited number of users.

4. Lifetime Licensing

The same is true of temporal licensing. Many software vendors bill licensing on an annual basis. With the argument of technological update, they charge the customer a fixed annual cost. If for any reason, the customer no longer wants to pay the annual license, for example,  for an accounting system that is to be discontinued, but need to keep track of the historical records, he will be in a difficult situation. In this regard, software vendors should be able to present in their proposals the cost of lifetime licensing of their solutions (with or without optional support and maintenance service).

5. Technological Immunity

If a solution provided in a given technology needs to evolve to a new technology what is the time and cost of such an operation? What is the technological dependency or immunity of this solution? Software vendors should clarify in their proposals:

• if the solution was manually programmed and all business intelligence is embedded in the code (in a given language and technology);
• if it was automatically generated from a template where the business rules are stored;
• if it works on any standard browser or need to install some proprietary application on each workstation.
• what are the typical timeframes and costs of technological change of the solution, with historical examples.

6. Change efficiency and evolutionary maintenance

According to a Barry Boehm study, in waterfall software development processes it is estimated that the cost of a change, in the operating phase of the system, is 150 times the cost of a change in the requirements phase. Therefore, suppliers should be able to present in their proposals the cost ratio of changes in the various design phases, so that the customer can take control of project costs, and not be held hostage to a rapidly outdated project specifications, over time.

After project completion and delivery, the same question arises for the price of rolling maintenance. What is the relationship between the price of functional changes to the operating system versus the price of changing during initial requirements?

If this relationship is difficult to measure, an effective metric should be sought, or vendors asked for specific time/cost examples for new features, that may be introduced after the system is implemented.

7. Software Modeling (Industry Inspiration 4.0)

In case the software solution is developed from modeling and automatic generation, and therefore enjoying technological immunity (paragraph 5.), the customer should be able to develop it, later on, autonomously. The customer must be able to keep the template (settings that automatically generated the application). And, therefore, the supplier must present the usage and licensing costs of the modeling and automatic generation platform, as well as the model costs.

The supplier should also be able to provide documentation about the complete informational architecture of the solution (data structure, relationships, business rules and processes) and the cost thereof.

8. Technology Transfer

The supplier should be able to present a technology transfer plan to the customer. This should include training in the use of the modeling and automatic generation platform in order to provide the customer with the knowledge necessary for its maintenance and evolution, regardless of whether this service will be provided later by the supplier.

9. Add ins

The solution provided should provide tools and accessories that enable the customer to access data for advanced query (reading), viewing through OData and for integration with other systems, including indicator generation and reporting. For example WebServices API that exposes all the functionality of applications.

10. (Cyber) Security

The solution provided should comply with the latest European and national integrated digital security legislation in accordance with GDPR and NIS and be easily and rapidly adaptable to future developments of these standards.

Conclusions

Here we suggest what to put and what not to put in a specification for developing or “customizing” specific management software, because a good specification is halfway to a successful project.

Give wings to innovation. In the specifications, border WHY, WHEN and even WHAT, but leave the supplier free to define the best HOW.

Seek inspiration from the sources sought (in the United States) or pre-commercial procurement (from the European Union) projects that are most conducive to innovative solutions.

Even on renovation, consider replacing what you have installed, notably with lower licensing values. Moreover, public procurement already requires at least the mention of an equivalent solution.

These are 10 important customer benefits when purchasing specific management software solutions. They can also serve as a guide for drastically reducing some of the hidden costs, resulting from more conservative development methodologies, such as:

• Growing reliance on obsolete technology
• Increasing dependence on man/hour resources
• Increasing dependence on a single supplier
• Slow development of new features
• Exorbitant prices for maintenance and global evolutionary adaptation
• Unforeseen licenses for new users and time periods

And thus give greater management control and value to those who award and manage innovative projects in this area.