Think Beyond the Problem

Yesterday in the department meeting, our CIO asked us one question: If you are generating a report showing a customers’ satisfaction score in this month, while this customer has a total of 3 visits which respective scores of 3, 5 and 1, what kind of data will you show?

Some colleagues says we should show an average point by summarising 3, 5 and 1 and dividing the sum by 3.

Some colleagues says we should show the latest score of this customer, which is 1.

What do you think?

The CIO answered in a smile, “No one asked me why we are showing this figure. Let’s think about the objective. If we are going to emphasise a consultant’s KPI on serving customers, it’s better to show an average figure. However, if we are going to emphasise on a customer’s current status, we should show the latest score as it reflects how a customer feels in the current moment. You must be cleared with the objective when you are making decisions.”

Well, I had to admit that I didn’t thought about what the objective was. Our CIO made a very good point.

Sometimes we do things blindly without thinking about why we are doing it and what state we are going to achieve. And that often leads to inefficiency of the work performed.

In our development work, we can also apply this knowledge. For example, at the requirement stage, our project manager explains the requirements to us. Don’t straightaway start to code, but slow down and think what does end users need from your application.

For example, the user needs a listing of job candidates. You can do a simple data grid to list out the paginated candidate records. But think further, what do users want from this candidate listing? The reason may not be included in the requirement, but we may think that they might want to sort and filter from the listing to make their work more convenient. Even more, indicators of summarised information can be presented, such as number of candidates belong to the current logged in recruiter user, and by clicking it, it is automatically filtered without users having to manually type in the filter texts.

Beyond what the CIO mentioned, I think the better way of doing things is to think further. When the problem is presented, don’t just do it first but think first, analyse the problem and make progressive suggestions to make the work better.