The Troubled Project

The Troubled Project

“The Story of a Turn Around”

When a Project Manager has a history of completing challenging projects successfully, then the management is always keen on throwing even more challenging projects your way. The same thing happened to me when I was assigned a very troubled project. 

The project was with a Federal Government Department and was regarding the implementation of a customized software solution. The project has been on and off for an infinite number of times. Both parties have tried numerous times, at their end, to even close the project but had no success. The situation was even more critical because the customer had started litigation against us. 

The management assigned me this challenge with the hope of some sort of revival. I had to plan the strategy extra carefully. As the customer was based in another city, so I had to plan the traveling part as well.

From the review of the available documentation and other information, I was able to see some obvious issues. The first issue was that the definition of scope. Since it was a Government Department, they had this mindset that they could change the scope any time they wanted and they were doing that quite frequently. The main reason was not just the mindset but also there was a frequent change of responsibility of heading the project from the customer side (Product owner) as they either used to get promoted or get transferred to some other department. Every time a new person (Product Owner) takes up the seat, he/she has his/her definition of the scope and always denies owning the scope agreed by the previous persons. Due to this reason, all the completed work would go wasted. 

Another important thing was that the scope, whatever was agreed, was either not documented or whenever it was, to any extent, the customer never officially signed it off. This was again mainly due to the previously mentioned issue of the ever-changing Product Owner.

One issue, I noticed, from my employer’s end was that they have been committing completion dates based on just the verbal understanding of the scope. Since there was no formally agreed piece of artifact regarding the scope of an assignment so any change of mind or change of Product Owner meant going back to zero. 

One more observation I made was that the project had always followed the traditional waterfall methodology so every time all the phases have to start from the beginning for the whole scope of the project and as a result there was a large amount of “waste”. Since the customer was based in another city, resource onsite deployment had been a challenge as well. To manage that issue mostly the technical resources were mostly working remotely on this project.  

In my first meeting with the customer, I was accompanied by a Business Analyst who had a technical resource, both of them had previously worked on this project. The reason I wanted to take along both of them, especially the Business Analyst, was because I wanted to have a “familiar face” for the client and also wanted to discuss some issues in the current system.  

The meeting, as expected, started with the customer blaming us for the failure. Once things cooled down a bit, I started the discussion of the future strategy with them regarding how to take this project forward. Good thing was that both sides were still very keen on completing this project successfully so the customer agreed to almost all parts of my strategy. 

The foremost suggestion in my strategy was to change the project execution methodology from Waterfall to Agile. For that, I suggested 3 weeks of Sprints and each Sprint will include defining scope, executing work, review, and sign off the completed work. So in principle, I was focusing on providing the customer some food for thought in every iteration. The client will decide which items are at the highest priority and should be completed next and also they will be at liberty to make changes and add items to the backlog. The most important thing was demo/review of the completed work and signoff by the customer at the end of the iteration. 

I also arranged for the technical resource to be deployed on-location to be joined by one more resource later. This allowed the technical team to closely work with the customer, especially during the UAT sessions, and quickly fix small issues as well as those items which only required some sort of understanding, etc.

The switch to Agile Methodology worked well. The customer started to experience the practical benefits of Agile. The customer took more interest in the selection of scope for each iteration and as it was more practical so they were able to get some completed work at the end of each sprint The customer was very comfortable in signing off the completed items. Short iteration meant less risk and frequent delivery of items so the issue related to the frequent change of Product Owner stopped affecting the project. There was a sense of achievement, at both sides, at the end of each iteration. 

I think two things contributed mostly to the successful closing of the project; the first was the adaptation of Agile methodology and the second was the support I got from my employer. They were keen on successfully closing this project at any cost and even they had to bear the high financial cost to achieve that target. They procured experience resources and also either posted them on-site or arranged frequent but flexible traveling and accommodation for them. 

Share this post

Leave a Reply

%d bloggers like this: