Is that magic or craftsmanship?
This is how a customized software is finished on time.
“Danger recognized, danger averted” is the proverbial saying. If you apply this rule to software projects, then it comes down to the early detection of problems. With a project status report, you can determine at any time whether the project is still within the calculated effort. And, as we all know, these have an impact on the schedule and programming costs. The earlier you detect discrepancies, the more time you have for the introduction of effective countermeasures.
In the beginning, everything will be fine.
How to finish a customized software on time? The cornerstone of good software is understanding the customer’s requirement. A good software service provider should therefore take the time to understand the customer’s requirements comprehensively and carefully. The requirements describe what the customer wants to achieve with the software. Ideally, each individual requirement is given a number. This number, known as the request key, is used to identify the requirement throughout the project.
Based on the requirements, the software service provider creates a realization concept. The term “realization concept” is used as a synonym for requirements specification. It contains a technical description for implementing the individual requirements. In order to establish the assignment to the included requirements, the chapters of the realization concept should also refer to the request keys.
With the realization concept, the customer and the software service provider agree on the scope of services of the software to be created. On this basis, the software service provider calculates the effort required to create the software. The cost calculation should also include the request keys. Subsequently, the process of offer, commissioning and start of the software development takes place.
Continuously determine the status of a software project.
Once the software development is started, many framework parameters are unchangeable. There is an estimate of the programming effort per request key and also a maximum total budget for programming the software. In most cases, the schedule and the available programming capacities are also already fixed. It is particularly important at this stage to keep a close eye on the project.
For this purpose, an exact database is required. It is best to have an effort estimate with the following information:
- Request Key
- Calculated effort in hours
The project status report requires the “% Done” value to be entered. This tells how far the programming task behind the Request Key has been completed. This consideration is independent of the required programming time. It is only about the degree of technical completion. If you maintain this value per request key, then you can easily calculate the equivalent value of completion in hours and the equivalent value of hours not yet completed in Excel. By summing them up, you get the number of hours that reflects the technical functional completion. In the chart to the right, this is 41.8 hours.
On the other hand, the programmers should have entered the actual programming time needed in a ticket system or another system suitable for this purpose. In the diagram this is 72 hours. So more time was needed than originally planned. If you form a quotient from the two values and multiply this by the calculated number of hours (in the example: 72/41.8 * 67 = 115.5), then you get a forecast for the hours until the programming is completed.
How can the software still be finished on time?
As mentioned above, many framework parameters of the project are already unchangeable at the time of programming. But what is to be done now if the project literally “gets out of hand” as in the example?
First, the project manager should check the parameters that appear unchangeable: Can the completion date be postponed? Can the implementation of individual functions be dispensed with? Is there perhaps still unconsidered potential, so that program functions can be implemented faster than planned?
In the next step, the project manager can check whether the framework parameters have changed outside the project: Has another project perhaps not been commissioned or scaled back, and can the programming capacity saved there help with the critical project? Are there perhaps other possibilities to increase the programming capacities? Or perhaps individual program functions can be outsourced from the service package and completed at a later date? Then, although not everything, the essential part of the software will be completed on time. Experience shows that careful planning coupled with reliable programmers (m/f) and careful project management usually lead to on-time completion of the software to be created.