In order to materialize, software projects require investments, support, care, hard work and dedication. A good delivery management practice ensures that once the software has been created, the software can be successfully deployed, taking care of the needs of the area that requested it and also of other units that want to use it in the future.
In the list of customers who confirm this premise is a large telecommunications company. The company decided to change supplier in order to carry out a reengineering of the systems for the management of the billing area and the issuance of accounts. The company had to implement the changes in three months or could lose hundreds of millions of pounds, including falling share prices.
Another issue was that, at the time, software development processes were bad and delivery management extremely problematic. The telecommunications company has called a specialized company to help it deliver the software on time and recover a flawed change management process.
With this, in three months, made the pending launches and managed to reformulate two applications. More importantly, it has established a simple and straightforward delivery management process to ensure that future releases happen in due time and with the required quality.
The following is a detail of the whole process, including the mistakes made.
1. Understand the current state of delivery management
You can’t begin to fix something without understanding what it is and what the problem is. The first step in improving our customer’s delivery management system was to create a detailed overview of the old processes. To begin with, the company held several explanatory sessions with key people involved in the software process. At meetings, the vendor found that the starting point was very bad: there was still software waiting for release after two months in which it was ready. Test environments were limited, unmanaged, and therefore outdated and impossible to use. Even worse, improving new environments and renovating existing ones was a relatively slow process. A good maintenance management software is needed to be made according to the current situation. It must be; specific failure metrics (MTBF vs. MTTR vs. MTTF).
- Establish a regular cycle of releases
When we get an overview of the current state of the process, we begin to define a regular cycle of releases. If the engineering team is at the heart of the project, the release cycle is your heartbeat. To determine the frequency of releases for production, we had to figure out how much non-functional test we would need and how long it would take.
- Adopt light processes. Test them at the beginning and regularly review them
If there is a guiding principle of engineering (or reengineering) a process, this principle is to develop a little, analyze the results and do a little more. Repeat this cyclic approach until you achieve the desired results. Light processes are those that do not require lengthy and bureaucratic approvals or endless meetings to reach consensus. Usually, they demand only the minimum acceptable level of inputs and outputs. What they lack in volume and bureaucracy is offset by response to change and popular adoption! Underlying this approach is the thorny problem of documentation. You have to monitor it.Otherwise, what will you review and how will it improve? It is not the kind of bulky documentation that threatens the rainforests or makes the readers sleepy. It is the documentation that people (technical or not) can read and follow.
4. Establish a release infrastructure at the outset
The release infrastructure is all that needs to exist for the software to be deployed and people can use it. Your commitment to the customer is not only to create great software but that it is available to be accessed and used. For a good release process, it is crucial that you find out what you need to be deploying to make it available to the customer before the engineering team finishes creating the software. The release infrastructure covers hardware, storage, network connections, broadband, software licenses, user profiles, and access permissions. To get more accurate results, you might need to calculate MTBF. Human resources and skills are also part of the release infrastructure. If you need specialized software to be installed and configured, for example, it is not smart to exclude from the infrastructure plan the availability of the skills involved or the cost of getting them.