Most IT professionals are detail-oriented. This is great when the final product needs to be precise. Unfortunately, too much attention to detail causes mistakes and cost your business money.
When you work in a world of absolutes, physical laws, or zeros or ones, accuracy and detail are important. Buildings are safe because architects pay attention to detail. Aircraft stay in the sky because of attention to detail. Software does what it needs to because of attention to detail.
As an IT professional, your attention to detail can spread into other areas of your work. Unfortunately, a laser-like focus on detail means you might miss the bigger picture. In addition to knowing the detail of what your customer wants, you should also try to understand the reasons behind the work.
You need to understand the intent
If you don’t know the intent behind the work you could deliver the wrong product.
For example, if you hire a painter to paint your fence and you tell them you want it painted blue. It seems pretty straight forward, so the painter goes off and paints the fence. When you see it, you are horrified because they have used the wrong colour. Your plan was to paint fish on the blue fence so your children could pretend they were underwater. But instead of an ocean blue, the fence is sky blue. The shade of blue you had in mind is different from the colour the painter thought you wanted.
You are missing opportunities to create a better end product
By not discussing the intention there is there a risk of the wrong outcome. You’ve also lost the opportunity to have a better end product.
In the fence painting example, by not talking about the intent you are missing out on the value the painter can add. Perhaps they have done something similar in the past, and have suggestions for a better colour to use.
Or they might ask if you want them to paint waves at the top of the fence, and add yellow for sand on the ocean floor, and so on. The discussion that comes from understanding intent helps create a better end product.
This lack of discussion about intent (the bigger picture) often happens when business stakeholders ask technical teams to do work. They ask for something specific and don’t talk about the intent. This means there is a lost opportunity to understand the real need and deliver a better product.
The business stakeholder gets what they asked for and they should be happy. Right?
How often does a business stakeholder get the product they asked for but they aren’t happy?
For example, A business stakeholder wants a new report to pull data from a database. They provide a spreadsheet layout example and they name the source system for the data. The technical team build the report exactly as requested, but the end-user isn’t happy.
Perhaps the data isn’t in a format the user expected and they can’t manipulate it. Or the application they names isn’t the best source of the data they want. Maybe the data is 24 hours behind the production data, or it is already manipulated and isn’t the raw data.
Whatever the reason, it doesn’t deliver the result they expected. The end product either doesn’t perform as well as it could, or it isn’t at all useful for the business. This is a waste fo time and money for everyone involved.
In these situations, the business stakeholders take the report, and they try to use the data. They might spending hours working on the spreadsheet before giving up in frustration. Inevitably they end up complaining that the technical team built another useless report.
It doesn’t matter that the tech team built exactly what the business asked for. The end-user still thinks the failure is the fault of the people who built the wrong thing. That’s human nature.
Why is this an IT issue?
At this point, you might be thinking ‘How is this the fault of the tech team?’ It isn’t your fault, but it is a reason the communication fails. Luckily, the fix is easy.
When business stakeholders give you requirements, make sure you ask them why they need it. What will they use it for? What is the desired outcome? What is the intent?
In the example above, if the tech team had asked about the end use for the data, they might have suggested a different approach. This could have automated the process and saved time for the business team. After all, most manipulation in Excel can be automated. This would have given a much better end product for the user and it only takes a conversation and a few questions.
The key is to not only focus on the detail but make sure you understand the intent of the requests.
