Three Ingredients of Good Partnerships

For the last several years I have been working in the partner channels organization at EMC. It has been a fascinating learning experience to watch the interaction from this angle and I was asked the other day why some relationships work and others do not. Having now been a customer, a partner and a vendor I can say with absolute confidence that this triumvirate is the most powerful but potentially dysfunctional relationships in business. I stress the word potentially because it does not have to be dysfunctional. The recipe for powerful IT partnerships must include a careful mixture of three key ingredients. Ownership, Focus and Communication. 

The Buck Stops Where It Started

Almost every complex deal has ownership problems. The project has a finite budget and the providers of services and software all want as much of that as they can get. This isn’t greed. It is capitalism. Deal with it. Consequently each participant wants to own as much of the decision making process as possible to ensure their cut. All too often though the customer is far too willing to abdicate too much of the decision making to the integrators or software vendors. They are all too willing to accept outside direction but it is the root cause of more downstream problems than you can imagine.

Project ownership cannot exclude the customer even if they want to give it up. The buck does not stop with the systems integrator. It stops where it started. With the source of the funding. This requires that the project owner learn enough about the work being done and take responsibility for decisions that are made. Ensuring plausible deniability only guarantees that the project will suffer from abuse by those that benefit from overreach. This overreach takes many forms. Poor product selection based on what the SI knows best instead of the best fit for example. Production support issues because every blinking light triggers a call to vendor support when there are easy in house remedies that are much faster.

This does not mean that the customer does not ever need a partner. Far from it. Your business is in other areas and they are experts but unless you can afford a chauffer you need to learn to drive. Own what you are paying for in more than just accounting.

For the integrator it is about going beyond the letter of the SOW to work with the vendor for the success of the customer. A technology partnership goes far beyond the boundaries of any one engagement and the totality of the relationship and success over time has to be considered. Sometimes this means one or the other taking on a problem that was not their responsibility but is within their power to fix. Don’t simply own the project, care for it.

Focus on the User not the Experience

Good project management methodologies tell you to focus on deliverables. Units of work that can be completed, delivered and paid for as the project moves forward. This ranges from libraries to user manuals and is not a bad thing but our pursuit for order often leaves a very important person behind. The person using the software. Every team member needs to take a turn in the user’s desk chair. I cannot tell how many failed projects I have seen that “met the requirements.” This is rarely if ever the fault of the software itself. This happens when teams (customer IT, integrator and vendor) focus on deliverables and matrices and neglect to as the question – if I had to use this every day would I hate it.

Things like agile, scrum and other iterative methodologies are supposed to mitigate this by building in feedback loops. They are nevertheless subject to the same deliverable blindness as others. These methodologies shed features to maintain forward motion and the decision processes that determine what is in and out is too often driven by budget or politics rather than common sense.

Keep things tangible and focus on the user, not the “experience.” These are people with kids, bills and better things to do than match invoices. Realize that those extra clicks may keep you on schedule but a real person pays that price in the end. I understand the use of the word experience as an abstraction but it still makes it too easy to get distracted from the reality of a human being behind the virtual interactions we create.

Learn to Give and Take Bad News

There are very few real surprises in big projects. What there is a lot of is people delivering bad news after it is too late to do anything about it. This problem is rooted in the fact that very few people are ever taught how to deliver bad news in a professional manner. They are trained to avoid it, usually by observing their management. The other side is even more important as even fewer people are ever taught how to receive bad news.

Most project problems do not equal failure but they can add up to it. When you have a partnering situation it is commonplace to blame whichever one of the participants (customer, SI, vendor) is not in the room at the time. If you are truly partners, a failure by one is a failure by everyone. Unfortunately risk management drives us to compartmentalize and create firewalls so that the one’s failure to deliver a feature is their problem alone.

I am not naive and suggesting that accountability is not a component. Accountability is critical but as an ingredient to a successful project I find it is a byproduct of ownership, proper focus and communication. If one makes a mistake, let it be known and work together to correct or mitigate the impact as soon as you know about it.

But how do you take bad news? The first question most people ask is whose fault is it. In an IT project that is probably the last thing you really need to know. The best leaders do one thing first. They listen. Too many leaders were at one time taught not to acknowledge problems. They literally pretend not to have heard what was just said and repeat the positive story they wish were true until the frustrated messenger accepts their warped reality. Childish really but on some dusty shelf in a recently shuttered Barnes and Noble I am sure there is a book titled “Power Listening: The Art of Hearing Only What You Want To Hear.”

Communication must be received to be valuable but it must also be substantive. Too often project communications are not about improving conditions. They are about protecting posteriors and are never even meant to be read. Powerful partnerships are distinguished by open, clear and substantive communication that allows all parties to make decisions about actions rather than making excuses for inaction. This kind of communication itself requires proper portions of diligence, trust and a willing vulnerability. Difficult attributes to foster in today’s business climate but when partners can do it great things happen.

These ingredients do not guarantee success. For example they do not necessarily prevent a project getting started that is based on bad idea in the first place. If the customer, partner and vendor are practicing the principles represented by them though you will be more likely to realize it sooner and take action and evolve the partnership into something that can be successful for everybody.