top of page

Case Studies

Here are few examples of Rescues I have led. The initiatives mentioned below, were mostly large and very complex, but I have deliberately kept the write-ups very high-level. However, I am happy to provide more context and any lessons learned if you are interested.

Fast & Furious Delivery

Some years ago I received a call from a C-level exec at a large company. She told me that she needed a "fixer" and had been given my name.  There was a government mandate that would hit in 3 months, affecting the very core of how her business operated, and touching 2/3 of all operations, and they hadn't started work on it yet.

  • Competitors had started as long as 2 years prior 

​

What we did:

​​

After a quick assessment, I called in some favours and hired a crack team that included the best BAs, PMs, Test Lead and Testers.

 

  1. Priority - I asked the Board that my project be made the number one priority, with everything else being secondary -- stressing that failure would literally put the company out of business. As a result, over 200 people were re-allocated to my team, and some other projects had to be deferred. 

  2. War Room - We set up a "War Room" where BAs, PMs and Test Lead all sat in one room which helped with collaboration and rapid decision making. Everyone helped everyone else.

  3. Agile Requirements - we created a spreadsheet format to capture requirements quickly and consistently and offloaded sections to be worked on, in an agile manner.

  4. Risk Management - we set up mechanism to quickly escalate and respond to risks and issues - often same day, so they we didn't get bogged down.

  5. Vendors - we set up a team to engage the over 120 vendors  involved, and planned jointly the changes & testing of the over 30,000 interfaces in play.

  6. Communications - we set up a communications committee and developed standard messages, channels of communication, cadence/timing and what each audience would need. We pro-actively "over-communicated" with our customers so they felt at ease.

  7. Daily Stand-ups - as development and testing started, we ran a daily standup to address issues quickly.

  8. Training - we created training programmes for all staff, including specialist CBT training for those at the coal face.

  9. Call Center - We staffed a new call center, with 20 people answering phones to handle any fallout. (In the end we didn't need this because we had no issues at all when we went live.  We received exactly 2 calls in the 6 weeks after go live, both of which were just questions that we could answer easily!) 

​

After a hectic and very difficult 3 months​, and working right up until the deadline, we delivered the solution and had zero fallout. We continued to communicate with our vendors and customers, and eventually released the Development team more quickly than expected as we had no warranty items to address.​​

Governance Down

Some time ago, I got a call from the leaders of a large organisation. They had been set aggressive targets to double their revenue but their PMO was not delivering. In fact the new management team which had taken over had recently let the PMO Director go. There was a sense that projects were late and over-budget, but the leadership wasn't getting good metrics to know for sure - project status reports were simply not telling the story. (In fact as I drilled in, I found most projects were red)

 

In it's "As Is" state, the PMO would not able to support the growth needed.

​​

What we did:

​

After talking to all the PMs and stakeholders including C-suite, I put together an aggressive plan and we started to overhaul the PMO. Here are a few things we did:

  1. Status Reporting - We created a new  traffic light format  for weekly status reports, and also rolled these up into to a portfolio dashboard. 

  2. Risks & Issues - We created new RAID templates, consistent across all projects, and ran risk sessions to identify and mitigate risk. We identified dozens of new risks. We set up bi-weekly meetings with Senior Leadership Team (SLT) to get help with any stubborn risks and issues. 

  3. Resource Forecasts - We created a new resource forecasting model, and put estimates into it for all projects. This showed that some types of resources, like Developers were at 150%.  As a result we had to replan, including deferring scope, cancelling lesser value projects, and bringing in additional resources including Developers, Testers and PMs.

  4. Financial Tracking - we built new financial forecasts and trackers and in using these, found lots of accounting errors, which were fixed in partnership with Finance. We found some projects were over-budget and made adjustments as necessary.

  5. Templates - we built out new document templates, such as New Project Request to make them more valuable.

  6. Intake Process - we revamped intake of new projects, so that we had the right information and ROI data to know what to move forward with.

  7. Agile - we started bringing in agile to have as an option for projects where it made sense.

  8. Staff Development - we identified weaknesses in PMO staff and started coaching and training to address.

​

Overall, we upped the pace at which the PMO worked, and held people accountable, as well as making the PMs feel supported and able to ask for help.

​

After only a few months, we had a dashboard that showed 21/22 projects were green, and we had a solid base to address the change and expansion coming.​​​​​

Mission Impossible: Vendor Edition

In this case, I joined the project to rescue it. Project was late and over-budget, with an immovable end date (government mandate). 

​​

What we did:

​

After talking to Executive Sponsor and key stakeholders, and sitting in with requirements sessions run by the vendor responsible for delivering a customised version of their software, I think I knew what the issues were. Most of the problems related to the vendor providing the software that was central to everything we were doing.

​

  1. Partnership vs. Confrontation. Although the client team felt that most of the issues lay with the vendor, I knew that we needed to partner with the vendor. There wasn't time to change horses, mid race. If the vendor failed, ultimately my client also failed and the consequences for all concerned would be massive. We looked at every problem through the lens of "how can we solve this together" vs. making the vendor solely responsible

  2. Initially, the vendor was not responsive when challenged.  I scheduled some very tough meetings between myself, the vendor and my Executive Sponsor. We had to persevere, and as part of the go forward solution, we insisted that they swapped some staff out. They added a new account manager and strong PM & architect on their side and this really helped. They also added testers and this allowed us to do continuous testing -- agile style.

  3. The vendor lacked process. They didn't have a 'script" or process to land clients (like us). Scope boundaries were uncertain and seemed to change as we went along: 

    • I worked with their management to help them get together flows and templates to gather key items they needed from us.​

    • I helped identify all the areas needing requirements and together with the vendor we scheduled daily sessions to cross off each subject area quickly and efficiently.

    • We put in place a robust approvals & change process to help manage scope

    • We put in place a rapid escalation process on both sides to resolve issues and questions quickly.

  4. The vendor had sold us vapour-ware.  As time went on it became obvious that they didn't have all the functionality they had sold us. ​

    • Frustrating as this was, there wasn't time to switch vendors, so we worked with them to quickly identify Minimum Viable Product (MVP) as release 1, and then drove towards getting it as a team. We agreed on follow on phases for less critical functionality.​

    • Availability 24x7 was key, and by drilling in, I found that the vendor had never done a fail-over or DR test.  I forced them to DR test, and as expected, they failed the first three times we tried. They were able to correct their solutions eventually, but the key learning point is to always ask for proof of things like this.​

  5. We got back some money. We carefully documented all the issues and my team estimated the extra expense on our side as a result, and we got the vendor to refund this from software license costs.

​​​​​

The Importance of Being Earnest… in Contracts

This is less of a rescue and more of a situation where, by applying best practice to contract development, I saved a lot of money for my client.

​​

What we did:

​

I was involved in creating the contracts covering a vendor in this USA engagement worth about $500k (USD). 

​

Long story short, the vendor came on site and failed to perform as expected. We tried to work with them to fix the issues, but after many failed attempts and insufficient progress on their part, we made the tough decision to fire them. They argued that we owed them about $75k.

​

Because I had put the following into the contracts we were able to get out of the contract, while owing nothing:

​

  1. Strong scope definition, with meaningful description of what the "solution" needed to include (the "what" rather than the "how")

  2. List of deliverables & project artefacts with specific, tangible/measurable acceptance criteria for approval of each deliverable:​

    • What vendor team is expected to deliver, vs. client team

    • Use of named client templates/format for documents (where necessary - e.g. Test Plan)

    • SLAs and non-functionals where applicable/known

  3. Vendor staffing:​

    • Roles that the vendor team must fill (e.g.  BA, Tester etc)

    • Inclusion of vendor staff CVs (with approval on client side)

  4. Strong client approval process with client sign-off

  5. Strong change request process with client sign-off and SLA on estimates for changes

  6. Deliverables grouped by phases:

    • Vendor must deliver x phase by date y

  7. Phased payments linked to successful sign-off of each phase

bottom of page