Monday 22 July 2013

The Sales vs Implementation Trap


Recently the news has been full of failed tech projects. Some are major government investments that have either been canned or are currently at risk. Others may be smaller yet the waste of time and money, not to mention the impact on reputation, are no less significant for the business or suppliers concerned. 

The reasons for failure are many and varied. Often seeds are sown during the early stages before there’s any sniff of a project let alone implementation. Expectations on both sides of the fence form and quite frequently remain unspoken. These sprout and grow as time progresses.

Back in 2011 I wrote a blog post about expectations of stakeholders and the role they play as an initiative moves from sales to implementation. It was a lead in to a guest spot on PMChat with Robert Kelly and Rob Prinzo. It's as valid now as it was then so I'm republishing it to trigger thinking and maybe, just maybe, tangible change through action.


“What do you mean, ‘it can’t do that’? That’s not what we understood / were told / led to believe. You have to change it but don’t think for a minute we’ll be paying for it!”

Recognise this? It should be familiar to all Project Managers. With expectations being set so early in the engagement cycle it’s no wonder PM’s spend significant amounts of time managing and / or realigning them. Life as a PM would be so easy (boring?) if this effort wasn’t necessary but expectations are established early and to complicate matters further often vary significantly between stakeholders. 

What are expectations and where do they come from?

An expectation is when a person has a strong belief something will actually happen or be the case in reality. In terms of projects, stakeholders are disappointed when what happens in reality doesn’t live up to or match their belief. If we separate sales from implementation we can quickly see how expectations are formed and where sales can confuse implementation.

The Sale is the pre-requisite to Implementation, that much is obvious. Simply put the buyer wants something that meets certain pre-defined requirements and the seller thinks they have the very thing that will satisfy those wants. This information is shared between the two parties during different stages of the sales process. But what’s shared isn’t always the full picture because:
  1. Focus is on key or critical processes only
  2. The end-to-end process isn’t always understood internally
  3. Many process steps are simply forgotten 
Process
What happens
Expectation created
Requirements analysis
As-Is Needs Analysis:
Companies have a tendency to look inwards capturing the As-Is or status quo and labelling it as business critical, rather than defining the To-Be organisation to support the future business and the gaps to fill in order to get there.
To do the same and more, faster, cheaper and with a shiny new wrapper.
Meetings and Discussions
Fragmented Dialogue:
Information exchanged during discussions may answer isolated questions but make little sense when reviewed against the bigger picture.
The complete process has been fully understood in its entirety.
Demonstrations and References
Selective Functionality:
Demonstrating how a business critical process can be handled without showing every step in detail.
The end-to-end process is satisfied and all complexities are clear.
Proposals and Documentation
Positively Pitched Documentation:
Words have a universal dictionary meaning however they’re not used universally which can influence interpretation. Stakeholders then add their own interpretation which creates another layer of meaning that usually remains unshared.
The stakeholder will receive exactly their interpretation of the meaning.
Commercial Agreements
Vagueness and Legalese:
Lawyers review the wording, clauses are changed, details are vague and assumptions are made that remain undocumented and not communicated to the implementation team.
The contract confirms the customer is always right.

Once formed every conversation the stakeholder has or document they read will further embed or increase these expectations so by the time the implementation cycle begins they’re set.

Because expectations are the beliefs of individuals we shouldn’t automatically judge them as right or wrong. As implementation begins the PM has to figure out what expectations do exist, how they formed, what they’re based on and where realignment needs to occur. I say realign rather than change because while you can provide all the information and knowledge to support a position and influence realignment, only the stakeholder can change their mind. 

Realign for project success

In order to realign expectations the PM must be both informed and objective. Ideally the PM gets a thorough handover from the sales process but unfortunately it usually consists of a quick rundown on general agreements and requirements supported by a few documents for the PM to interpret. Therefore as implementation kicks-off the PM must quickly:
  1. Understand stakeholders existing expectations
  2. Uncover the basis of their formation
  3. Identify realignment opportunities where necessary
Perform a simple audit by reviewing all existing documentation including the contract, any schedules, project charter etc. Also review any assumptions or notes attached to other documents such as the business case and budget calculations. Capture the mismatches by identifying issues and contradictions. Work with the team to come up with solutions and any associated costs, timeline changes etc. Table these with the Sponsor as early as possible in order to gain agreement or direction, support and assistance with re-educating and realigning other senior stakeholders. This isn’t a one off exercise. Projects benefit when the PM keeps this output as a point of reference and maintains it throughout the implementation. Chapter 4 of Todd Williams’ book “Rescue the Problem Project” provides excellent guidance when it comes to auditing project documentation.

Whether the PM has access to all documentation or not it’s crucial that every conversation is a fact finding conversation. Talking is one way but an interactive conversation yields more information especially if conducted in an informal relaxed environment. PM’s can check what they learn against their cross-reference output, seek further clarification and engage in realignment discussions if needed.

All stakeholders need to be aligned with the direction set by the Sponsor. Sharing the cross-reference results while practising active listening means the PM can drill in to what isn’t being said and rise above the detail to objectively observe activity. Staying in constant touch and open dialogue engages key stakeholders who can then assist with realigning others.

The differences between the sales process and implementation will always be there but with a bit of effort a PM can use every discussion, issue raised or risk mitigation plan as an opportunity to realign expectations in the project and across all project stakeholders.

What challenges do you experience in this area and what techniques do you use to address them?

2 comments:

  1. How important is it to distinguish been what are contractual requirements on a project against what are discussions or suggestions? I have worked on projects where quick emails seem to carry just as much contractual weight as formally reviewed and signed off documentation. I know ongoing scope management is a key part of a contract, but is it possible to have an initial legal statement of project expectations?

    ReplyDelete
    Replies
    1. Thanks for the comment Paul. You've posed some interesting questions. What you've experienced is quite common. First let’s differentiate 'contract' from 'Statement of Work' (SOW) or 'Annex' or 'Schedule' or whatever other label you want to assign to the documents attached to the contract. The contract is more about the legal relationship between and obligations of the two rather than what’s to happen at the delivery level. The contract will refer to the services as specified in the schedule, which is about as close as it gets to legal statement of project expectations.

      I think the way we use language and conduct conversations or email exchanges has a lot to do with how and why these things turn into obligations. To my mind it’s about context. The person is asking the question or making a request with something in mind that doesn’t come through in the email or discussion. The answer is given at face value with little to no context but interpreted and evaluated against the missing piece. Assumptions get made and expectations are created. So, it’s probably less about Contracts and Schedules and more about communication skills, active listening, and being sufficiently aware to ask more and different questions before giving a response.

      Most of the time stuff like this happens because we’re all conversing from a different starting point. Will another legal statement in the contract change that? Doubt it. Would adding a disclaimer to everything make a difference? Maybe, maybe not. Should everything be verified and validated with the contract owner? Possibly, though the overhead could put a quick stop to that.

      Regardless of experience level these things still catch people out so it then comes down to how successfully the fall-out’s managed. A magic wand wouldn’t go astray either…

      Delete