It is difficult to capture all of the front-end requirements for a web application project. The job is made worse if the direction for the work is coming down from C-suite level stakeholders who have no idea how the business processes integrate with various departments and teams in the organization. All they know and care about is for the work to get done on time and under budget. The rest is left up to the subordinates; the Directors, the Managers, the Analysts, and the Project team to lead and execute on the project set forth from above.
As an architect, there’s a fact about poorly initiated projects when uncovering requirements; there will be dragons.
The “dragons” are the huge, incredible gaps in what the people familiar with the existing system think they know and what they actually know. You will be talking to Directors and Analysts who will give you background on the processes of the current application. Take most of the information you get from them as pieces of a larger puzzle. As you turn over each of these pieces, you will find that they hide much larger complexities. Either the processes are taped together with horrible code, or the organizational politics generate incredible baggage that’s hard to overcome.
So how do you succeed in slaying these unforeseen dragons? A few simple steps will lead to a higher likelihood of success for your web project. First, identify the real need for the project by asking questions from the Stakeholders. If they mention anything about their product reaching end-of-life support for the underlying technology, or their team wanting to “modernize” the system, then that is a clear sign to tread carefully. Usually, this means that the team is working to overcome technical challenges from a system that has had a patchwork of updates for several years. The team probably lacks a clear understanding of the current system either because most of the people that started the original project are long gone or the technology is no longer relevant. Reduce the scope and features of the project. Inform the stakeholders early that there are many risks associated with moving forward with such a large project, and that the harm to the business of releasing a buggy application is greater than the rewards.
Second, avoid a full-scale Agile project methodology in the beginning. Most of the organizations that I work with want to start building a house without a blueprint. This is wrong! Instead, you should follow the Waterfall methodology for the first set of core features you want to implement and build out a high-fidelity prototype. Many of the user interface elements, components, and navigation that will be used for the finished application will be defined in the prototyping phase. Many projects want to start hammering code without first validating that the ideas presented in mockups or designs make sense. Once you have your first set of features defined and prototyped, you can start the project using Agile. Just make sure that the backlog grooming stays ahead of the current Sprint so that the developers receive fully defined user stories for the next sprint.
So in summary, make sure that web application projects are small, with one or two core features to start. Gather the initial main requirements for the web application using the Waterfall methodology and prototype the final application using your favorite prototyping tool. I love Figma and Invision.
Now go forth and slay some dragons!
