Despite the ubiquitous awareness of the software development life cycle in the world of business technology, I’ve been continuously surprised at how rarely technology and business leaders take the time to write down business requirements that are agnostic of any particular software when considering a new software purchase.
1. Get over documentation being unsexy
It makes sense though. Documentation is very unsexy. With such a proliferation of software-as-a-service platforms and 3rd party plugins, and limited time set aside for careful decision-making, many IT leaders succumb to the temptation to start by looking at a specific software solution, then work their way backward to justify how it could be used.
2. Realize the grass is not necessarily greener
This is like seeing a car commercial and immediately imagining how sweet life would be, if only you drove that car. Never mind pausing to consider whether you need a sports car or a minivan; or whether it’s more responsible to just take care of the overdue maintenance on your existing car; or (if you’re not in LA like me) whether you could just use public transportation.
3. Know what you’re solving for
In spite of my education in software engineering, early in my career, I rolled my eyes at the idea of writing down what’s needed and how I planned to build it. What a waste of time, when I could just start writing code or configuring an application! I learned the hard way that it’s difficult, if not impossible, to know you’ve designed or selected the right solution if you never take the time to write down the problem. Without writing down your requirements, you have no way of knowing what assumptions are in every stakeholder’s head, or the distinction between need-to-have and nice-to-have.
4. Start with your need, not with their feature
I was once tasked with completing the implementation of an IT Asset Management tool that had already been selected and purchased. There were no documented business processes or roles and responsibilities, and I received blank stares when I asked “who’s responsible for keeping the data accurate?” The tool supported barcode scanning to receive new assets, but our vendors didn’t put barcodes on their packing slips. The tool could import shipping confirmations from vendors to identify which items were inbound, but there was no internal product catalog with consistently used SKU’s or other unique identifier. Our custom in-house tools could call the API to help map hardware assets to business services, but the internal developers already had more pressing priorities. In other words, significant changes were required to internal and external processes as well as resource allocation for these features to be of any use. And were these really the most urgent needs of the business? If someone were actually held accountable for tracking IT assets, couldn’t they just maintain a spreadsheet, or use the existing IT Service Management software?
5. Don’t be a sheep
To top it off, why was this software selected? Because someone found out a competitor was using it.
In conclusion: first write down what you need
Next time you see an unmet need and a tool that seems to address it, I challenge you to write down exactly what the business needs, without mention of a new tool. It doesn’t matter what form this takes, whether it’s a formal list of agile stories (as a {specific type of user} I need to {perform a specific action} so that {I get a specific outcome}) or a higher level a bullet list of pain points to resolve and new capabilities that are needed. This should be your criteria for evaluating all your existing and potential options. Before getting emotionally committed to a new tool, convince yourself that it’s impossible for these needs to be met by any combination of existing tools. This simple step can save hundreds of man hours and tens of thousands of dollars in software licenses and fees. You will thank yourself for the sanity and clarity that result from separating requirements from solution design.