Many business analysts spend most of their time in meetings documenting business process requirements, explaining what they mean to developers, waiting for weeks and then figuring out why the implementation didn’t match the documentation, rinse and repeat endlessly! The job is often a series of user experience wireframes, record state transition diagrams, business process swim lane diagrams, and other methods/diagraming/documentation tools.
Getting consensus on the business requirements may take several meetings with many different stakeholders as you iterate to a set of first drafts or mock-ups that you can ask the developers to build for you. When your stakeholders see the initial builds, we begin the process again because after they see a working application, the next round of requirements emerges. The developers now have to rework/refactor their initial build, so they aren’t happy. The project manager is facing another iteration of tasks and costs so they aren’t happy. The business stakeholders didn’t get what they asked for first time so they aren’t happy either! In fact, the average development team spends between 20 – 40% of their time refactoring code.
One of the main reasons that it takes so long to get consensus on business requirements is that most people think better when they have a working application to interact with. There are many factors that contribute to this challenge, including a gap in understanding implicit requirements, silent stakeholders, and incomplete non-functional requirements.
The efficiency of the business analysis process is directly and inversely tied to the time between the meeting where the requirements are discussed and when the prototype is available. Then divide that by the number of iterations required to get to a working application.
It’s not just the effort and cost of the business analyst in this endless cycle. You also have to factor in the effort and cost of all of the stakeholders involved in the meetings and review process. The wasted effort and cost of the developers building prototypes that are incomplete or just plain wrong.
So how can we increase the efficiency of business analysis?
We need to do two things: reduce the time to interact with a working implementation of the business requirements; and reduce the number of iterations. Fortunately, a good approach for reducing the first also directly reduces the second.
Most of the business requirements for a typical application relate to the movement of data between a user’s screen (the rendering of the application user experience (UX)) and data storage (Create, Read, Update, and Delete data (CRUD)). Analysis of many software applications shows that most (>90%) of the code is directly related to UX and CRUD functionality.
If we can virtualize that UX and CRUD as configuration data that can be quickly created by a business analyst, then we eliminate the time taken to both document the requirements and wait for the developers to build an initial prototype. In other words, we can have the business analyst configure the desired user experience without requiring a developer to write any code. This process “short circuits” the cycle of having a business analyst mock-up a prototype of a desired user experience and then hand it over to a developer to actually build the application. If the BA can configure the user experience as quickly as creating a mock-up, then we eliminate the development effort and significantly shorten our build. In addition, by virtualizing the UX and CRUD, we have literally eliminated over 90% of the code. This makes the finished solution much easier to change in the future and permanently eliminates the cost and effort to refactor code.
The configuration data will need to encompass: the defined user experience (e.g. form definitions, field definitions, data model, navigation and search, styles and color scheme, header and footer details); the record’s state transitions (e.g. “draft”, “submitted”, “closed”, or other record lifecycle); and the user’s role (e.g. admin, customer, supplier, etc.). To render the application user experience, the configuration data is interpreted using a dynamic page builder to generate a working application. This means that changes to the user experience could be made by a BA during a meeting where the requirements are being discussed with stakeholders and then instantly presented to the stakeholders! The stakeholders being able to quickly interact with a working model of the business requirements both improves the quality of the requirements and reduces the time required to obtain consensus.
What about the other remaining 10% of the application? Workflow automation requirements will still need to be captured and passed on to the development team for implementation. Since the rest of the user experience has been configured, we can direct the developer to the exact place in the user experience that the workflow is invoked. This helps simplify our workflow automation requirements to focus on the specific result the workflow needs to complete.
Like to learn more?
If you would like to schedule a virtual meeting or learn more about trellispark, please contact us and provide a brief description of your interest. Or simply drop us an email at info@greatideaz.com.