In many companies IT has come to be regarded as an essential component of core strategy. Companies are thereby responding to a fundamental change. In times of digital transformation IT capabilities are often what decides which company is a crucial step ahead of the rest. Speed plays an especially decisive role in this competition. How much time does a company need from the idea – the requirement – to the implementation of the software that puts the idea into practice? And how quickly are new releases taken into production? The answers to these questions largely determine business success or failure.
In the course of digitization views on IT and the software used in the company have undergone a further change. Instead of being regarded merely as an unavoidable cost area many organizations now see them as a competitive and value appreciation factor that decides whether or not the company can leave its competitors behind. That is why companies are increasingly concentrating on putting their IT to good strategic use and driving it on. In-house IT is thereby gaining in significance for corporate strategy.
In spite of this aspiration by no means every company succeeds in placing software really successfully and strategically within the enterprise. Instead, software projects repeatedly come to grief in similar problem areas. For one, in the specialist departments of many companies there is a prevalent mistaken belief that each and every software specification is so valuable that it must go live in the first release. This aspiration takes the project to a much higher level of complexity and makes a swift, iterative development of the software impossible.
For another, successful software development includes accompanying the project until the application is in productive use. Software development is therefore not limited to producing high-quality code. Instead, the IT department must also ensure that the software can be put to productive by its end users. The application must be installed on all systems (development, testing, and production) with quality assurance ensured until handover. If required, data must also be migrated or consideration given to connecting the software to third-party systems.
The success of software is not only an IT responsibility
As the problem areas outlined indicate, software development is not an end in itself. Its value results from it being used on a daily basis and thereby making a contribution to the success of business processes. So the principal aim of software development must be to implement in the best possible way the end users’ requirements of the software. At first glance that may sound trivial, but in reality the organizational separation of IT and business departments leads to the two finding it difficult to communicate or collaborate with each other. In these circumstances the problems described are almost impossible to resolve. Not infrequently, for example, business departments do not want to be involved in the software development process, their pretext being that “that’s for IT to do.” As a consequence business departments follow software launches with a motivation that is at best capable of improvement.
Software development is not an end in itself. Its value results from making a contribution to the success of business processes.
Yet the business departments’ role must surely be, for one, to explain to IT which tasks the software to be developed is to perform and, for another, to help ensure in the course of development that the specified requirements are correctly implemented from the business viewpoint. Communication processes of this kind can only be ensured by means of a lasting amalgamation of IT employees and the business department in question in a project team – in keeping with the golden rule “make the people who are affected participants!”
Furthermore, the world feels turned around when the project assignment consists of launching so-called standard software. As customers’ changes to this kind of software are mostly protracted and cost-intensive, from the moment it goes live the software is frequently no longer geared to optimal business processes. Instead, the processes must adjust to the software. The task of the business department representatives in these projects is to prepare and communicate in their departments the process changes that launching the new application will necessitate. That is especially important if it involves cooperation between several organizational units.
The overall project manager connects the business and IT departments
Choosing the right project manager is also of decisive importance for the success of a development project. Purely IT companies tend to make the mistake of appointing the best technician as the project manager. Ideally, what you get will be an outstanding technical project manager, but due to his technical background he will frequently lack the understanding, motivation or competence for further tasks – with the result that these challenges are dealt with either half-heartedly or not at all.
That has disastrous consequences for the project. As the problems discussed above demonstrate, the quality of the code is not the only factor that decides whether a software launch can be described as a success or not. In addition to the technical implementation an entire range of other tasks must be performed if the software go live is to be a success. They include the following:
- Expectation management
- Requirements management
- Development
- Design
- Data migration
- Quality assurance
- Infrastructure
- Training end users
- Rollout
And this list could be extended effortlessly.
In view of this heterogeneous range of tasks the overall responsibility for a new software launch should not rest solely on the shoulders of the technical project manager. Instead, there should be an overall project manager who not only has his eyes on the technical side of software development but also ensures the comprehensive involvement of the business department in all aspects described. That eases the burden of numerous organizational tasks on the technical project manager, who can then concentrate fully on the technical architecture, the quality of the software and the software development processes.
The overall responsibility for a new software launch should not rest solely on the shoulders of the technical project manager.
With his overview of the project the overall project manager should take on the risk management as well as the tasks listed above. In the course of risk management he will not only identify risks that the project may face and analyze their likelihood of arising and their damage potential but also develop strategies in advance to prevent them from arising. He will also be mentally flexible enough to develop at short notice a solution to minimize the damage caused by previously undefined risks.
Along with this mental flexibility the overall project manager should also possess another soft skill. For a successful project manager the project aims must in principle be the foremost priority. He is explicitly required to show project egoism. In-house the project manager may accordingly not be very malleable and cooperative, and that may make life hard for him during and after the project. That is why it makes sense to take an external project manager on board for larger-scale projects. He will see the project through with all his might and the necessary consistency and does not need to worry that his egoism might rebound bitterly on him once the project is completed.
Conclusion
The not only organizational but also mental separation of IT and business departments is largely to blame for delays in or even failure of software projects. Business department representatives are often lacking in insight into the way their IT colleagues work and the consequences of this work for their own processes. On the other hand, IT often restricts itself to the technical aspect of their work and neglects embedding the software produced lastingly in the business department.
In order to bring software successfully into production the IT and business department must therefore be more strongly interlocked. That requires, for one and indispensably, the creation of mixed project teams. That is the only way to ensure constant communication, the basis for successful collaboration. Furthermore, an overall project manager should always be appointed to support the technical project manager. By keeping an eye on and eliminating the problems that will inevitably arise in the area of tension between the IT and the business department he will pave the way for the software and ensure that it is put to productive use once the project has been concluded.
Image source: Fotolia – Rawpixel.com
