There are many things that can make or break a project. More often than not does one hear about projects being behind schedule and budgets overrun. Quite often the cause can be found in bad preparation.

Have you really thought through the return you need from a project prior to its kick-off? In short, have you defined your wishes and requirements well?

Well begun is half done

There’s many a reason why you wouldn’t have defined your wishes and requirements well. It takes time to thoroughly think through and map project wishes and requirements. Most people prefer to simply jump in in order to avoid a tedious preparation stage. Ironically, well begun is half done; 40 to 50% of the project effort turns out to consist of repair work, necessary to correct the consequences of unclear wishes and requirements.

Fresh cream or from a can?

Of course the cause could lie in an inability to make wishes and requirements clear to everyone, in spite of a wish to do so. Project teams consist of individuals working together, but every discipline has its own ‘language’. A nice example: last week my husband sent me a WhatsApp message asking me to drop by the supermarket for some cream, after work. Fine, no problem! Confronted with a full shelf I started wondering what type of cream he wanted. Freshly whipped cream or from a can? Light or regular? I had no idea! And this is where it goes south!

These kinds of situations occur daily. You assume you know enough but you didn’t inquire further. This is what happens in organizations. People assume they know what someone means. Did you know that 71% of project failures are caused by ambiguity of wishes and requirements?

6 tips to get wishes and requirements straightened out

• Understand that compiling requirements is never 100% done.
• Limit the number of project participants by choosing one representative of each discipline that will be affected by the project.
• Spend as much time and effort as possible on collecting and refining requirements.
• The more time you spend on this during preparation, the more you limit the necessity of redefining them during the project design and build stages.
• Try to work with the other project members as much as possible during collection and formulating requirements. An ideal scenario would consist of each member collecting and systematically validating requirements that apply to his specific discipline.
• Only allow one need per requirement.
• Store the requirements in a central repository for easy access and management, providing insight in the latest updates for everyone involved.

Do you know which type of cream you need?