It is important to connect the dots

Recently I had the misfortune of overseeing a project that seemed it would be a big success-- but failed at the last minute. We had two talented developers, we accomplished all of our work just in the nick of time, and the work that was done looked very good.

Seems like a successful project no? The issue was that we didn't get paid for all the work we did. This made it unsuccessful from at least that point.

The root cause of the issue was my failure to "connect the dots". I told the customer we were adding another developer to the project in-order to get the work done in their time lines. I had warned them about that before hand as well. Since this was a Time & Material project this notification seemed sufficient to me. To me it was obvious, the customer disagreed.

When I used to write code, I always preferred to be explicit. That is, not rely on implicit casts or other operations. In this case, the increased cost was merely implicit in this case. Yes, they should have known, but I didn't mention it explicitly.

The lesson to learn out of all of this is that it is important to be explicit, and to connect the dots. This will leave no room for interpretation or mis-communication.

Transparency, it's alpha blending for managers

A few weeks ago, I had the misfortune of having to tell a customer that we were going to deliver milestone 1 a few days late. As I am sure you are aware, it is never easy to tell the client this.

Undoubtedly, the following usually questions come up:

• When will you deliver?
  
• How confident are you on the new date?
  
• What team changes (if any) are you going to make
  
• etc

These questions usually lead to the question of "Why are you late?".

In this case, I had to pause before I answered this, I didn't think the answer was going to be one that they would like.

To provide a little background, this project was small in scope, the team was small, only one local developer and one global developer. Both of these developers were doing a great job. Productivity was greater then 100% and we were coming in under the estimates.

So how could we be late if we were doing better then the estimates?

Well, we were late as one of the developers ended up spending a significant amount of time at the start of the milestone finishing up some last minute tasks that popped up on his previous project, and hence didn't spend all of his time he was supposed to.

The decision was a simple one, fall back on our corporate (and personal) values and be transparent.

I told the customer that the developer had to spend some time on his previous project as a few last minute bugs came up. I told the customer that based on the metrics, we would be able to make up the time in the next milestones, and I also told him that we would do the same if required at the end of his project as we stand behind our work.

The client accepted all this without batting an eyelid, and thanked me for my honesty. It seems that honesty is the best policy.