"For a list of all the ways technology has failed to improve the quality of life, please press three." - Alice Kahn
I love technology. I especially love database-driven, web-enabled technologies with great interfaces that make important things easier to do. Seriously, I really do.
But, I have become aware recently (or should I say "reminded") of ways in which technology can fail to deliver on its promise.
1. Stop-Drop-and-Roll When Technology Makes Something Simple More Complex
Forget scale. Forget extendability. Sometimes business needs are simple. You need to answer the phone and route calls, for instance. How hard can it be really? Incredibly difficult once you create phone trees, voice prompts, scripts, and queues. Add to that a hold music music track from Hades (a stress-inducing piece of classical music that is reminiscent of a battle scene from an epic film) and you have a comic combination of making something simple hard. Part of the problem is trying to fit all possible needs into one solution, when in fact a customer-driven approach would call for multiple, smaller solutions.
For example, some websites are packed with information for everyone which makes them hard to navigate, contain too much copy, and lose their purpose (for example see anything that the good folks at Microsoft post), so all technologies are prone to this kind of complexity. In contrast, stands very simple web page design where the text is a clear call to action, the copy is natural speech, and all of the content fits "above the fold" without making the user scroll to read.
Using the web page example and applying it to my telephony problem, I wonder if the solution is this. Replace the complicated phone tree with its 50 options (and the hold music that enrages already irritated callers) with a pleasant woman's voice who says "Thanks for calling us. We love to hear from you and want to make sure you talk to the right person who can help you the best. To skip to sales, press 1. To go straight to technical support, press 2. Or just hold and a real live, honest-to-goodness human being can assist you. On our website you will also find a directory of contacts that might help you connect even more quickly. Again, thanks for your business. Please wait a moment while we connect you."
If technology makes something more complex, you should stop it, drop it, and roll with something new. For instance, if your customer base is known and finite and if you have more than 2 options on any phone line, break it up and pass out new numbers. It could be that your business is too complicated for the technology to solve. This leads to my second principle.
2. Don't Pave a Cow Path (or Pave Only Cow Paths that Lead Somewhere)
A colleague of mine once told me a story about how a farmer sold his property to a developer and they decided to build houses along gravel roads laid down where the well-worn paths through the pasture land that the cows had cut over years of grazing. Years later, they paved those gravel roads and although the residents complained, only the old-timers remembered the someone hadn't sat down to design the best layout for the neighborhood, but had instead paved the cow paths.
How often do we do this? Come up with a great technology solution to a problem we don't understand fully, just because the technology solution is in hand or can be envisioned. I am guilty of this more than I like to admit (being generally optimistic about technology and life and having this natural impatience to get on with something already). We start building solutions for things that only work the way they do by accident. Or, we throw out a perfectly good "cow path" solution in favor of a more complicated one.
One of the most successful development projects I was involved with was an internal corporate application. Before writing a single line of code, I lived the workflow of the application (however painful it was) for several months managing an Excel spreadsheet. During this "alpha" phase, I worked out all the communication flows and templates, the policies of who needed to be copied on what, and started to quantify the benefits of automation. The core workflow changed quite a bit in those early days and got refined in this manual process, and I was able to articulate requirements for a little application that is still very useful and powerful (and has gone through numerous iterations as new needs and ideas were explored).
This reminds me that one must make careful choices about what gets paved and why. Living in a tent on a cow path for a while, while taking land surveys might be a perfectly reasonable way to "write" requirements.
3. Nothing Replaces an Outside-In View
Companies love to create Inside-Out solutions. You need to know how many product returns you get and why products fail, so you adopt a nifty little service application to manage the transactions. It works great. Unless, a customer wants to see all their transactions and the status of each. Maybe that gets a little tougher. Or unless a sales person wants to see all their transactions and the status of each, across multiple customer accounts, geographies, product lines, or departments. Then the transaction system doesn't quite serve the purpose. Before you rush out an implement a fully-integrated CRM package (which can be wonderful by the way), remember the problem you are solving and the points above. It could be that the outside-in perspective would tell you to keep the transaction system and implement a report instead. It could be that a fancy, automated report isn't needed, but rather a regularly scheduled phone conference with a key customer to walk them through any open issues and assure them of your attentiveness to their issues. It could be that you have back office communication or coordination challenges, that once solved through better roles and responsibilities, the issues are minimized and more manageable.
It is good to keep in mind that most customers don't really care about the efficiencies of your business overall, how the same phone tree helps them and their competitors, or what you are doing to solve problems for everyone. They really want their problems solved. And, it is always easier to solve one issue than ten.
Technology can be a part of that. It can help coordinate information, make dispersed and diverse team act together, and can provide feedback loops in real-time. It can be game changing or tactical, but it is only a part of the whole solution.
I love technology. I especially love database-driven, web-enabled technologies with great interfaces that make important things easier to do. Seriously, I really do.
But, I have become aware recently (or should I say "reminded") of ways in which technology can fail to deliver on its promise.
1. Stop-Drop-and-Roll When Technology Makes Something Simple More Complex
Forget scale. Forget extendability. Sometimes business needs are simple. You need to answer the phone and route calls, for instance. How hard can it be really? Incredibly difficult once you create phone trees, voice prompts, scripts, and queues. Add to that a hold music music track from Hades (a stress-inducing piece of classical music that is reminiscent of a battle scene from an epic film) and you have a comic combination of making something simple hard. Part of the problem is trying to fit all possible needs into one solution, when in fact a customer-driven approach would call for multiple, smaller solutions.
For example, some websites are packed with information for everyone which makes them hard to navigate, contain too much copy, and lose their purpose (for example see anything that the good folks at Microsoft post), so all technologies are prone to this kind of complexity. In contrast, stands very simple web page design where the text is a clear call to action, the copy is natural speech, and all of the content fits "above the fold" without making the user scroll to read.
Using the web page example and applying it to my telephony problem, I wonder if the solution is this. Replace the complicated phone tree with its 50 options (and the hold music that enrages already irritated callers) with a pleasant woman's voice who says "Thanks for calling us. We love to hear from you and want to make sure you talk to the right person who can help you the best. To skip to sales, press 1. To go straight to technical support, press 2. Or just hold and a real live, honest-to-goodness human being can assist you. On our website you will also find a directory of contacts that might help you connect even more quickly. Again, thanks for your business. Please wait a moment while we connect you."
If technology makes something more complex, you should stop it, drop it, and roll with something new. For instance, if your customer base is known and finite and if you have more than 2 options on any phone line, break it up and pass out new numbers. It could be that your business is too complicated for the technology to solve. This leads to my second principle.
2. Don't Pave a Cow Path (or Pave Only Cow Paths that Lead Somewhere)
A colleague of mine once told me a story about how a farmer sold his property to a developer and they decided to build houses along gravel roads laid down where the well-worn paths through the pasture land that the cows had cut over years of grazing. Years later, they paved those gravel roads and although the residents complained, only the old-timers remembered the someone hadn't sat down to design the best layout for the neighborhood, but had instead paved the cow paths.
How often do we do this? Come up with a great technology solution to a problem we don't understand fully, just because the technology solution is in hand or can be envisioned. I am guilty of this more than I like to admit (being generally optimistic about technology and life and having this natural impatience to get on with something already). We start building solutions for things that only work the way they do by accident. Or, we throw out a perfectly good "cow path" solution in favor of a more complicated one.
One of the most successful development projects I was involved with was an internal corporate application. Before writing a single line of code, I lived the workflow of the application (however painful it was) for several months managing an Excel spreadsheet. During this "alpha" phase, I worked out all the communication flows and templates, the policies of who needed to be copied on what, and started to quantify the benefits of automation. The core workflow changed quite a bit in those early days and got refined in this manual process, and I was able to articulate requirements for a little application that is still very useful and powerful (and has gone through numerous iterations as new needs and ideas were explored).
This reminds me that one must make careful choices about what gets paved and why. Living in a tent on a cow path for a while, while taking land surveys might be a perfectly reasonable way to "write" requirements.
3. Nothing Replaces an Outside-In View
Companies love to create Inside-Out solutions. You need to know how many product returns you get and why products fail, so you adopt a nifty little service application to manage the transactions. It works great. Unless, a customer wants to see all their transactions and the status of each. Maybe that gets a little tougher. Or unless a sales person wants to see all their transactions and the status of each, across multiple customer accounts, geographies, product lines, or departments. Then the transaction system doesn't quite serve the purpose. Before you rush out an implement a fully-integrated CRM package (which can be wonderful by the way), remember the problem you are solving and the points above. It could be that the outside-in perspective would tell you to keep the transaction system and implement a report instead. It could be that a fancy, automated report isn't needed, but rather a regularly scheduled phone conference with a key customer to walk them through any open issues and assure them of your attentiveness to their issues. It could be that you have back office communication or coordination challenges, that once solved through better roles and responsibilities, the issues are minimized and more manageable.
It is good to keep in mind that most customers don't really care about the efficiencies of your business overall, how the same phone tree helps them and their competitors, or what you are doing to solve problems for everyone. They really want their problems solved. And, it is always easier to solve one issue than ten.
Technology can be a part of that. It can help coordinate information, make dispersed and diverse team act together, and can provide feedback loops in real-time. It can be game changing or tactical, but it is only a part of the whole solution.
Posts
Ah, totally top-of-mind today. Lots of "web strategy" meetings of late. Gotta remember to connect it to ROI and the people using the web sites. Good post.
This topic is hot again for me today - from a totally different angle. I'm trying to get a handle on photo and video asset workflows. There's many, many variables and people are resistant to changes. It's hard to get people to see the bigger picture (i.e. adding their value to the larger group).
I like thinking through the whole workflow/process/user scenario on a whiteboard, with a group giving input. Then, go find the tools/code that fits that workflow. Many apps/foundations want you to do things their way.
You are so right! Software, especially, is such a reflection of the personality and workstyles of the architects, developers, and designers, it is hard to try to do thing different with that tool (to a hammer everything has to be a nail). The white board exercise you described is the right way to go, as long as the team retains a little flexibility (often getting creative or visionary with what the "to be" state could be).
This is why the large enterprise software packages (SAP, Oracle, etc) have sparked a whole industry of consultants who can customize the tools to the business workflow of the customers. I have participated in this ERP consultant work and they start by documenting the current workflow (what tools are used, by whom, what works, what doesn't), then they white board a "to be" state, with those two in hand they can identify gaps, recommend a tool, etc. Sounds like this is what you are doing.
That said, I have come to believe that every business or organization thinks they are more unique than they are. Unless you are really breaking new ground and inventing something (which might very well be the case in your situation), most problems have been solved before by other groups with similar needs. Tweaking something that already exists is often more possible than people realize at the beginning. If you need something that no one else has done before, you might be onto a new market and others might be interested in licensing your final solution for their needs!