Show them the numbers – it’s results that matter

On a recent project one of our customers had some questions about the project’s progress. The project was a mid-size systems integration between Oracle Financials and Onyx CRM for a Fortune 500 company.

As with many large companies, there were several business units and people with interest in the project, and also as with many large companies, people had several other projects to deal with and were not attending the daily standups or weekly progress meetings.

I began to hear that there were some concerns about the project progress from some of the management team and a concern that we were spending too much time writing tests instead of code.

This came as a big surprise to me: from the perspective of the team working on the project on a daily basis (both customer and ext.IT), we were sailing along with no problems. We were providing the usual artifacts such as status reports which showed how we were tracking against estimated hours and when our code complete date would be, and all of this was tracking well against our original estimates, so to hear that people were unhappy was a big shock.

I called a meeting with all of the stakeholders and as soon as I invited all of the stakeholders I realized two things:

1. This meeting would be the first time in the whole project that all of the stakeholders had been in a room together.
2. While we had discussed our approach during the initial engagement, we hadn’t held a project kickoff with all of the stakeholders to discuss our approach to building software.

Both of these items were my fault, but here I was, several months into the project with an unhappy customer, so I thought I would address it in this meeting.

I put together a short presentation which discussed our approach to building software, including brief descriptions of how we perform iterations, test driven development, automated acceptance testing, retrospectives and other benefits to the way we build software, and why we considered our approach to be best practice.

Almost as an afterthought, I ended the presentation with a couple of slides showing our project status. This was an afterthought because everyone at the meeting was a recipient of the weekly status report containing the same information. I created one slide comparing our original project estimates (before we had detailed requirements) to our detailed estimates (once requirements were fleshed out) and to our actual hours so far on the completed features, and another slide showing our defect count and comparing it to another of the customer’s internal projects that they had build without the benefit of automated tests.

Once the meeting started, it was clear that I didn’t need any of the slides about our approach. We spent a few minutes discussing the original estimates against the actual time taken for completed features: everyone was happy with the job we had done in estimating against the original high-level requirements. We also discussed how we were tracking on the hours left: again, everyone was satisfied with the results. Finally, we spent five minutes comparing the low defect count on our project (with a high level of test automation), compared to some of the customer’s other projects (without unit tests), and everyone was satisfied with this too.

There wasn’t a single question about our approach, and ultimately no-one in the higher echelons of the customer’s business cared about the minutiae of our approach, nor were they interested in why we thought our approach was best practice.

They simply wanted to see the results of our approach.

In retrospect, this might seem obvious, but the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

To conclude: After this meeting, the project was delivered successfully without any more concerns from the customer. We were one of several projects integrating with Oracle and we were the only project to deliver on time and under budget, with a very happy customer!