“You can have brilliant ideas, but if you can’t get them across, your ideas won’t get anywhere” – Lee Iacocca
The quote from Lee Iacocca is absolutely true. If you are not able to articulate what you want, you cannot expect that your implementation partner (the Vendor) is able to deliver it to you. Having said that, there is a key component missing. The existence of implementation partners is their expertise and capability to help you define what you want, such that your needs get fulfilled. Oftentimes that is not well understood and/or executed throughout the project life cycle.
Dilbert (by Scott Adams) hits the nail on the head with his strip about a customer that wanted a swing on a tree. It indicates that there is kind of a ‘broken telephone’ between the project stakeholders. None of them actually truly understood what the customer wanted and all reasoned from their own paradigm and communication matrix.
Let’s say for a minute that there is a mutual understanding of the need between the customer and implementation partner. Can it still go wrong? Absolutely. There are many factors that can still make the outcome of the project not to be acceptable to the customer. Think about lack of quality of work, contractual disputes, shortage of resources, resistance to change, competing business priorities, low trust culture, and so on. Having said that, it appears that proper communication is the main success factor.
It is key to sing from the same song sheet, but how do you make that happen? Here are a number of practical measures:
Make communication meaningful: Many verbal and non-verbal communications can be much better coloured with proper wording and visuals such that they become meaningful for the recipient. I have been in many meetings where people leave the room with a completely different understanding about the outcome; at times the complete opposite. Oftentimes it happens, because the meeting is not well prepared. A very effective way to change that is to have the key messages that you want the recipient to take away, well documented on a single page. Use visuals with key words as much as possible. Acknowledge the response and feedback from the audience by paraphrasing it throughout, and summarizing it at the end of the meeting. Document the outcome and send that with the single page to the participants by email. If the subject comes back in subsequent meetings, start off with setting the base line by sharing what has been discussed to date. You want to avoid ‘wheels to spin’.
Synchronize the different communication matrixes: People with different backgrounds who come together in a project to work collaboratively on achieving the project goals need to be set up for success. That is a key responsibility of the customer as well as the implementation partner. Setting the project and team members up for success entails more than conducting a project kick off and reading the project handbook and other on boarding material. Both organizations need to understand that to be effective as a whole, it is crucial that project staff can ‘speak the same language.’ Train your project staff in the software product, methods and tools, project approach, roles and responsibilities, processes and procedures. Maintain a common set of definitions, templates and guidelines. Make this training a repetitive process as we all tend to forget elements over time. Lunch & Learn sessions are oftentimes an effective instrument
Document along the way: ‘Better have it documented.’ If that is part of your style you’ll go far in projects. In my previous blogpost ‘Continuity of Vision’ I wrote about the different kind of documents that you want to use from start to finish. Critical is to be mindful of the fact that WHAT the organizations wants is changing over time as insight grows and/or priorities change. That is a given and both organizations have to manage that change properly and not be surprised of it to happen. Documenting the requirements, design, build, etc properly and consistently along the way can become crucial and a factor of success or failure for the overall project
Build checkpoints into project approach: It is imperative that the customer wants to see what they get well in advance of the formal acceptance phase. Implementation partners can be difficult when you ask them to demonstrate the product while it is going through the design and build phase. It is perceived as a non-productive step or as a delivery risk, especially in fixed price contracts. Understand that Implementation partners do not always have the capability (read: qualified resources) that they signed up for, or customers may change their minds of WHAT they want after a demonstration and they expect that change to be at no cost. This can all be prevented if both organizations agree what those checkpoints are and how change will be addressed as it occurs
Implement an effective escalation path: When organizations engage and embark upon a new project it is the right time to think about how to deal with conflict, because they will happen and when they do, you don’t want them to become lethal. Most of the time conflicts are about WHAT will (not) be delivered at the end of the day from a quality, cost or time perspective. It makes a lot of sense to consciously think about the escalation process from a business and legal perspective before you start the project. Oftentimes it is done from a legal perspective only, without proper involvement from the business, and then when problems occur, it turns out that what is part of the contract is not what the business wants to pursue. Avoid that from happening and define a pragmatic and effective process that has business and legal support. Think about including a mediation and/or arbitration step in the end-to-end process with named internal/external subject matter experts. Build in response times, such that the turn around time on conflicts (issues / disputes) can be managed and the impact on the critical path can be assessed
When quality of communication goes down, ambiguity goes up, cost goes up and the project timeline come under huge pressure. Avoid that and set your team up for success by implementing a robust framework of communication processes, procedures, methods and tools. Train your project staff along the way and lead by example.
Bas de Baat
Program Manager Enterprise Applications, PMP©