Acquiring new software solutions is often a complex process. The need only appears clear and unambiguous at first glance. It is necessary to evaluate the costs and benefits – even if it is not possible to assess all aspects. An answer must be found as to what budget will be available. And in even more important aspect to keep in mind is that the affected employees want to be listened to and also have their needs taken into account.
Most of us have experienced software implementation and rollout projects that did not achieve their stated goals, to say the least. And when compared with off-the-shelf solutions, the risk perceived to be associated with custom solutions is even greater. Challenges remain even after the software is successfully put into service; after all, it is necessary for the solution to do what it was designed to do for many years, even though essential boundary conditions are subject to continuous change.
It is possible to better meet all of these challenges if you fully understand the phases in the life cycle as well as the specific characteristics and tasks associated with them.
Not yet at the point of being a phase – how a need arises
There can be many causes that lie behind a need. New tasks need to be dealt with. External obligations force a company to set up and implement new processes. The solution employed up to now, perhaps one that was even developed in-house, no longer meets the elevated requirements.
Whatever the situation, the need comes into being for business reasons, with “business” including both the actual business domain (the market) and specific areas of work, such as one’s own IT system.
For example, a subject-matter expert from a specific area of the business has an idea for a new solution that could make work easier or enable work to be done in the first place. This subject-matter expert then looks for fellow comrades-in-arms to support their idea and help gain a better understanding of the need. The topic of investment is also raised at an appropriate point in time – after all, a justification of costs versus benefits is expected no later than when you discuss the topic with your boss.
The specification takes care of every possible detail. Or does it?
In the beginning, everything seems to be clear. In our mind’s eye, we can already envision how the new solution suggested by our subject-matter expert from the business area will work. All key features are clearly designated and well implemented. However, there is still the task of having to put this vision on paper. This needs to be accomplished in such a way that the creator of the software can complete their work without submitting follow-up questions (taking up time and introducing stress to the process) and without deviations from the expectations of those commissioning the project (leading to frustration). And all of this needs to be done in the specified timeframe and in excellent quality.
When a colleague takes a glance at the draft specification, it is quickly revealed that entire requirement areas have been left out and that there are too many details that still need to be discussed – after all, other requirements might promise a better result. However, it is important to avoid having too many requirements, as that could make the solution too expensive to implement. It is also important to ask whether it is enough to deal with the problem of sufficiently specifying all aspects of the ultimate solution by stating that you otherwise want “features and characteristics that are typical for the market”?
This example demonstrates that a specification can never be entirely “complete”, “correct” or “unambiguous”. It is rather about finding the right compromise in terms of both depth and breadth. Finally, the software producer will also want to contribute its own expertise and experience for the benefit of the client. Unfortunately, the subject-matter experts from the business area are often left to their own devices when they are drafting the specifications. Their lack of experience then leads to incomplete results that can quickly be misinterpreted. When all of that is mixed in with the competitive environment among potential producers of the software during the bidding process, you can expect there to be conflicts.
The custom software solution is created
The contract has been awarded, and implementation can begin. Depending on the software producer and what you wish to accomplish, production of the software can take place in accordance with process models that differ a great deal from each other.
Most software producers now favour the use of agile process models. Under ideal circumstances, these models allow the client to be continuously involved in production through fixed client representatives. On this basis, ambiguities and necessary decisions can be made “for the benefit of the client”, and conflicts and problems can be addressed and resolved at an earlier point in time.
However, you often see situations in which the subject-matter expert, after an initial intensive phase of specification development, is sent off to concern themselves with the day-to-day work that was left by the wayside while the specification was drafted. There were no plans to have this key person accompany the software producer intensively during the actual production process, or the extent of this assistance was not sufficient in scope. In addition, our subject-matter expert should also have the uncommon ability to assess the needs and challenges of creating software solutions – because only then can they make appropriate decisions and have a markedly positive influence on the success of the project.
However, there also software producers of an entirely different type. These producers do their work in secret and then “suddenly” provide you with a result for final acceptance. Experience in many projects of this kind should have made it clear to everyone by now that any advantages of this approach are more than offset by the incalculable risks associated with it.
The factor of time also needs to be taken into consideration. It’s actually not true that nearly all projects are completed behind schedule – it’s just that we perceive delays much more intensely than we do successful projects that are brought to a conclusion as originally planned. However, projects delivered on schedule typically have one thing in common: Both the client and software producer have at least one project stakeholder who cares a great deal about keeping to the schedule. The bottom line is that it is necessary to actively work on ensuring on-time delivery from the beginning until the very end…
The go-live can be seen as the culmination of the life cycle. After extensive and elaborate preparation, the new solution can finally fulfil its business purpose for the first time. However, reaching this milestone often requires compromises to be made, because a solution has rarely reached its fully developed state at this point in time. It is important to distinguish here between “healthy” and “unhealthy” compromises.
“Healthy” compromises can include missing or faulty technical features for which there are workarounds. “Unhealthy” compromises generally affect all basic operational issues, such as stability, technical configuration or monitoring. Compromises like this can quickly lead to weeks or months of extra work on both sides, which can enormously worsen the subjective perception of performance. For this reason, unambiguous acceptance criteria for the go-live can help prevent “unhealthy” compromises from being made in the first place.
The operational phase – an opportunity to lean back and catch your breath?
The operational period of the software will hopefully extend over many years. That makes it clear that ongoing maintenance and upgrades should also take place during this period. For the sake of simplicity, we divide the operating period into three phases:
In the start-up phase, the management of the company often begins to pay less attention to the solution. Once the go-live has been completed, the solution may seem to disappear into a virtual desk drawer labelled “All done”, and managers may block additional efforts and costs that should to be expended to achieve optimal operation. It is precisely at this point in time that the correction of suboptimal features and characteristics would yield the greatest benefit, as it would be possible to benefit from such corrections for many years to come. However, there are also laudable exceptions in which the companies explicitly include a budget for the start-up phase as a contingency option in the contract.
The start-up phase is then followed by a quiet phase in which the solution serves its purpose. Underlying business processes are dealt with properly, the users of the solution have fully familiarised themselves with the solution and are often aware of the reasons for the actual design of the solution – a situation in which the users have a positive attitude towards the software has been created.
However, it is necessary to make more and more concessions as the solution ages. The technology and the (operating) concepts based on it slowly get out of date, and the business processes change. If no measures to maintain the software are taken at this point, the solution will soon feel “obsolete” and user satisfaction will rapidly drop.
The end and a new beginning
In the final phase, the solution is no longer being used. Nevertheless, the solution often remains in operation because users perceive a necessity for the solution’s features or data, or even just its depictions of data. It goes without saying that this scenario is extremely unfavourable from a business point of view. It is therefore a good idea to draft a plan for phasing out the solution in an independent project, which allows shutdown and archiving of the solution to be carried out quickly and with clear goals in mind.
- Ein gemeinsames Verständnis der Ziele bei der Spezifikationserstellung sind entscheidend für die Qualität der Spezifikation
- Eine gute Spezifikation beinhaltet immer mehrere Perspektiven auf die Problemstellung
- In der Startphase sollten Verbesserungen explizit eingeplant sein
- Eine passende Pflegestrategie über die mehrjährige Betriebsphase erhöht den Nutzen
- Kunde und Lieferant sollten die Produktion aktiv gestalten wollen
- Die Produktion sollte niemals „laufen gelassen“ werden
- Änderungen im Arbeitsumfeld lassen den Bedarf entstehen
- Eine erste Kosten-Nutzen-Analyse zeigt, ob eine IT-Lösung den Bedarf abdeckt
- „Ungesunde“ Kompromisse sollten auf jeden Fall vermieden werden
- Klare Akzeptanzkriterien sichern die notwendige Reife
- Wie die Einführung sollte auch die Ausmusterung aktiv als Projekt gestaltet sein und nicht einfach nur „passieren“
Our familiarity with the phases in the life cycle makes us aware that the tasks and challenges that arise in the support of our software solution can be wide ranging as well as quite complex. The other articles in this blog series will therefore take a closer look at specific aspects, including certain software maintenance measures and the involvement of colleagues “affected” by the solution.