The joy of big up front design

Big up front design (BUFD) is a term that finds its origin in the standard waterfall model. It is often criticized and seen as something that should be avoided. I believe we should not be so easy to dismiss BUFD. I want to discuss the good things of BUFD, because I believe there are many. For a minute, stop thinking about project effectiveness and all those agile principles and let's zoom in on an imaginary group of people, team red, working on their Big Design. Perhaps you'll agree BUFD has it's merits if you look at it from a personal perspective.

Let's imagine the project has just started, the business has come in with a request and they want their problem solved. The competition has launched a new product or is offering their services for a lower price, so things need to change. Let's say their problem is 'finding information on customers'. When the business wants information on a customer, it takes forever to find all information. They want an automated solution that can satisfy their information needs quickly and accurately. Sounds like a familiar problem? Let's look at our team to see how they handle this. They're having a meeting on 'process and tools', asking themselves 'how can we tackle this?' They want to do a good job, letting the business know how the problem needs to be solved, coming up with answers and solutions. There is clearly a positive vibe in the team, you can feel the 'we're going to get it right this time' atmosphere. After a few weeks of solid discussion and studying of the business case they come up with a plan. The business is pleased, this looks like a real plan. What are they waiting for? Let's do this thing! So after the business has given a 'go' they start making plans for next year, 'we'll have this new search capabilities, how can we turn that into profit for our business?' The business starts to get exited as well, the goal of any IT project.

So next step, the design. It's gonna be a big one, this is a complex problem which needs some complex solutions and good thinking. Thinking caps on and let's make that design. All limits are off, out of the box thinking is what we need. Someone says: 'What if we use this new technology? We'll be able to roll out new solutions in no time, the business will be so pleased'. That's what I call focus on business value! We've got some enthusiastic people on the team. The design is coming along nicely, after only a few weeks the outline is getting visible, without being limited by details the team can paint a perfect picture. Discussing all kinds of issues, thinking of possible problems (such as error handling) AND their solution (a error reporting tool or framework will do the trick) they work through all the details. It's not easy, but after a few months they finish the design. A job well done!

Now it's time to get some more support for the project, more people need to get involved. The business needs to be updated of our design as well, we want to include them in the process, we've got feedback along the way but now they can see the finished design. If we present it well they'll come with good feedback and perhaps even new ideas. That will give the project a new boost... Luckily, the presentation goes as planned, the business is pleased. If it all works as designed they'll be competing like crazy in a few months...

This is where the implementation cycle starts and my blog ends. I won't go into further details, you might have experience with this kind of projects and fill in the rest yourself. But let's think about what the team and the business went through. BUFD allows for good communication, working as a team, sharing experience, fixing problems, involving the business, thinking about business value etc. With the added benefit of setting high ambitions and creating an imaginary product and business process that makes everyone feel good. People like imagining things, thinking big, thinking of future issues and coming up with their solutions by discussing different options. Plus, the development phase is tough, so good preparation increases confidence throughout the company. BUFD gives you that confidence...

If people want to stop doing BUFD, where will they get our sense of security? Can they keep using their imagination and expertise to reach that state of perfection that they're used to work towards? If we want to improve the way people do IT projects, we'll have to understand their current motivation for doing it waterfall, only then can we make the first steps towards change.

Comments (11)

  1. Nico - Reply

    October 14, 2007 at 12:07 am

    This is a very confusing post...what is your point exactly?

  2. Vikas Hazrati - Reply

    October 15, 2007 at 12:46 pm

    "BUFD allows for good communication, working as a team, sharing experience, fixing problems, involving the business, thinking about business value etc."

    Couldn't the same be achieved with an incremental design?
    I see that it might be easy to have more involvement of the business by getting BUFD however then we lose the merits of educating our customer properly and being effective the incremental way. I still see a huge risk of throwing away everything after doing a wrong BUFD.

  3. Lars Vonk - Reply

    October 15, 2007 at 11:46 pm

    Hi Machiel, I have some questions/remarks regarding your post:

    "If we want to stop doing BUFD, where will we get our security?"

    - Security in what?

    "If we want to change the way people do IT projects, we’ll have to understand their current motivation for doing it waterfall".

    - So do you want to change the way people do IT projects?

    - What are in your experiences "their current motivation"?

    - I agree with you that it is good to understand the people you are communicating with, especially when you want to convince them of something.

    "Plus, the development phase is tough, so good preparation increases confidence throughout the company. BUFD gives you that confidence…"

    - It would scare the shit out of me ;-)....

    Also don't forget that at the end of this story nobody is really happy. What good does it for the end customer when the project says "Well here is your shitty product, way over budget, but we had a great time designing it!". Would you be happy if it was your design?

  4. Mary - Reply

    October 16, 2007 at 12:30 am

    Hi folks,

    I don't know if i right about this bur i believe dat Machiel is trying to align the 'good' things about BUFD methods and agile developing methods or to let us see that these approaches can be combined when necessary or appropriate given the circumstances.

    In large and more 'formal' organizations they use Prince2 in stead of let's say DSDM.

    I will give you a example of some comparison between Prince2 and DSDM.

    They both have a defined set of products, with prince2 focusing on the projectmanagement and control products and DSDM on those products required to deliver the final product – the solution (as scrum is too)

    In DSDM there is just enough management control to ensure that the project is managed and run effectively. But in more controlled environments that's not enough.

    For a DSDM project to be managed and controlled to Prince2 standards, it may not be necessary to use all the defined Prince2 products.
    In Prince2 the product flow for each project is contained in a Project Initiation Document (PID) and states that if a product is not to be delivered some explanation for this omission can and must be included.

    DSDM is a tool to understand, plan, communicate, control and deliver all kind of projects (not only IT) and Prince2 is a structured method for effective (or must i say efficient) project management.
    Prince2 is not designed for effective product delivery and therefore alone does not deliver a solution. It is there to ensure that the project has a sound basis for starting, there is sufficient governance, is planned and that there is a means of checking the project has met its upfront set objectives.

    DSDM is a framework based on best practices and lessons learned to provide a flexible yet reasonable controlled process. It has control elements and they are considered important. DSDM fits well within a Prince2 environment. It will require some tailoring as most of the elements within Prince2 are also inherent within DSDM. In some areas, however, Prince2 can provide useful additions to DSDM.

    The point is:
    Some of you think scrum is the best but remind yourselfs that to start with a scrum developing (build) proces you have already had a project start up, most of the requirements known with some of it prioritised, usually also the funding, a communication plan, marketing and sales involved etc. and scrum is not (yet) accepted in certain environments.

    Be very carefull in stating that your customer has to be educated. It can be seen as arrogant. Do what can be done and do not throw away anything that 'works'.

  5. Machiel Groeneveld - Reply

    October 16, 2007 at 9:41 pm

    To clarify, my main focus is on the fact that a lot of IT projects take a BUFD (standard waterfall) approach. I'm trying to understand why people take that route. There must be a motivation for doing it this way, probable even more than 'that's just how IT works'. Lots of professionals do waterfall every day, my honest question is: why?

    So I'm not making a case for or against agile here. And I'm not making a case for educating the customer. I do see a need for more collaboration amongst IT people and between IT and the business. And I think collaboration starts with understanding.

  6. John Farrell - Reply

    October 17, 2007 at 3:15 am

    "This is where the implementation cycle starts and my blog ends."

    But at this point you don't have anything working...

  7. Patria - Reply

    October 17, 2007 at 5:31 am

    hi Machiel

    ". There must be a motivation for doing it this way, probable even more than ‘that’s just how IT works’. Lots of professionals do waterfall every day, my honest question is: why?"

    well, my only guess is that some big shots within company decided that it was the good way of implementing an IT project. now, it would be interesting to see the rate of success of IT projects following a waterfall methodology compared to those that chose the Agile path...
    In my experience, being Agile allows for an open channel of communication with the customer on a daily basis, show them results at the end of every iteration and lets you concentrate in implementing the business needs instead of writting endless Word documents that will not reflect the reality at the end of the project....

  8. Serge Beaumont - Reply

    October 17, 2007 at 9:49 am

    Looking at the previous commenters, I think I have a different interpretation of Machiel's post. It's not about defending waterfall in any way: it's a tongue-in-cheek piece that reminds us that there are good bits to be found in anything. We should not throw away the good with the bad.

  9. dcdashone - Reply

    October 17, 2007 at 2:55 pm

    BFUD => BOHICA

  10. Mary - Reply

    October 17, 2007 at 6:31 pm

    Hi Machiel,

    Thank you for clarifying. I could not be so blunt as to suggest that you are cynical about the approach to your colleagues, designers and big upfront designs. That’s why I react again and want to share my thoughts on this with you. For I think you’re honest about this and I am not a designer, nor a colleague; just an in the subject interested person.

    I think designers make big upfront designs for the same reasons as why you posted your blog and clarification: the basic human need to understand (and be understood within) the big picture and to solve problems. This of course, assuming designs are made to understand and solve problems; to grasp reality in a certain way. Designing was (and still is largly) viewed as a science which required comprehensive models/structures in which the interrelations and interdependencies are drawn and thus understood. It gave (gives) an understanding of the problem in a broad perspective and in more dimensions. This was/is not only the matter in designing but in other sciences or disciplines as well.

    There were (are) other and parallel approaches but let’s not make this an historic summary and a too complicated story. Views (paradigms) change in time due to many factors. To name a few: level of education and experience, research techniques, means and levels of – distributed- communication, knowledge of other cultures, shared insights, speed of change, evolving information technology, etc.

    In this day and age ‘the world’ is a turbulent environment and the problems to solve are complex.
    Still, we want our solutions to fit the organizations and their needs, but are submitted to (our own) bounded rationality. The big picture has become too big.
    Now we think we can achieve reduction of complexity through cutting problems into smaller chunks addressing a specific part or concern of the problem. This is because we are aware that complexity consists of several dimensions (e.g. dependency, relatedness, predictability) and solutions to large (big) problems can be more easily constructed if we decompose them in a collection of smaller (related) pieces.

    To illustrate the outcome of this mindset: increments, components, iterative (lean, scrum, soa)

    Actually I think we are trying to combine a collection of competing approaches, methodologies and mindsets. And design paradigms, but not only these, shift from ‘a science’ to more of ‘a process’ and increasingly minding the human factor, people, you and me. But it takes time to adjust. We live in an interesting age.

    Be wise!
    Mary

    BOHICA (bend over here it comes again) isn't tonque-in-cheek and can be achieved when a product owner doesn't communicate with the - other- users. This can happen in BFUD, Scrum, DSDM. We have to prefend this from happening.
    As with FUBAR (fucked up beyond any recognition)

  11. Marcus Blackhall - Reply

    March 13, 2012 at 12:38 am

    I believe the main point being made here is that Waterfall works for some companies. Some of these have tried Agile type practices and failed. This is with their resources and budget constraints. In many industries the business requirement does not change frequently. If the design is ratified in conjunction with the business it can result in a robust product that fully satisfies the business.
    AGILE may or may not have produced a better result. A business will look to achieve the requirements within the constraints of the budget available. Many businesses also work with offshore teams. Planning a BUFD or an AGILE type construction require different skill sets both from the project management and from the existing development teams. Clearly the only answer for companies to choose is for benchmarking.
    BUFD or AGILE do not have anything in themselves that lead to greater sense of achievement. It is the drive to achieve the result that satifies the business requirements that determines the sucess. All developers, managers, business analysts have a bond with each other when they have succeeded as a TEAM in meeting these requirements. If BUFD design has achieved it or AGILE they will both be considered successful strategies.

Add a Comment