Successfully implementing custom software projects: best-practice tips

Paper prototype software

On time, on budget and according to the specifications – this is the avowed objective of (custom) software projects. According to a study conducted by Lünkendonk, 86 per cent of companies surveyed had experienced situations in which software projects were not completed. In 31 per cent of these companies, roughly one in five IT projects was not brought to completion. There are many reasons for why this can happen.

What can companies do to make a custom software project a success? This blog post provides an overview of crucial factors for success – with input from a variety of different studies as well as from our own project experience.

Pros & cons of custom software:
Conduct a careful analysis and then make a decision

Companies that use enterprise software tailored specifically to their needs are more innovative than competitors that primarily rely on standard, off-the-shelf software. This was shown in a study by the Centre for European Economic Research (ZEW).

A Forrester survey also demonstrated that companies invest just as much to develop custom in-house software as for off-the-shelf software. It is primarily for functional reasons that custom software continues to be in high demand. The off-the-shelf software often does not include the features required by the users. The Forrester study also claims that companies expect lower costs and less complexity from software developed in-house. In addition, custom software precisely maps the specific business processes, something that off-the-shelf software usually is not capable of. (Blog post: Custom software versus off-the-shelf software: a comparison)

However, it would be incorrect to say that a custom software solution is always the optimal solution. This means that it is necessary for companies to carefully consider which software best meets their own individual requirements. This can be off-the-shelf software in one case, or custom software in another.

If off-the-shelf software meets the company’s requirements, a decision can be quickly made. Custom development is able to demonstrate its superiority particularly in situations in which the off-the-shelf software cannot fulfil the requirements of the users or when it can only do so with disproportionately high level of customisation.

It is necessary for companies to take the time to carefully analyse their requirements. Through comprehensive market analysis and by discussing the situation with a variety of different providers, prospective users can find out what they need to know to make a decision for or against a custom software solution.

Using decision-making aids:
workshops, showcasing and proof-of-concept evaluations

If it is difficult to make a decision regarding a provider or if it is perhaps not yet clear whether and how your requirements can be implemented, workshops, showcasing and proof-of-concept (PoC) exercises have proven to be helpful tools. These methods allow companies to put their stated requirements through their paces, to get to know a vendor’s software solution and to better assess the functionality of the solution through the use of an application example. The client is also able to obtain a valuable impression of the work methods, approaches to solution finding and many other factors that play a role in the selection of a provider, such as reliability, expertise, process models (such as agile project management methods) or references.

Whether workshops, showcasing or PoC exercises are the right tool depends a great deal on the phase the company is in as well as the size and importance of the project.

Seven2one offers a variety of opportunities to get to know its expertise, approach and software – from one-day workshops for analysing requirements to showcasing and proof-of-concept processes.

Workshops – getting a custom software project off to a good start

A workshop can take place in all phases of a project. We also have had very good experiences with workshops conducted for requirements analysis prior to submission of an offer. In the situation we serve as sparring partners, provide support in taking stock and moderate the discussion of fundamental questions about objectives, opportunities and so on, such as in the workshop on the digital transformation and new business models for municipal utilities and energy suppliers. This largely involves drafting requirements together, honing objectives to be achieved and agreeing on the approach to be taken. There are obvious advantages to hosting a workshop: the project partners can get on the same page in terms of what needs to be accomplished and also jointly agree on a plan for getting there.

Showcasing – getting an impression

According to our understanding, the showcasing process demonstrates the fundamental features of a software solution based on a specific use case. A showcase is therefore a demonstration that occupies a space somewhere between a mock-up and a proof of concept. At Seven2one, we use showcasing primarily to enable interested companies to get an impression of the software functionality as well as the implementation concept. In this way the user can see and “experience” the software, allowing them to assess its usability much better.

Proof of concept (PoC) – evaluating feasibility

As the name suggests, a proof of concept provides evidence that a (custom) software solution works for a defined use case. The PoC comes into play especially for unusual, novel, complex or business-critical requirements. A PoC provides confirmation of a concept, allowing users to see the implementation. It therefore can also serve as a basis for making decisions regarding the direction in which the project will go. Companies are able obtain a reliable basis for assessing whether they are on the right track while also identifying risks.

A practical example of this would be when Seven2one created a proof of concept for a complex system environment for an energy provider.The goal was to demonstrate the functionality of a uniform interface for importing market data from several different sources. In addition to proving the functionality of the interface, the test also served to evaluate the data quality, that is, how complete, reliable and timely the data deliveries were.

Table: Comparison of workshops, showcasing and proof-of-concept exercises

Agile or waterfall:
Deliberately determining the approach to the project

Companies are well advised to make deliberate determinations regarding how a project is to be approached. There are many advantages to agile methods. However, you need an appropriate environment and mindset within the company to carry out agile projects. In the vast majority of cases, suddenly announcing that “we’re agile now” simply does not work.

From our experience with a wide range of projects, we know that agile methods (such as Scrum) are not suitable for every company. If companies choose to use agile project management methods (blog post Agile project management methods), then it is necessary for the company to desire agility as a mindset and for the project team to embrace this concept.

We have found that it is crucial to remain authentic, to know the strengths and weaknesses that your organisation brings to the table, to investigate where your boundaries lie and to make decisions regarding methods on this basis.

Requirements specification reloaded:
Defining requirements in a custom software project

Developing ideas, brainstorming and thinking outside the box are all great, but at some point these creative ideas need a “home“, that is, they all need to be written down somewhere.

The days when the requirements for a custom solution were defined in detailed requirements specifications and then implemented on the basis of equally detailed functional specifications are over. There are very few projects that continued to be implemented according to this model, and more and more agile project management methods are being used instead. Nevertheless, it is still necessary to have written documentation of some kind, since a (rough) requirements specification is still advantageous even when an agile approach is used.

A sophisticated and well-organised requirements specification fulfils several purposes at once:

  • As clients, companies can inform several suppliers about the project at the same time. At the same time, the requirements specifications serve as the basis for comparing providers and narrowing down the list.
  • When companies take the time to record their requirements in the functional specifications, they often identify gaps and inconsistencies in their own requirements. “Better early than never” is the name of the game, as they have a great opportunity to close gaps and clarify inconsistencies at the very beginning of the process.
  • The requirements specification is the foundation and “common thread” in the custom software project. It identifies mandatory and optional functions and serves as a “reference work” in the course of the project. It also makes scheduling and budgeting easier.

How detailed should a requirements specification be? The following rule of thumb helps here: The more specific, new and business-critical the company processes, the more detailed the requirements specification. At the same time, the specification should be sufficiently lean and leave enough room for solution variants.

Making decisions possible:
Technically and organisationally

Decisions need to be made in every project. Who is allowed to make what decisions? And on what level, technically or organisationally? This should be clear at an early stage. We therefore believe it is important to involve stakeholders at an early stage as well as to share information with them on a regular basis in order to enable rapid and effective decisions.

The project manager is the linchpin here. Their task is to provide information to stakeholders who are substantially involved in the custom software project and in the decisions. The project manager also moderates discussions while facilitating and documenting decisions that need to be made.

*Stakeholders are individuals, groups and institutions that share common economic goals or that are affected in some way by the activities of a company. A distinction is made between external and internal stakeholders. (Source:

Software testing in a custom software project:
Scheduling capacity and starting promptly

In agile project management in particular, users receive an increment of executable software at an early stage. In our projects, we see time and again how important it is to test the software “pieces” in a timely manner and to report back on the results. On the basis of the test results, the client is able to recognise an undesirable development at an early stage and to take appropriate countermeasures.

Software testing requires resources. These resources need to be scheduled at an early point in time so that timely feedback can be provided and so that agile software development can be enabled.

Instead of snippets of documentation:
Investing resources in robust documentation

Custom software projects often take several months to complete. After such a long time passes, who will remember why a given decision was made? It is therefore important to document decisions, feedback, changes and the like. While documentation takes time and can be tedious, documentation creates a high degree of transparency. Decisions can also be reconstructed after the fact and ambiguities can be quickly clarified.

For reliable documentation, it is important to consolidate the snippets of documentation from the multi-channel communication (e-mails, recorded video calls with screen recording or team chats). Only then are the project participants able to use the information. A shared data space (such as on the extranet or similar secure platforms) is a helpful basis. It should preferably be centralised and accessible to all project participants.

Last but not least:
Remaining flexible in custom software projects

Despite all the planning, documentation and so on, companies will find themselves in situations they did not expect. Both the project managers and the project staff should be prepared for this. Finding a constructive solution requires creativity, courage and sometimes a great deal of perseverance. It often only helps to remain calm and flexible so that you can safely reach the project goal.

Custom software projects for energy industry issues

Seven2one has been developing custom software for dealing with energy industry issues for more than 17 years. Thanks to our long-standing expertise in energy and IT, we are an indispensable partner for discussions on an equal footing when it comes to custom software. We also accompany you through all the phases of software development. Our know-how, methodology, perseverance and creativity allow us to overcome challenges and find solutions. Talk to us.

[Platzhalter - leer]

Kommentare anzeigen/schreiben


Submit a Comment

Your email address will not be published. Required fields are marked *

Diesen Beitrag teilen