Although I have a master’s degree in technical communication, I’m notorious for ditching instruction manuals. I’ll always try to complete a task (assemble furniture, set up a new computer, etc.) with complete disregard for the “proper method.” Call me foolish, but I like to figure things out on my own.
Recently, I assembled a set of shelves with my usual “wing it” approach. I finished the task in what was surely record time! Beaming with pride, I turned the shelves upright, only to realize that one whole side was upside down. (Insert your favorite curse word here.) I had to take the shelves apart and start over, costing me time and sanity. If only I had read the instructions…
As it turns out, doing things properly is almost always a good choice. Though reading instructions or planning ahead may slow you down in the beginning, you’re more likely to end up with a quality outcome. This is true when assembling furniture and when implementing new software—particularly if that software offers a great deal of flexibility. Taking a few days to plan your approach (rather than diving right in) can dramatically improve your chances of success.
I recently co-authored an E-Book on this topic with GRC consultant Dan Plato. Dan presented on “Smart, Rapid Solution Design” at Onspring Connect (our annual user conference) and shared some great tips for defining business requirements before implementing new technology.
A few key points:
Design the Big Picture
When implementing new software, you need to define how the solution should address specific needs or challenges. For example:
Your business requirements are an itemized list of solution behaviors or capabilities. These requirements, coupled with process flows, enable you to get all stakeholders on the same page about the expected outcomes of the project.
While it’s best to define your business requirements before selecting your technology, this may not always be an option. In these situations, keep moving forward. Regardless of the tool you’re using, it’s important to capture your requirements before you dive in and start configuring. Your business requirements will be a useful guide that you’ll reference throughout the design process, particularly when it comes to testing.
Review and Respond
Depending on the complexity of your software implementation, you may need multiple design sessions to capture all necessary requirements. At the conclusion of each session, send the deliverables to all participants as quickly as possible. If you can send them out within 48 hours, that’s ideal.
Why the hurry?If you wait a week or two to initiate the review process, or if you wait until all design sessions are complete, you’ll hear a lot of, “I don’t remember that” or “When did we decide this?” By contrast, if you send the deliverables quickly, the conversations will be fresh in your participants’ minds. A rapid turnaround helps to maintain alignment and momentum.
You should also require a quick turnaround on the review process. Give participants 3 business days (max) to respond with comments or questions. Again, this helps to keep the design process moving forward.
Work Out the Details
Once you reach agreement on business requirements and process flows within your design team (and from higher management, if necessary), it’s time to go a level deeper and define your configuration requirements. This is where you connect your business requirements directly to the capabilities of your chosen technology. In this phase, you need to define:
Data capture requirements (field name, description, type, values, required/optional, etc.)
Reporting requirements (data to include, text or chart presentation, filters, etc.)
Security requirements (user types, data to view, data to edit, etc.)
You’ll find many more details in the E-Book: Smart, Rapid Solution Design. As an added bonus, you’ll have access to templates and samples for business requirements, process flows, configuration requirements and design session notes. I hope you find this content useful the next time you’re considering new software to solve a business problem. Remember: A little bit of planning goes a long way!