How our project planning and execution went Agile

The inside story of how Risk Quotient moved from a traditional Gantt chart based project management approach to the Agile methodology and a sprint based approach.

Change is the only constant

Nowhere is this more true than at Risk Quotient.

It was the early days of January 2019. The leadership team at Risk Quotient (RQ) had assembled for their weekly review hoping to finish it in an hour and go about their regular work. Little did they know. Just before the end of the meeting our COO stopped and ominously said, “Guys, and one more thing...” Our reaction was a collective “Gulp!”

“We have been managing our projects wrong and that should change.”, the COO continued, “Have you heard about the Agile manifesto/philosophy?”. The COO, sensing our reluctance to commit to knowing or not knowing about Agile, launched into an explanation of the Agile philosophy and what his vision was for RQ. In a nutshell, going forward he wanted the delivery team to start planning and managing their projects as per the Agile methodology. Plain and simple! 

The challenge 

RQ is a professional services company and provides cybersecurity, business continuity , cyber insurance consulting. One of our biggest challenges is our  dependence on client availability for completing our activities. This invariably results in tasks getting delayed owing to unavailability of people. However, since our traditional project management methodology prescribed, we did tasks in an orderly fashion, it meant there was a lot of unproductive waiting involved, further derailing the progress of the project. 

The Agile methodology promised a workaround, if not a solution to project delays. It gave the flexibility to the project manager to manage the project 2 weeks at a time. If people needed for a certain activity were not available in a given period of 2 weeks, those activities would not be taken up for execution in that sprint. Of course, this can’t be applied to all activities in a project, as some activities will have to be taken up before others and could prove to be bottlenecks. However, we could remove bottlenecks. What we were doing was building  flyovers over congested signals!

There were 4 main milestones that we fixed for ourselves:

• Sprint planning - picking tasks and activities for an upcoming sprint

• Mid-sprint review - reviewing to see if activities in the current sprint need to be added or deleted based on progress, unforeseen circumstances and other factors

• Sprint closure - closing the sprints at the end of 2 weeks

• Sprint retrospective - analysing what went good, bad and ugly in the sprint and why

The winds of change

Of course, we knew ‘Agile’, but that was in association with software development and couldn’t wrap our brains around the fact that we had to apply it to professional services. After having understood the basic principles of Agile and key jargon like sprints, retrospective, backlog etc. we thought we were armed with sufficient information to tackle this new challenge. 

The easiest next step would have been to buy software. However that would not have seemed like such a bright idea, if we were to later find out that the software does not check all the boxes for us. So getting software was the last step for us. We turned to our old reliable- the spreadsheet to help us out. This meant quite a bit of manual labour. Creating backlogs, creating sprints, relevant status options and flags etc, for all active projects. Our instructions were very clear. There was to be no “test project”. We were all in or not at all! 

We created spreadsheet based backlogs, sprints (lasting 2 weeks) etc. for all projects starting January 2019. The COO , delivery head and the Project management office, regularly monitored the spreadsheets to resolve the issues that had cropped up and to foresee issues that could surface in the future.

The next step was to start evaluation of various available services that offered SaaS based solutions. This was happening in parallel and so by the end of March we had our SaaS software that could help us with the sprints-way of working.

Get, set, sprint

Starting April 2019 all our projects had been migrated to the SaaS application. The sprint based project methodology  helped us to :

• Manage projects effectively, professionally and efficiently

• Keep our client informed of what we plan to do, when, what is the expectation from them in terms of time, resources etc.

• Assist the delivery head make appropriate decisions with respect to people, time and scope

• Provide a better MIS to our leadership

Pitfalls no one warned us about

As time passed, we realised that sometimes a significant number of activities were not completed in a sprint and as a result projects would get delayed. After a root cause analysis we pinned this down to 2 main reasons:

• No involvement of client representatives in sprint planning - Initially with only the project manager and the team involved in sprint planning, the client could not provide their input on people availability, priority tasks etc.. This led to some wrong decisions when creating the sprint backlog that could have been easily avoidable by involving the client in the sprint planning discussion. That was a change that was immediately made in our methodology. 

• Missing out the big picture - in our endeavour to effectively manage our sprints we sometimes missed on the bigger picture of project management. It was a classic case of “forest for the trees”. We figured that we can avoid this. This was a very subtle change that we were making in our project management style. 

It’s a success story for RQ and its project management methodology and we at RQ are extremely proud of it. It fits perfectly with our Think, Learn and Innovate philosophy. We will revel in its glory till we hear that certain voice in one of our leadership team meetings saying “Guys, and one more thing!”

“All professional services organisations should move to managing projects the Agile way.”