While successfully developing and implementing these exotic technologies in an organization, it is very important to ensure that business processes/goals, as well as end-users, are accounted for in the BIG picture. I have seen great technology being implemented in organizations but there were gaps in the business processes modeling and requirements gathering efforts which led to errors in the final output or failure to complete transactions. I have also come across very successful IT projects that worked well- did things right and did the right thing but were not being used by employees and so business benefits were not being derived. This is what some people consider a technical success and a business failure.
To make this clearer, imagine implementing an AI-powered chatbot for an insurance services company. Call-in customers are expected to interact with the chatbot to get answers to questions about their claims, insurance status, etc. To create an effective chatbot, the Business Analyst and the Solution Architect had to model the steps taken by a human call center agent to attend to every request a call-in customer has. For example, the customer calls in for a claim. Next, the call center agent goes on to review their claims history, SSN, and DOB to confirm their identity, etc. So the goal of the AI chatbot is to simulate all the steps the human agent will take to verify the customer’s identity.
The solution architect with help from the business analyst comes to create a business model that depicts this series of actions by a human agent and sends it to the developers to write the codes and train and program the chatbot. Imagine that for some reason, the Business Analyst and the Solution Architect forgot to capture in their business model that a ‘Social Security Number’ is needed before a call-in customer can access their personal insurance information. The solution architect would have designed an AI chatbot that ignores an important business rule and might lead to an error in the interaction.
This could be very frustrating for call-in customers and defeats the purpose of the IT system whose goal is to enhance customer interaction. This type of issue can cascade to 100s of other business processes within the same system because as IT systems would have it, an output for one process could be an input for another.
Taking the business process into considerations requires an elaborate requirement gathering exercise to ensure that all business processes that should be covered by the technology are accounted for at the onset of the project rather than midway. And to do this successfully, the BA must engage with the current owners of the process and potential end-users of the system as much as possible pithing the given time.
The decision should be made collectively by all involved on what processes should be done by technology and which areas will be better done manually. For every business process, the solution architect should determine the flow of information and data within the systems and the output of one process should be the input or starting point of another process.
Lastly, for every IT project, the people especially the potential end-users of the system should be engaged throughout the process. Their buy-in to the end product is very crucial to overall project success after all, what is the use of a very efficient system that is not being used by the people it was made for.
Getting the buy-in from the potential end-users can be achieved in several ways.
The first is to get end-user representatives to take part in the requirements gathering and solution architecture sessions followed by the biweekly sprint reviews to gain their feedback.
Make sure to involve potential end-users (and no-one else) in the performance and usability testing. They are in the best position to recognize if the system’s performance is subpar.
Consult the stakeholder representatives on a robust change management plan that takes into account the organization day to day activities. The introduction of new technology in an organization more often than not will introduce some or a lot of changes in the status quo. The change management plan should document a strategy for introducing this technology to the public with minimal interruption on the business day to day activities.
To be included in the change management is training for the end-users on what to expect from the new system and how to navigate the system. The training should also include a process for escalating issues or submitting feedback on the system. Finally, a plan for ongoing maintenance should be in place for when the executing team moves on.
So you can see that the overall success of an IT project doesn’t just end with delivering a fantastic solution, it also ensures that the end-users accept and gain the expected benefits from the system.