In this Lightning Cast, we’ll explore the practice of using stage gates and a big design up front. Why do organizations use the BDUF approach and is there a better way?
A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.
A common practice in many organizations is to create a big design up front (BDUF), but it that the best approach? Regardless of your delivery methodology, consider the impacts and weigh your options when you choose how to deliver solutions.
A big design up front approach is a stage gate process in which each stage (e.g., scoping, requirements, development, testing) is completed in its entirety and approved before moving to the next stage. As a Business Analyst, that means that you’ll finalize the complete requirements package and get stakeholder approval before the team starts building the solution.
On the surface, BDUF makes sense. If we can get everything right in the beginning and resolve all issues, we can mitigate risk and be more confident that we will achieve our goal.
Reasons Organizations Use BDUF
Organizations use a stage gated, big design up front approach for two main reasons: to gain a sense of control and to avoid risk.
From a control aspect, they feel that if we know the scope, cost, and all of the details in the beginning, they can plan better and hold teams accountable for delivery according to that plan. Part of this may stem from a lack of trust or discomfort with the unknown.
The stage gate process also helps address the needs of risk averse organizations. We know that changes made later in a project life cycle are more expensive than changes made at the beginning of a project. A change identified during the testing phase will be much more expensive than a change identified during the requirements phase.
The problem is that this sense of risk reduction is only an illusion. The truth is that we can’t know everything up front. Changes will happen.
What really reduces risk? Creating solutions in smaller increments reduces risk by making it easier to understand the initiative and the associated work. This also makes it easier to estimate the work (because it’s in much smaller pieces) and we can more accurately estimate.
In addition, building in small increments allows us to create faster feedback loops. We can get feedback on what we’re building more frequently, learn and adjust as needed. If we get off track, we can adjust with the next increment.
If your initiative is one that you’ve done many times before, requirements will not change, and more frequent feedback would not help, then creating all of the requirements up front may be reasonable. It’s also likely that if you’ve done this before, you can reuse the requirements from past initiatives.
I would also recommend that you make the process as light weight as possible for initiatives such as this. Don’t use a lot of overhead – just do it.
For all other projects, we know change will happen, so we might as well do things in small increments so that we don’t waste time full finalizing things that will change (or won’t be needed).
Instead of developing a big design up front, use an evolutionary design approach. Think about the term ‘evolution’. You start with something and it changes as it responds and adapts to conditions.
To apply this concept to requirements, start with high level requirements and get feedback. Evolve your requirements by successively adding details or by adding new information.
Identify which of the high level requirements are the top priority and start evolving those first. Once you get to a point where the developers can work on a slice of functionality, let them begin while you work on evolving the next highest priority item.
Shifting From BUFD
Moving from a big design up front approach to more of an evolutionary approach isn’t always easy. Your organization may mandate the methodology and process.
If trust or fear of losing control is an issue, I suggest calling it out as an issue and discussing it respectfully to address the issue. If it’s not safe to do so, you can try one of the approaches below.
Suggest an experiment. Make a recommendation that for a small initiative, you run an experiment in which you deliver the solution in iterations. Make your work transparent and invite stakeholders to demonstrations at the end of each iteration. The transparency may make them more accepting of using this approach on more initiatives.
Try splitting up a larger initiative into phases with each phase developing smaller pieces of value contribution to a larger whole. It’s important that each phase delivers end-to end value or capabilities to your customer.
Use prototypes and mock-ups to create fast feedback loops. This allows you to get feedback and adapt to input and changes earlier in the project.
Listen to this lightning cast to find a better way of delivering value.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.