You start by identifying the high risk issues that are likely to cause problems and tackle these areas first. Any severe problems can be dealt with before too much money has been spent on the project. Reporting on successfully testing the difficult parts of the project will build confidence with the project manager and the client because that's what they worry about.

I second tomazos' view that a prototype (even of the smoke and mirrors variety) is a great way to start the design process. Reviewing the current product (demos, models etc.) with the client at each review stage allows them to better visualise the deliverables and provide better requirements which are fed into the next iteration.

I respectfully disagree. The theory is sound; the practice is not.

Prototypes tend to become products without further design; no one wants to revisit the work done, and if the design isn't done right to begin with, it's usually not done right at all.

Simple little programs that "evolve" tend to grow into sprawling monstrosities who's fundamental design assumptions are often wrong for the scale of complexity the end product is expected to run at.

For example, on my desk I have a paper that presents a formal proof that certain aspects of concurrency have to be designed into a system in the first place; any attempt to add them as an afterthough is guaranteed to fail in certain important aspects.

Sometimes, the "reduce the program and then re-expand it as needed" philosophy fails utterly. As the saying goes: "You can't jump a chasm in two short leaps." Sometimes, it's wise to take the fundamental achitectural considerations into account in the first place: if you know you're building in mountains, plan to build a few bridges. If you're working below sea level, don't assume tunneling is a good idea. And so forth. Don't abstract away the important implementation details, because they're what will make your product sink or swim in the real, non-abstract, non-ideal world.

I don't like prototypes; they're a good indication that the client doesn't really know exactly what they want. That's a red flag for any project, of any sort, right there. Prototypes tend to drag troublesome people out of the woodwork with all sorts of mutually-contradictory (and self-contradictory) opinions on how you should design the system, who will then remain eternally bitter that you asked for their advice and didn't take it.

Sometimes it's better to just work out what really needs doing, and do that. Here's an all too typical scenario:

Boss: "Bill in marketing needs a TPS report sent in with blue headings on a daily basis ASAP! How long will it take you to complete?!?" Me: "I'll find out, and give you an estimate by morning."

I go see Bill... Me: "Bill, why do you want blue headings on the TPS reports?" Bill: "Mary wants the entries will blue headings sent to Accounting for their summary report, and the entries with the black headings sent to Payroll" Me: "Thanks"

I go see Payroll... Me: "Why do you need the TPS reports separated out?" Payroll: "We don't really use marketing's data; we thought Mary needed this change made! Why don't you ask her?"

I go to see Mary... Me: "Hi, Mary. I'd like some more info on the TPS report Blue Heading's project" Mary: "Oh, well, I'm not a very technical person. You should talk to Fred... he's handling the matter for me"

I go see Fred in Accounting.... Me: "Fred, how do you create the summary reports?" Fred: We take the info from marketing, give it to Joe, and he writes up the summary report." Me: "Is that all you do with them?" Fred: "Yes, that's it. Why?" Me: "No reason. Thanks, Fred!"

I go see Joe... Me: "Joe, what do you do with the info from marketing for summary reports?" Joe: "Marketing data isn't part of the Summary Reports. I just need it to put the total volume from each department into the Department reports, and email it off to Ralph"

I go to HR... Me: "Who's Ralph?" HR: "Ralph? He quit three years ago..."

I go to the boss.

Me: "Job's done." Boss: "That was fast!" Me: "It was easy, once I eliminated all the redundancies..."

Prototypes "evolving" into "real" programs isnt the fault of the prototypes at all, its the fault of those who use them, or their team leaders. Prototypes are quite useful to define a common "this is what we are talking about" stage, to show something people can point at and say "I want that" or "I don't want that", all specs and words on paper are sometimes hard to visualise for non-technical people.

The prototype is definitely not there to expand upon, its part of the "build one to throw away" philosphy.. If thats hard to do, then one should create them in another unrelated language, or just draw them even, a drawn up design on paper is a prototype in a way too.

Your typical scenario isn't bad, but you missed out the part where you go back to Joe and inform him, whereby he tells his manager theres a ballsup, and they figure out who it is that does want/is getting reports etc etc. Discussing specs with whomever is concerned is a great ider (tho I'd have just called them all into one meeting), but usually doesnt allow you to just eliminate the problem like that.

C.