This getting stuff down on paper lark

Not enough

mm, a tricky one and not just because every project is different anyway.

I'd like to say 'not enough', because given infinite time and resources - and this is actually a good way to start off thinking about what you want from a project - you'd have the end user stakeholders and business BA's involved in identifying base requirements. Then technical designers and hybrid BA's to develop a very detailed technical spec - the kind that doesn't leave any scope for confusion in a Delhi-based development shop, or for gradual mission-creep - and maybe even a prototype before the first line of code is written. Those very few projects I've worked on that have been anything like this always deliver the best result, requiring near-zero maintenance after delivery.

It's only when such evils as budgets, politics, staff availability and agressive deadlines telescope all this down into a single blur that it becomes a disadvantage to invest a decent amount of time in the design.

So although I accept I'm never likely to spend more than 5% of my time working under my ideal scenario, and am familiar with the coping strategies to deal with real-world contracting, I'll always argue for lots of strategic preparation.

In you experience how many businesses actually spend lots of time diagramming software? To me, its more of a hinderance than an advantage.