In The Land of Development, Process Is King

Today at work I played a truly Machiavellian game in order to get some forward movement on a portion of the project.  We have one portion of the project where three different teams are working on an integration - the Evil Corporation and two vendors.  This is a part of the project that ran into schedule delays due to poor planning and feeling were high and hostile by the time I got involved.

In order to make the integration work, it was necessary to get down into the nitty-gritty details and line out each individual data element - however, because of the delay and the fact that all three sides were pointing fingers at each other I could not get them to do the detail work.  Each group was playing highly defensively, waiting for the other groups to make a move, so they could dodge any blame.

After several fruitless meetings last week where we struggled to get even the most basic questions answered I spent the weekend reading a massive chain of email trying to figure out how to break through through the logjam. The answer was in the changing tone of the emails.  As they progressed through time I could see the tone changing to more accusatory, more defensive, less productive,  until the reached the point where I had been brought in, which was the point of near total meltdown.  Everyone was waiting for someone else to go first, so that if something went wrong they could point a finger at someone else.

So, I over-reached my authority and went first - I wrote up a set of requirements and announced - this is what we are going to do, this is the condition the data is going to be in, this is the place we are going to send the data. You all need to be ready to pick it up when it gets there.  Then, I spelled out, in some detail, what I was planning to do. 

Of course, it was wrong, largely because I was making it up out of whole cloth - but one of the vendor rose to the bait and said "that's not right", which opened up the door for me to simply say "tell me exactly where it is wrong, and what change needs to be made to make it right".  They tried to dance, but I just drew back to my original proposal and said "absent detailed input, I am making a best guess and doing it this way, and I have no problem documenting it as a best guess in the lieu of more detailed information" - and that was enough to prompt, first, the two vendors to talk to each other, then the whole team to get talking.  When I left tonight, I have two thirds buy in and one third outstanding.

It was pretty Machiavellian, but it was the only thing I could think of to break through the positions that everyone had hunkered down in. Sometimes a stalking horse serves a good as well as a real horse.  Of course, none of this would have been necessary if we'd actually followed any sort of good engineering process from the beginning.  What appears to have bitten them on this end of the project was that no one wanted to do the grunt work - and everyone preferred to assume that someone else was doing it, so there were no detailed documented system requirements.

When it comes to software development, process is king.

Trust

Trust.

It is a pretty astounding thing. That we function at all in society is a result of a vast interlocking system of trust. We approach a green light at the intersection and we trust the people approaching the red-light are going to stop since it is "our turn". There are a million other daily examples.

I was reading up on negotiating techniques today (I negotiate a lot in my work, finding ways to move through the conflicting interests that are common in any large complex organization) when I came across an article by Seth Freeman, a teacher of negotiation and conflict management at New York and Columbia universities.

The article was primarily about the current credit crisis, but it laid out six steps toward building trust very concisely and I thought I would take a few minutes and share them with you all here, just in case you ever need them. The high level framework of establishing (and re-establishing) trust is universal.

1.) Who can serve as a credible bridge of trust? If two parties do not trust each other, is there a third party that both parties trust that is willing to serve as a bridge of trust? Picking a successful mediator to establish that bridge of trust is often tricky. This most effective mediator is someone who a.) has a general interest in resolving the issue but b.) does not have a vested interest in a specific outcome.

2.) How can we most effectively watch or test the two parties ability to perform? In any issue of trust it is important to remember something. Both parties think they are in the right. Both parties have a legimate reason to not trust the other. Any effective monitoring solution must monitor both parties - to the satisfaction of each party.

3.) What incentives and penalties can best encourage performance? The parties will want to construct a system that rewards trustworthy behavior and penalizes untrustworthy behavior. Be as explicit as possible with the events or milestones that will trigger both behavioral modification alternatives.

4.) Build in mild, moderate, and strong trust supports within the incentive/penalty process. A range of behaviors allows the parties involved to begin the intervention process early and mildly if it starts to go astray - and at the same time allows both parties to have options, enabling them to feel in control of the process, and reducing the coercive feel of it.

5.) Does the solution satisfy all parties key interests? It is important that the solution be both simple (easy to comply with, easy to monitor, easy to enforce) and comprehensive (covering all of the key points at dispute). The vast majority of negotiations break down because one or both parties have one or more key interests that are not satisfactorily addressed in the solution. It is often very tempting in any negotiation to set aside the really sticky break points and address them later. This is almost always a mistake. Be sure and include them in your roadmap to establishing trust.

6.) What if the worst case scenario happens? It is always best to think of that worst case scenario before it happens. When they happen, our emotions, our ego, our pride, our feelings, all get tangled up inside of them. Take the time in the process to determine what the worst case scenario is and discuss how it will be addressed when it occurs (not if - when). If you prepare for the worst case scenario you will find that everything short of it is much easier to handle.

(Seth Freeman is currently writing a book called "Promises: Making Commitments More Reliable in Business and Beyond".)