In the previous parts we described the various concrete dependencies of the software development process. These dependencies can be translated to actual costs that together create the total cost of a software development project. However, to successfully execute the project and to scale it as per requirements, the final few dependencies of the development process are time and execution related which need to be thoroughly understood and examined.
This dimension of a software development project is not really an estimated cost factor – it is included here just for completeness as this is one the artifacts required to make sure the client’s goals are met in a timely manner. A typical timeline is split into phases such as the following:
- PoC: The Proof-of-Concept phase is a non-trivial system built within weeks of the customer engagement to prove the feasibility of the client’s vision
- MVP: Minimum Viable Product is the essential set of features required to engage users into the system.
- Day-1 System: Post MVP, what are the first set of features required to make a full-fledged release of the software.
Execution Tracking & Delivery
As mentioned previously, agile development projects use an ALM to create scope artifacts and execute the development in 1 or 2-week Sprints. This enables the development team to be able to quickly react to changing requirements. It also allows the system to be built small pieces/features a time. However, agile development does not necessarily guarantee the quality of product delivered and this is where delivery steps kick in. Working closely with the team of both software and QA engineers, a person in a Delivery Manager role creates the necessary release artifacts which are eventually delivered to the customer. These will include deployed software in Production, Release Notes and Known Issues List. Towards this end, every software project will require at least a partially loaded person as part of the team in the Delivery Manager role.
Every major software system, no matter how mature, has problems when rolled into Production. This is in the very nature of software and cannot be eliminated through an extensive process or delay of the release. Depending on the criticality of the software system, there will be a certain appetite to allow issues and taking the risk of such issues manifesting in Production as compared to the time spent on identifying and fixing every issue during the development of the system. It is easier to plan a Production support team rather than spending time on never-ending QA cycles. A reasonable Production support team will consist of a few members from each of the various roles in the original team.