Another critical step after discovery and diagnosis to ensure digital integration projects are successful is to correctly define where to go. This can be defined as a future state and contains all the goodness found in the discovery phase. This future state needs to be documented as a set of requirements which when signed off also becomes the scope of the project. At this stage however, it is recommended to only define the preliminary set of requirements.

User Stories

When defining requirements for a software integration, it is useful to consider using Agile Scrum User Stories. This method can then be integrated with the Agile implementation plan, which will significantly facilitate integration. Additionally, user stories can help understand how the business operates and potentially provide insight into what can be further improved. A simple user story for a construction service company would be: “As a dispatcher, I want to send a notification to the worker, So that the worker knows where to go and what to do, And I know I am done when the worker confirms he is on the way.”

Define by Business Function

To ensure that there is clarity in what is needed for a business’ future state, it is strongly recommended to define requirements by business function. This will enable accurate selection of apps or set of apps which may meet the defined need. For instance, a CRM is usually highly recommended for B2B businesses. But a CRM is a means to an end. It is therefore required that before a business decides on implementing a CRM, it truly needs a customer relationship management solution and not just an invoicing solution.

Start with Metrics

For each business function, a set of metrics or measures should be drafted. Data-enabled decisions are an important success factor in small and large businesses alike. And while basic financial indicators are usually what comes to mind, they tend to be embedded in out-of-the-box apps. More difficult to define are strategic indicators which will give an understanding of company direction to management.

Understand the Needs

The business needs should naturally stem from IDEAS™. Despite the unintended pun, the statement stands true. A first pass at needs (or recommendations) is usually done by the advisor and later discussed and refined. Brainstorming potential improvements with several stakeholders can help identify how the business sees certain problems or challenges solved. These ideas will then feed the requirements themselves.

Define Capabilities

At the drafting stage of requirements, it might be difficult to correctly assess whether the chosen solutions will meet the requirements, but a first pass is a good idea. This approach may help immediately discard some software solutions that will not meet business needs. For instance, it is not recommended to manage field service work with QuickBooks. This might be somewhat obvious, but there are several companies “hacking” tools to manage things the tools were not designed for. This in turn creates inefficiencies and confusion. “Hacking” tools should therefore be avoided.

Connectors and Automation

Knowing where to connect apps and where to automate is a very important step of the process. However, until software solutions are selected, it is very difficult to know connections and automations. But as for capabilities, a first pass may give ideas for which software should be selected in the next several steps.

Involve Business Stakeholders

At this point, it goes without saying that business stakeholders should be deeply involved. They know their business better than anyone. And although they need help to improve it, they will likely have invaluable insight for how to improve. A frequent situation is that business stakeholders have ideas as to how to correct deficiencies but do not have the knowledge nor the time to execute and implement.

Takeaway

Discovery and diagnosis and requirements definition are two of the most important steps in a digitization project. If these two steps are done correctly, success rate increases dramatically. In defining preliminary requirements, the business chooses which approximate direction to take and allows stakeholders to alight towards that direction. Requirements will have to be refined and re-prioritized at a subsequent step when software solutions are chosen and capabilities evaluated versus business needs and preliminary requirements.