Hasty Decisions can Cost your Project
- Reshmi Sujesh
Reshmi has 16 years of functional and leadership experience in IT industry. Reshmi’s expertise includes Managing Programs across distributed teams globally, ensuring quality delivery from all aspects of Project Management. She also has expertise in running projects in Agile SCRUM.
Every project is unique and comes with its own set of challenges and learnings. During the life cycle of a project, there could arise scenarios that require careful analysis, critical decisions to be taken, risks to be evaluated and so on. Hasty decisions must be avoided in any situation. Hasty decisions result in adding substantial risk to the projects, rework, and frustrated and stressed teams. Let's understand hasty decisions using a case study.
Situation: During the user acceptance testing of an IT Project, which was part of a critical and prominent visibility program, a business user raised a high severity defect. The IT team analyzed the defect and found it was a new requirement, which cannot be addressed in the current release. However, the program team and their respective Business Unit confirmed that this requirement was always in scope for their testing and wanted the IT team to deliver the requirement in the current release without a formal change request. But, the IT team included this change in their backlog as a new requirement.
The Program Go-Live date was three months away and the expectation was all the impacted IT teams had to complete their changes well beforehand. If the Go-Live date was much later, what caused the urgency? The reasoning from the Program team was that they had no plan to make data available in the environments for the next releases and to avoid testing challenges they wanted this requirement as part of the current release and not in subsequent releases.
The IT team was not comfortable to accommodate the requirement in the current release as it came in very late when they were busy preparing for the project launch that was just two weeks away. Program leadership escalated to the IT Management to deploy this change during the warranty period if the teams could not make it up for the current release window. The IT Management, considering the visibility of the program, asked the team to assess quickly and deliver this change for the warranty window. A meeting was called with the IT team and they agreed that the change was low complexity and they are comfortable to deliver the change during the warranty window.
Warranty windows are only used to fix defects coming out a release. So this was definitely a deviation and required an exception. The case was tabled to the enterprise release management with relevant background. After endless meetings and emails, exception approvals were secured and the change got included as part of the warranty window. The code change was done and when it moved for testing, considerable defects were noticed and the team struggled to address these. Something was definitely not right. A meeting was called and that’s when the team realized the gravity of the situation. The solution was not complete and the assumptions that had been made had backfired! Boom!
With just two days left for the change to go, the team was really in a bad shape. The Program team was told that the change was descoped from the warranty window and new dates will be communicated. This resulted in very uncomfortable situations for the IT team and their management, all of which could have been avoided. Let’s try to understand the lapses which put the team in an awkward and unpleasant situation.
Acceptance without questions: The IT team and their management accepted the change and did not try to understand or challenge the program team as to why this requirement did not come to IT well in advance. Was it a result of the ineffective requirement gathering or missed stakeholder needs? Secondly, with the program Go Live being three months away, the team could have asked for more time by reviewing all the options they had rather than pushing themselves hard. The IT assessment of the new change was done hastily and communicated as a low complexity change.
Yes, the program was a highly critical one but the IT Management got pressurized by the escalations and they, in turn, asked IT team to deliver during the warranty window.
Deploying change during warranty window: Warranty windows should not be used to deploy new changes as they are strictly used for fixing defects arising out of a major release. Teams need to focus on ensuring production stability and not spend this time to handle new requirements. The IT team agreed to deploy the change during the warranty window without doing a proper risk-based analysis. They went through severe pressure to fix post production defects as well as to work on the new requirement racing against time considering the warranty period was only for two weeks. Significant effort was spent on seeking exception approval which at the end was a wasted effort.
Inaccurate Assumptions Backfired
Assumptions went wrong, which turned into risks and this became visible during the testing. They missed seeing the big picture and this impacted costs negatively. Assumptions were not properly reviewed and that backfired. Low complex requirement turned into a highly complex requirement.
In the above scenario, the entire IT team, which included the Project Manager, the technical teams and IT management are all accountable for the situation they put themselves in. Decisions were made in haste and they never anticipated the situation to go out of control.
In a project, considerable time and effort should go into assessing the situation in hand, performing qualitative and quantitative risk assessment, evaluating all the possible options and arriving at a consensus with all the Project stakeholders. Any decision has a consequence but a hasty decision is sure to result in wasted effort.
As Benjamin Franklin rightly said, “Take time for all things, great haste makes great waste.”