You know the feeling – the realization that your latest web project is suddenly off course. The development schedule is slipping and budget overages are on the horizon. The likely culprit is the identification of one or more new requirements that management or the client determines are a priority. Whether the project is an enterprise web solution or a simple web app, the introduction of new requirements once development is well underway is almost always detrimental, causing slipping schedules and skyrocketing costs. In the worst case scenario, business is disrupted, users are frustrated and goals are not realized. As reported by Forbes magazine, “25 percent of technology projects fail outright; 20 to 25 percent don’t show any return on investment; and as much as 50 percent need massive reworking by the time they’re finished.”
According to Information Age, “An expanding project may lead to development going vastly over budget, and can continue to cost, even past the go-live date. A noticeable sign of this issue is ‘scope creep’, where requirements are constantly added to the initial specification without the project’s budget, timescales or functionality being updated accordingly.”
A proven approach to help avoid this scenario is to start each web project with a discovery phase. By completing discovery, the project team is in a better position to architect and implement a solution that successfully addresses critical business, user and technical requirements. From my experience managing large scale web projects, I’ve learned that traditional ‘requirements analysis’ processes, such as the waterfall method, are not necessarily the most effective approach. Instead, let’s consider a more contemporary, “lean” or agile approach to gathering and finalizing project requirements.
In an agile development environment, being responsive to change is expected. However, this is not the same thing as starting a project EXPECTING to have changes based on the identification of new requirements. All projects benefit from the expectation that a strong effort has been made to finalize requirements before development begins. The goal is to achieve a balance between the time/effort/cost of a traditional requirements analysis phase that aims to identify ALL requirements before development begins, and a leaner, more streamlined process that will identify critical requirements, but may not delve as deep to refine more obscure requirements. The agile development process will compensate to address the less critical requirements that are identified after development has begun.
Let’s review some examples of a leaner discovery approach. At a very high level, this approach is less about creating a formal requirements document, and more focused on direct user interaction to solicit feedback:
- Identifying user personas – who are the constituents of this project (ie, the intended users) – and be sure to include internal as well as external users, as well as the users who will manage the system
- Creating user stories (sometimes called ‘use cases’) – for each persona, develop one or more stories illustrating how the user will use the system
- Creating a prototype – this may be as simple as a wireframe, or may include working, reusable software – either way, the goal here is to get something visual in front of potential users for their evaluation and feedback
- Meeting with stakeholder representatives – there is great value in scheduling in-person conversations with representatives of each user group – be prepared with a set of questions to initiate the dialogue, but the goal is to have an informal discussion where the user feels free to share his/her thoughts and opinions
“We don’t have the time or money for that.” Even this suggested scaled back discovery approach impacts project budget and schedule. However, the insight that is gained becomes a critical component of a successful project. In fact, a properly completed discovery typically results in a project actually meeting its budget and schedule parameters. And implementing the leaner requirements approach will have less of a budget and schedule impact.
The discovery process can be completed solely by an in-house team, in tandem with an outside consultant, or 100% outsourced. In my experience, all three scenarios can be effective. If, however, there is an internal environment where different factions are competing for control of the project, using an outside consultant may be more beneficial, resulting in a more subjective analysis.
So the take-away is: include a lean requirements phase to increase the probability of a successful web project launch!