Uncertainty in Software Project
Today is a closing of “The IndiPro Project”, the project I co-managed during the last 1,5 months in Hexavara Technology. I want to share some stuff related to the project, but before that, I want to introduce a little bit about IndiPro. So, IndiPro stands for IndiHome Provisioning Reserve on Demand. If you want to set up Indihome services (Home Internet, Home Telephone, and Interactive TV) or you are current IndiHome’s user and have a problem regarding the service, probably you want someone to come to your place and set up/fix that problem, right? This is a system that enables you to get a technician that can do those stuff for you. You can take a look at what my team had built here.
The process started with requirements gathering with the client to better understand their needs. As I said earlier, they want a system that enables customers to get a technician to come to their place to set up IndiHome or fix problems related to the service. We offer a web-based system to simplify the process so that customers don’t have to install apps to get the service. That need means there must be a system too for the technician to manage the customer’s request and proceed it to related division/business function. We need an app for those kinds of capabilities. We then work with the details and give them the system design and mock-up. After several iterations and calculations from our side, then the business contract is made and the project started.
The project executed using the SCRUM development method where the requirement translated into the product backlog and then deployed into a sprint that executable on a 1-week basis. At the end of the week, we held a sprint review with the client to deliver the progress and ask for feedback. This process often leads to several changes in the next sprint due to that feedback or changes in the requirement. Sometimes the new requirements came in this process. If those are minor requirements and still in the project scope, we put that in the next sprint. But if that a major one, we need a further discussion because possibly that requirements are out of the contract. The solution is either adjustment in the contract or scheduled into the next project.
Successful project delivery is defined by the completion of deliverables as per the objectives of time and cost. Project closing as the last stage in the project management is the process performed to conclude all activities across the project are formally completed. As per Aziz (2015), a project must be closed properly because if not, the project management team and the project team’s efforts, time, and credibility may be negatively perceived for matters that are not their fault or responsibility.
I basically agree with that because there is so much uncertainty in the software development process. Requirements change pretty often and new requirements exist during the implementation phase of the project. These unclear requirements often lead to several problems such as lateness in the delivery, contract adjustments, and probably miss-understanding between two parties that can lead to a reduction of customer’s satisfaction. These changes must be well-documented during the project and are agreed upon by both parties to minimize miss-perception. The project closure functionates as a recap of all those changes.
