Build Upon Rock: Understand the Business Need
Because software developers are in the business of delivering solutions our thinking and discussions with business owners tend to be solution-oriented. It’s not uncommon to hear things like this from business owners:
It’s also not uncommon for developers to listen to business owners talk about their issues and jump to well-known solutions and say things like:
Thinking about solutions is not a bad thing but it can lead to mistakes if the business problem is not framed properly. You can tell that you’ve framed a business problem properly when its description has nothing to do with a system, per se. Take the case of adding a column to the F105 report. Rather than respond – “ok – we’ll get right on that,” start by getting to the underlying business need:
Developer: “What's changed? What is motivating the need to add the total processing time to the report?”
Business Owner: “We’ve changed our processes so that we’re reporting on this to our customers. Upper management is also really hot on it – we had some very slow fulfillment times last month.”
Developer: “Oh. Ok. It’s easy to add it to the report but that’s just a lagging indicator. Do you think you might need tools that alert you to orders that haven’t been fulfilled in a certain amount of time? Then you’d have a chance to head the issues off before they reach a certain point of criticality. So rather than just a passive indicator we could give you a proactive tool for managing exceptions.”
Business Owner: “Yeah. That’s even better.”
If you understand the underlying business need you will be able to offer alternative solutions and improve upon solutions that may have already been suggested. You’ll be that much more valuable and seen as an architect of solutions, not just someone who implements things blindly without understanding implications. Moreover, understanding the underlying business needs will teach you more and more about the business that you are supporting which will make you far more effective in your work. You’ll be able to make logical deductions based on business understanding that would otherwise not be obvious. And you’ll become the go-to person when your business owners are facing a tough problem – business owners love people that can speak their language and that can help bridge the gap between what they think they need and what they really need.
Related to understanding business needs, it is imperative to ensure that one has framed a problem properly before beginning to work on it. An inaccurate framing of a problem can lead to serious mistakes not the least of which is that one may be focusing on solving the wrong problem. As human beings, our brains are conditioned through millions of years of evolution to see patterns in order for us to process information quickly – we are wired to put things into categories and react accordingly as this has been necessary for the survival of the species. For example, if one perceives a threat (e.g. a hissing cobra) the amygdala takes over and ensures that we react immediately via a fight or flight response. The amygdala is an ancient part of the brain which is not used to solve a difficult math problem – a different portion of the brain (the frontal lobe) is used to solve that problem. Our biology itself is pre-conditioned for pattern-recognition.
As seers of patterns, it is easy to leap to conclusions in either the definition of the problem or worse, its solution. We sometimes make things fit within a box. Sometimes we may even reverse-engineer a problem to fit a pre-conceived solution! Think about it. “I’ve got a meeting with the head of the Customer Service team. Sounds like he needs a CRM.” Then you go to the meeting and due to the human tendency toward confirmation bias all you hear are the issues that a CRM could help solve. “See – told you he needed a CRM.” But you walk away not hearing the fact that this person is dealing with other issues that you might have been able to help with. And after all, have we even framed the problem? What is the problem? CRM-Deficit-Disorder?
Imagine the following scenario. A business owner comes running into your office. “I can’t run the F105 report! I enter the search criteria and then the application just crashes. I need to get these numbers to our customer within an hour. Help!” Being a diligent production support team member you make sure you can replicate the issue. Good – you can. You start seeing if you can fix the crash. You queue up the testing and deployment staff – “hey – we’ve got a hot bug fix coming – be ready”. 45 minutes goes by and you’re still having trouble figuring out why it’s crashing. The business comes in very concerned. “Well?” “I’m working on it” you say. 15 minutes go by and then 30 minutes and then a few hours. By the time you get the issue fixed it’s 7:00 PM. Your business owner says – “Since we didn’t get it out by 4 PM the customer’s going to be pretty angry. But thanks for getting it done as quickly as you could. I know you tried.” You say to yourself – “I did the best I could but I only had a few hours' notice. Oh well.” You go home feeling pretty good about yourself. You kiss the kids goodnight and hold your head up high.
But did you do a good job? What was the problem? You might think – “Duh! Clearly the problem was that there was a bug in the F105 report that was preventing it from being run”. Wrong! The immediate problem was that the business owner was not able to submit required information to the customer by 4:00 thus causing the company to fail in the customer’s eyes. Framed that way, one obvious solution would have been to run the query behind the report (manually) and give the business owner the results. But business owners are not always aware of options available to them – we have to help flesh them out – most have no idea how a system is put together. Framing a problem properly can lead to a broader solution space and can lead one to the best solution faster. Framing a problem incorrectly can, in some cases, lead to disaster.
Understand the business need, frame the problem properly and your solutions will be built upon rock.
- “I really need a new column added to the F105 report – the total processing time.”
- “I need a new screen that tracks inventory.”
It’s also not uncommon for developers to listen to business owners talk about their issues and jump to well-known solutions and say things like:
- “What you need is a CRM system.”
- “The F109 screen will take of everything you need. I’ll show you how to use it.”
Thinking about solutions is not a bad thing but it can lead to mistakes if the business problem is not framed properly. You can tell that you’ve framed a business problem properly when its description has nothing to do with a system, per se. Take the case of adding a column to the F105 report. Rather than respond – “ok – we’ll get right on that,” start by getting to the underlying business need:
Developer: “What's changed? What is motivating the need to add the total processing time to the report?”
Business Owner: “We’ve changed our processes so that we’re reporting on this to our customers. Upper management is also really hot on it – we had some very slow fulfillment times last month.”
Developer: “Oh. Ok. It’s easy to add it to the report but that’s just a lagging indicator. Do you think you might need tools that alert you to orders that haven’t been fulfilled in a certain amount of time? Then you’d have a chance to head the issues off before they reach a certain point of criticality. So rather than just a passive indicator we could give you a proactive tool for managing exceptions.”
Business Owner: “Yeah. That’s even better.”
If you understand the underlying business need you will be able to offer alternative solutions and improve upon solutions that may have already been suggested. You’ll be that much more valuable and seen as an architect of solutions, not just someone who implements things blindly without understanding implications. Moreover, understanding the underlying business needs will teach you more and more about the business that you are supporting which will make you far more effective in your work. You’ll be able to make logical deductions based on business understanding that would otherwise not be obvious. And you’ll become the go-to person when your business owners are facing a tough problem – business owners love people that can speak their language and that can help bridge the gap between what they think they need and what they really need.
Related to understanding business needs, it is imperative to ensure that one has framed a problem properly before beginning to work on it. An inaccurate framing of a problem can lead to serious mistakes not the least of which is that one may be focusing on solving the wrong problem. As human beings, our brains are conditioned through millions of years of evolution to see patterns in order for us to process information quickly – we are wired to put things into categories and react accordingly as this has been necessary for the survival of the species. For example, if one perceives a threat (e.g. a hissing cobra) the amygdala takes over and ensures that we react immediately via a fight or flight response. The amygdala is an ancient part of the brain which is not used to solve a difficult math problem – a different portion of the brain (the frontal lobe) is used to solve that problem. Our biology itself is pre-conditioned for pattern-recognition.
As seers of patterns, it is easy to leap to conclusions in either the definition of the problem or worse, its solution. We sometimes make things fit within a box. Sometimes we may even reverse-engineer a problem to fit a pre-conceived solution! Think about it. “I’ve got a meeting with the head of the Customer Service team. Sounds like he needs a CRM.” Then you go to the meeting and due to the human tendency toward confirmation bias all you hear are the issues that a CRM could help solve. “See – told you he needed a CRM.” But you walk away not hearing the fact that this person is dealing with other issues that you might have been able to help with. And after all, have we even framed the problem? What is the problem? CRM-Deficit-Disorder?
Imagine the following scenario. A business owner comes running into your office. “I can’t run the F105 report! I enter the search criteria and then the application just crashes. I need to get these numbers to our customer within an hour. Help!” Being a diligent production support team member you make sure you can replicate the issue. Good – you can. You start seeing if you can fix the crash. You queue up the testing and deployment staff – “hey – we’ve got a hot bug fix coming – be ready”. 45 minutes goes by and you’re still having trouble figuring out why it’s crashing. The business comes in very concerned. “Well?” “I’m working on it” you say. 15 minutes go by and then 30 minutes and then a few hours. By the time you get the issue fixed it’s 7:00 PM. Your business owner says – “Since we didn’t get it out by 4 PM the customer’s going to be pretty angry. But thanks for getting it done as quickly as you could. I know you tried.” You say to yourself – “I did the best I could but I only had a few hours' notice. Oh well.” You go home feeling pretty good about yourself. You kiss the kids goodnight and hold your head up high.
But did you do a good job? What was the problem? You might think – “Duh! Clearly the problem was that there was a bug in the F105 report that was preventing it from being run”. Wrong! The immediate problem was that the business owner was not able to submit required information to the customer by 4:00 thus causing the company to fail in the customer’s eyes. Framed that way, one obvious solution would have been to run the query behind the report (manually) and give the business owner the results. But business owners are not always aware of options available to them – we have to help flesh them out – most have no idea how a system is put together. Framing a problem properly can lead to a broader solution space and can lead one to the best solution faster. Framing a problem incorrectly can, in some cases, lead to disaster.
Understand the business need, frame the problem properly and your solutions will be built upon rock.
Very good points. For a long time now I've suspected that analysis skills have been on the wane within the agile community, very likely caused by far too much focus on user stories. User stories are great, but only one part of the overall modelling picture.
ReplyDeleteI agree. My experience is that the hardest part of software development is often analysis and requirements-gathering. And it's the area that often gets the least attention. It's the hardest piece to teach as well because it's part art, part science - bits of tribal wisdom often work best. This Dilbert cartoon hits the mark. :-) http://images.cryhavok.org/d/1401-1/Dilbert+-+Software+Requirements.jpg
DeleteNice post Joe!
ReplyDeleteI have seen too many project teams in my career do a sloppy rush job on the problem framing.
No less of a genius than Albert Einstein said:
"If I had an hour to solve a problem and my life depended on the answer, I would spend the first 55 minutes figuring out the proper questions to ask. For if I knew the proper questions, I could solve the problem in less than 5 minutes."
and I love John Tukey's observation:
"Far better an approximate answer to the right question, which is often vague, than an exact answer to the wrong question, which can always be made precise."
IMHO, many of the most startling innovations in business have started with a single person looking at a situation countless others have looked at before and framing the problem in a unique way, which leads to a breakthrough solution.
This reminds me of How To Ask Questions the Smart Way
ReplyDeletehttp://catb.org/~esr/faqs/smart-questions.html
The similarity is "ask about what you want to do, not about an implementation of what you want to do."
For questioners on the internet, the onus is on them to ask a proper question. For software professionals, the onus is on us to help the client get to their need.