Many years ago I worked on a three-way project with 1) a customer, 2) a well-known equipment vendor and 3) a service provider (my client). Time-frames were particularly tight, not so much because of the technical challenge, but because of the bureaucratic processes of the customer and the service provider. The project was worth well in excess of $100M, so it was a decent-sized project as part of a $1B+ program.
The customer had handed the responsibility of building a project schedule to the equipment vendor and I, which we duly performed. The Gantt chart was quite comprehensive, running into thousands of lines of activities and had many dependencies where actions by the customer were essential. These were standard dependencies such as access to their data centres, uplift to infrastructure, firewall burns, design approvals, and the list goes on. The customer had also just embarked on a whole-of-company switch of project management frameworks, so it wasn’t hard to see that related delays were likely.
The vendor and I met with the customer to walk through the project plan. About half-way in, the customer asked the vendor whether they were confident that timelines could be met. The vendor was happy to say yes. I was asked the same question. My response was that I was comfortable with the vendor’s part, I was comfortable with our part (ie the service provider’s), but that the customer’s dependencies were a risk because we’d had push-back from their Project Manager and each of the internal business units that we knew were impacted (not to mention the other ones that were likely to be impacted but we had no visibility of yet).
That didn’t go down well. I copped by far the biggest smashing of my career to date. The customer didn’t want to acknowledge that they had any involvement in the project – despite the fact that they were to approve it, house it, host it, use it and maintain aspects of it. It seemed like common sense that they would need to get involved.
Over the last couple of decades of delivery projects, one trend has been particularly clear – the customer gets back what they put in. That project had at least twelve PMs on the customer side over the 18 month duration of the project. It moved forward during stints under the PMs who got involved in internal solutioning, but stagnated during periods under PMs that just blame-stormed. Despite this, we ended up delivering, but the user outcomes weren’t great.
As my least successful project to date (hopefully ever), it was also one of my biggest “learnings” projects. For a start, it emphasised that I needed to get better at hearts and minds change management. There were many areas where better persuasion was required – from the timelines / dependencies to the compromised architecture / hardware that was thrust upon us by the customer’s architects. What seemed obvious to me was clearly not so obvious to the customer stakeholders I was trying to persuade.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email