Delivery management is the intricate process of assuring timely delivery of quality software products and services within the agreed budget, while at the same time, ensuring a fair share of profit for the company. One needs to be strategic with proactive thinking, not just to correct issues that arise during the project phase, but to take nececarry actions to prevent their occurrence too. Because as the old saying goes, prevention is always better than cure! Here are five ways to reduce time and cost overruns in projects, and some pointers to help you deliver a successful project.
This would be the best approach, as Agile is one of the most flexible project management models in use. Let me give you a brief overview for those who are not familiar with the concept. Agile project management accepts that change is one of the major risks which needs to be dealt with in projects. Change means a change in requirement, change in timeline, change in budget, or any such factor which decides the project’s success. The Agile approach deals with this risk in multiple ways.
Plans are prepared for providing work output usually a week or two at a time. This time frame is called a sprint. Deliverables of each sprint is internally tested and submitted to the client, who reviews it and provides feedback to the development team. This results in progressive constructive feedback about the work being undertaken, thereby eliminating surprises at the last moment, once all the work is finished and submitted for client review.
An Agile project team’s maximum size will be around ten, including developers, BAs, QAs and project manager. All team members will have the authority to make decisions which are beneficial for the project, and such decisions will be communicated across the team. Knowledge is not centric to any particular division within the team; it is rather spread across all team members.
As hinted in the previous point, all details regarding the project are communicated with all the stakeholders. Development builds and demos are planned at the end of each sprint for clients, and they provide open and honest feedback which is taken into consideration for the next sprint. Daily stand up team meetings are a good way of keeping everyone (including the client) updated about the project status. Sprint backlogs are maintained and updated daily to keep track of progress against each task committed for delivery in a sprint.
While planning your sprints, plan for dummy sprints in between, with no work planned except for handling bugs identified in previous sprints and adjusting minor changes in overruns. You can plan for a dummy sprint after every third or fourth development sprint.
Doing proper research on the planned area of work – both general and technical - is essential for understanding and sizing up the requirements. Even after the project starts, make sure you have architects in the consultant role so that your team does not get stuck on issues due to unavailability of expert advice.
Continuous integration is achieved using GitHub or Bitbucket. The code is managed from three branches – Development, Acceptance and Production. Development is the branch where actual coding work is performed. Developers check out code, make modifications, and check them back in only in the Development branch. Once development is complete and unit testing is performed, the code is deployed in Acceptance branch, where it is subject to thorough testing by the QA team.
Any feedback received is worked upon in the development branch, verified, and re-deployed in Acceptance branch. Once it is confirmed that all functionalities are working as desired, the acceptance copy is moved to Production. No work whatsoever is performed on the Production branch – ever. This lets us quickly revert to stable code, in case of unforeseen adversities.
Integration testing and product testing should be performed on the produced code to ensure its compliance with stated requirements. The Requirement Traceability Matrix (RTM) will help you in this process. Business Analysts list down each requirement in the RTM document. Integration test cases and product test cases are prepared by QA team members, and are linked with each requirement in the RTM. Testing is performed in the Acceptance code branch and only QA certified code is released to the customer.
This is at the heart of project management process, and demands considerable amount of ‘thinking out of the box’ and creativity to perfect it. However, a delivery manager’s strength lies in managing unforeseen risks from a perfect plan on a daily basis. Contingency and mitigation plans are prepared to handle such scenarios. The decision about which one of these needs to be prepared is based on two parameters – impact of risk and probability of its occurrence.
Figure: Selecting a Risk Management Plan
Contingency plans are prepared to deal with risks that have high impact, but low probability of occurrence, while mitigation plans are prepared for risks with high impact and high probability of occurrence. Essentially, you need to prepare risk management plans for items with high impact. Both these plans identify risks, list associated stakeholders, and detail steps to be taken in case of occurrence of each risk. We hope the information shared in this article helps your team use the Agile project management approach to reduced time and cost overruns in your next delivery project. Need help getting your app business off the ground? We are happy to assist!
Subscribe to our newsletter and know all that’s happening at Cabot.
YOU WILL BE HEARING FROM US SOON!
We look forward to hearing from you!
YOU WILL BE HEARING FROM US SOON!