The importance of aligning Business and User requirements
- Written by
- Michael Cathie
You have walked into your first project meeting with the buzz and excitement of a new project kick off with your internal project team, executive stakeholders and vendor.
You start to run through the project with all ears and attention on you. This is the start of a great project and an exciting outcome. Fast-forward to your User Acceptance Testing (UAT) phase and none of the functions meet the requirements. Late stakeholder engagement adds input that you wish you had earlier. Someone pops into the meeting momentarily to state that they don’t like the colour purple and it should be red. Someone else likes the term disruption and wants it to be incorporated somehow. It is at this point that you get a sense of losing the project and losing your mind.
Over the years we have had the pleasure of working with some great folks in great businesses. One thing that became evident to us in a full services project (engagement, UX, design, development) was how each area of specialty consumed and interpreted information differently – i.e.: left and right brain thinkers or executive versus marketing versus business analysts versus designers versus developers and so on.
After reviewing past projects, where we could improve and how we could better manage our own and client expectations, we found one key factor to be a contributor to a successful and a non-successful outcome – interpretation and continuity of information.
How can I ensure that our business goals and objectives are carried through all phases of a project, without being lost in translation, interpretation and creative license? Who ensures that at every level, we are adhering to the objectives? Who ensures that all stakeholders have been engaged to prevent late input and change requests?
The answer is that there is not one person that has this responsibility, as there would need to be individuals that possess an inordinate amount of skills and experience to oversee and validate all levels of a project. A product manager may possess these talents, but the answer is in a process and application to manage the process for you. A single dashboard that shows all of the projects business objectives, user, technical and design requirements, keeping everyone focused on the outcome or defined set of outcomes.
Working and testing our own theory, Webplace developed its own continuity process and named it BUTDDA, which is an acronym for:
- Business requirements
- User requirements
- Technical requirements
- Design requirements
- Development requirements
- Analysis requirements
This method has been put to the test over the past 18 months to iron out issues and learn about how we can improve it. In that time we learnt about the process, ourselves and our clients and most importantly – does the process support the project and the original intention and objectives.
The material used to capture the input is a canvas board that allows us to capture all requirements from the very start, in fact from the brief/quote stage we are able to ascertain business and user validation and discovery requirements, technical and design considerations, and success criteria. We can also understand how the project brief was prepared and by whom (ie: tech or marketing head)
As we discover or validate requirements across the project, they are applied to the BUTDDA canvas, which is shared with the client. This is a quick reference view of what the project intentions are and how the objectives are being met.
The objective of the BUTDDA canvas is to ensure:
• the objectives are continuously referenced across all phases of the project and in terms that mean something to the team as a whole
• any late input is validated against the objectives and if it doesn’t and it has a large impact it would become a change request or part of a future release
• providing a project overview for every stakeholder (client-side and internal) to understand what their part is in achieving the project goals.