Early in my career I was assigned a project that had been running for almost a year, but had never seen a single live release to the customer. On my first day, I was informed, “Welcome aboard! But you are already 20 days late! You have to deliver a release in the next 30 days!”
After checking with my fellow team members, I quickly realized that far too many dependencies weren’t getting resolved. Yet the team had to continue plugging away — designing, coding, doing integration testing and so on, always to discover at the 11th hour that dependencies couldn’t be resolved. Hence, I decided to put risk management as a top priority.
Risk management was a very new concept there and, hence, resulted in a lot of skepticism. With the introduction of risk management, I added reserves to the Microsoft project plan. This resulted in an increase of effort. Typically, no one likes bigger estimates, especially none had ever existed before. I readily sensed the unhappiness over this plan change, and it became a major obstacle to get the approvals we needed for those changes.
I assigned risk owners and risk response owners. The missed actions and their impact on the project were also highlighted in all the status reports from the start.
If any response had to be taken to reduce the risk before working on a task, my approach was to reduce the risk first to an acceptable limit and then perform the task. If that wasn’t possible, I wouldn’t allow anybody to work on the task. For example, if a WAP URL (used in mobile apps) wasn’t available for final testing, I wanted a simulated setup to be ready before any development work could begin.
Additionally, risks that couldn’t be handled were quickly and progressively escalated. This created more ruffled feathers as some stakeholders weren’t used to being called out so publicly. It was a daily battle with not-so-pleasant outcomes. But I had no choice. Without those measures in place, I knew the release would never happen.
One day a senior manager dropped by who was obviously irritated by the perceived delays, especially when this person saw that I was stopping tasks where risks weren’t mitigated to acceptable limits.
I was asked, “You have already factored in risks in the estimates, right? And also you have added the reserves. Fine! But why are you asking people to stop working on the tasks? Don’t the buffers you have in place take those risks into consideration?” To his way of thinking, if risks were factored into the schedule and cost, that should be enough to overcome the issues the team was facing.
My response was this: “When you know a cyclone is going to hit in five days, do you wait to act on the fifth day or do you start immediately working to mitigate the expected impact?”
He wasn’t happy about my answer. But I’m OK with that. After all, for the first time in that project’s history we made the release — and it took us just over 30 days.
