Many people advocate agile work methodology, but there are times when the waterfall method is more beneficial. The top things to consider are whether the company has an in-house development team and if the UX team is integrated in it.
Even though it can be difficult to incorporate UX into an agile development process, there are clear benefits to agile development. Since agile basically breaks a project in to many micro projects the main benefit is the ability to respond to market changes and changes in business directions. The overarching idea when incorporating UX into agile is often to have the UX team a few sprints ahead of the developing team which allows the UX team to iterate the design a bit before handing it over to the development team.
However, there are times when it is more beneficial to split the project into two separate projects and revert back to the waterfall method. One example of this is when you don’t have the necessary competencies in-house. For example, an electricity company in Sweden needed a new intranet but they did not have a lot of competency with either UX or coding. At this point most companies would have hired a consultancy that would provide all of the services needed and provide a “functioning system” in the end. We all know how this usually turns out: most of the times the users are neglected and the delivered system is not good enough. The result is to try to fix the issues later on, which results in late and very expensive changes. The reason why this tends to happen is because the purchaser doesn’t know enough about UX and the consultancy can get away with minimal spending on user experience.
Luckily, the energy company in Sweden had a project manager that knew UX and realized he would not have time to make sure the consultancy take all necessary UX steps. The solution for them was to split the project into two distinct phases by sending out two requests for proposal. The first request for proposals was for the system interface and was sent out to different UX consultancies. The goal was to create one clickable prototype without any back-end functionality, but comprehensive enough to clearly communicate the design. Since these companies understood the importance of including users and iterating the design, they discovered unmet needs and additional features they needed to include before it became expensive to make these changes. The final result turned out great and all stakeholders (end users, project managers, project sponsor, etc.) were happy with the interface.
With the interface done, they created the next request for proposals which included the prototype so that all bidders could see exactly what was expected to be delivered and how the system was supposed to work. The benefit was that the developers could get an overview so they could select the right technology/programming language from the start and structure their databases in an efficient way. As an aside, the coding companies also preferred the split proposal method since it decreased their risk (they knew exactly what to build) and they did not have to try to include UX, which was not one of their strengths.
The result was a success and the system worked flawlessly for the users (with some minor bugs) and they did not have to do any late changes. The budgetary split between the two parts of the project was roughly 25% for the first part and 75% for the second part. I believe there are very few consultancies that would take on a contract and allocate 25% of the budget to UX.
When looking into purchasing a system, it can be very tempting to hire one vendor that does all of the work because they charge less, but with all of the late changes that could be necessary, will it really be cheaper in the long run? It can be better to develop the interface first and then ask for proposals, as mentioned earlier. Some industries often purchase out- of-the-box solutions which may have interface limitations. With the split proposal, it is possible to find out what the vendor is unable to build so this can be taken in to consideration when choosing a vendor. They may also suggest their interface solution, which you can evaluate to make sure it is good enough.
The primary benefits of a split project are:
- Decreases the number of late changes
- The right technology is decided upon from the start
- Better estimate of the amount of work required to implement the system
The primary drawbacks are:
- Significantly increased run time for the project
- Limits the possibility to account for rapid changes in the business environment
- Increased upfront investments
Don’t get me wrong, I am not opposed to running projects in a more agile style and overlap different project phases. It is more important to recognize which approach is best for which project (there is none “one fits all”). If you have your UX team and developers in-house and they are working close together, I definitely think you should capitalize on this benefit and run it as agile as possible. The problem is if you outsource the project or if the teams are not considered a unit (you may have internal billing resulting in different goals between the units), you may run into problems.
The final thing to consider is if you are just starting up a UX team in your organization. At this point it may be better to start with a full split between UX design and development. Later on, when everyone gets more used to the process it will be possible to overlap between these two groups. Think of it as, “don’t try to run before you can walk”.
© David Juhlin and www.davidjuhlin.com, 2015