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)

“. 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….

But at this point you don’t have anything working…

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.

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’.

“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?

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.