Month: October 2014
It was always going to be a challenging project. The end users had the attention span of a gnat. The delivery was to change their way of working significantly. We knew we were looking at an uphill battle of acceptance, agreement and adoption. But it was a transformational project and had benefits beyond the front line use (CRM).
My key sponsor knew how to play this landscape and knew how to navigate the culture and habitat of the business. As such he drove an extremely hard line on the project team and maintained a level of focus and engagement that ensured that we did the “right things”, not always “did things right”.
As the project manager this approach often conflicted with the fundamental way minds work in an engineering project discipline. It clearly did not sit well with the project team. “Where is the best practice?” rang in each team meeting, “this doesn’t work with the deliver dependencies in the plan!” Somehow we needed to find common ground and understanding with the business and agreed demarcation of decision making and domain respect.
I was accountable for the delivery of the solution. It had to meet the business needs but also needed to be sustainable and workable across the wider solutions and process platforms. It also must protect the long term ROI by the manner in which we engineered the solutions for several international areas of the business.
Some environments can tolerated the “do the right thing” v’s “doing things right” approach and other will push back. The birth of Agile PM as an example has been bastardised from it pure efficiency gains into a delivery expectation paradigm which is wrong, wrong, wrong. It places business, projects and outcomes at risk by setting expectation that do not align to a design and puts avoidable pressure on all sides of the project. Some things we build need foundations; it isn’t just painting and decorating!
However, in this instance my sponsor had the positioning bang on and influenced the way I priorities and multitasked the project into what would “curry” favour with key stakeholders, answers their concerns and keep the project from by flushed down the loo! The key was to make an early deliverable to the end user communities and make an immediate and important win whilst building solid reputation and greater tolerance of the project for doing thing right going forward.
I must confess, at the beginning of this journey this approach created some degree of challenge for me and great anxiety for the team. It went against all my experience and best practice as a PM. I was tasked with managing a delivery whilst my sponsor was tasked with delivering an outcome. I have since come to realise that these in essence are one and the same.
So over too many drinks one night this miss-alignment resulted in a heated debate (constructive and open) between us. My sponsor resolved it by setting me a test. This proved his point and influenced how I would assess delivery forevermore.
“You have been out all night drinking copious amounts of beer. You’re hungry and in desperate need of a toilet. You grab a microwave curry on the way back to your flat. Keys in the door into the hallway and you see that you have some messages on your answerphone (those were the days). So you’re hungry, desperate for the toilet and there are messages waiting for you. What do you do first?”
I’ll leave you to work out what is the correct answer and please let me know by leaving your comment below,
Suffice to say this approach has continued to influence my thoughts and approach in engagements and project management. Where there is a clear need for “quick wins” that conflicts with “best practice” it is important to find a way forward that allows leveraging greater stakeholder tolerance of the wider delivery and a more pragmatic direct focus on doing the “right things” by the team in order to do things right.
As a leader of the project team my task is to gain buy-in from all parties to identifying why a “doing the right thing” by your business stakeholders is the first deliver that any project needs to make.