Importance of prerequisites

Paying attention to quality is also the best way to improve productivity. We do this by adopting high quality practices which emphasize quality at the beginning, middle & end of the project.
Emphasizing quality at the beginning implies you plan for high quality product, require high quality product & design a high quality product.
Emphasizing quality in the middle of the project means emphasizing on construction practices.
Emphasizing quality at the end of the project means emphasizing on system testing.

Upstream activities, i.e. architecture, design, and project planning can be done well. Projects will run best if appropriate preparation activities are done before construction begins.
Goal of preparation is to reduce chances of risk as early as possible. Common risks are poor requirements and poor project planning. Hence preparation tends to focus on improving requirements & project plans.
(specific approach to risk reduction must be decided project by project).

WIMP syndrome

Lack of planning can often be attributed to team's leadership. This is often due to WIMP Syndrome of managers. Why isn't Mary Programming?

If your manager happens to be such brigadier general and orders you to start coding right away, it's easy to say "Yes sir!" But that's a bad response, and you have several alternatives:
i.   You can flatly refuse to do work in an inefficient order, that is iff your relationship with your boss & your bank balance are healthy enough.
ii.   (Ethically questionable) Pretend to be coding. Put an old program listing in the corner of your desk (or opened somewhere in your screen) then go right ahead and develop your requirements & architecture with or without your boss's approval. You'll do the project faster with better quality results.
iii.   You can educate your boss in terms of technical projects & how/why planning beforehand will be better.
iv.   Find another job.

Compelling & Foolproof arguments for doing prerequisites before Construction

This section will help you deal with bosses who have not seen the light yet. Learn the argument & then sit down with your boss for a heart-to-heart discussion.

• Appeal to Logic - plan before building Big projects require more planning; small projects need less. From management point of view, planning means determining amount of time & people the project will need. From technical point of view, understanding what you want to build, so that you don't waste money/time/resources building the wrong thing. Sometimes users aren't entirely sure what they want at first, so it might take effort in finding what they really want. That's cheaper than building the wrong thing and throwing it away to start anew. It's also important to know how to build the system before starting to build it.
• Appeal to Analogy - do things in the right order Building software is similar to any other project. If you make a house, you make architectural drawings & blueprints before pounding the nails. You don't start decorating a Christmas tree before putting it in a stand. You don't get dressed before you take a shower. You don't put on shoes before wearing your socks. Things need to be done in order. If any impurity is introduced in the beginning it'll contaminate the complete food chain. In programming, if your requirements are contaminated, they'll contaminate the architecture which in turn will contaminate the construction & hence will lead to radioactive polluted software along with a malnourished grumpy programmer. You don't want that.
• Appeal to Data - speak stats for proof The principle is to find an error as close as possible to the time it was introduced. The longer the defect stays in software food chain, the more is the damage it causes further down the chain.

Table: average cost to fix defects based on when they're introduced & detected (units in multiples of $1000)