When you’re building your business case, you can’t build your team, brainstorm solutions or crunch numbers unless your business need is crystal clear.
Think of it as a pain point. Whatever pain your organisation has, that’s the source of the need, and your task is to figure out how to alleviate the suffering.
You may identify the pain point yourself—maybe your accounts payable process takes too long, aggravates both accounting clerks and department managers and is making your organisation lose out on early-payment discounts. But maybe your boss calls you into his office and says, “Fix this.” Whether it’s a problem you identify or one that is handed to you, you have to research the business need so you can build your business case.
It’s important to realise that some projects are driven by opportunities, not problems. For example, you might save 40% in operating costs if you change to a new software licensing model, or benefit from a promotion if you decide to purchase quickly. Regardless of whether your project is driven by a problem or an opportunity, there are four specific steps you’ll take to identify the business need.
Step 1: Ask
Your job is to ask the people involved in the process what they think is going on, and listen to their answers. Ask open-ended questions—they may not know the underlying reason for the problem, but you can help discover the cause and identify a solution.
At this point, you can also gather relevant data. For example, find out how much money departments are spending on copying, storage, distribution, and other costs of document handling. This will help you later as you build your ROI.
Step 2: Analyse
You can’t just take people’s word for what’s wrong. Diagram the process to figure out where bottlenecks are, what steps can be automated or eliminated and what pain points exist.
Remember to be objective—you may think the problem lies with slow A/P clerks, but it may turn out that invoices are sitting on managers’ desks waiting for approval. You won’t discover the true pain points unless you approach the problem with an open mind.
Step 3: Agree
Go back to your stakeholders and make sure your assumptions match theirs. Should you be concerned about compatibility with other IT systems, like your accounting system? If there is already a related initiative, like implementing a new ERP system, does that mean there is a particular time when the rollout will have to take place?
Use the following questions to guide your discussion:
What departments or offices will use the solution?
How quickly does the solution need to be in place?
Will we roll it out over time (phased or pilot implementation) or to all departments at once?
How should we measure the solution’s effectiveness?
Should we combine the solution with a related initiative?
Step 4: Archive
Record everything you learn—where the pain comes from, who’s experiencing it and what the solution needs to accomplish. This will save you a lot of time later as you prepare your presentation to stakeholders, because you’ll know what you’re basing your recommendations on and who to go back to if you need additional information.
Once you make it past the pain points, it’s time to start building your case for document management.