daily standup meetings are gimmicky nonsense

run as fast you can in the other direction!

As an example, I encountered a requirement recently which included the phrase ‘any printer shall be supported’. After discussions, and any customer that doesn’t engage in discussions is clearly an indication of a very difficult customer!, it became very clear why the requirement had be written in the way – a third party would be supplying the as yet unspecified printer. However, the discussion did enable the requirement wording to became slightly more achievable by rephrasing as ‘a network connected printer supporting postscript’. At least I would have a chance of testing this (and have constrained it to exclude printers with parallel or usb interfaces).

The hardest part of requirements is not the accepting the requirement, it is the validation at the end. How often have you encountered ‘This isn’t what I wanted’. The only way to avoid this is to remain in constant contact with your customer to validate any assumptions throughout the development so that there aren’t any surprises at the end.

You have also touched slightly different subject – hidden assumptions which I consider as the biggest danger for any project. Especially those assumptions on client’s side are risky The real trick is unearth them early!

I’ve found that clients don’t like questions. Even the right ones. They prefer conversations.

Your second situation is really about playing back a solution with a bunch of assumptions you’ve made earlier. Instead of asking questions, let the client play with it. Then the real conversation starts in which you validate and/or refute ALL prior assumptions.

Man, I assumed you’d support IE6! Of course it should render on the IPAD? Yes, why on earth would you not make these pages SEO friendly.

Nothing hurts you more than hidden/unvalidated assumptions.

Thanks a lot for additional insights!

Recently I have heard that quite often we are dealing with fixed time and fixed scope projects. It sounded quite risky so it’s good to learn that when deadline is a priority we can still control scope.

In the digital industry clients have deadlines for all sorts of reasons, product launches, launches to coencide with events, license renewals etc.. some are harder than others but in certain cases meeting a deadline means making money or not.. so when the client is paying literally paying our wages they do expect us to meet the date.

There is always room to manage scope, either by descoping (or simplication of) lower priority features in order to meet the date… but as a general rule when a deadline is drawing nearer teams (client and supplier) work harder as more unknowns come to light and MUST-HAVES! are uncovered.. This pressure then release cycle as deadline is met is what gives us our sense of achievement when a project is delivered.

Deadlines are common across all industries, ask an accountant about the pressure to deliver as they come upto a fiscal year end.. or a lawyer preparing for a big case.

Other times you’ll find it’s some immovable barrier, such as “we must launch in time for the shareholder’s AGM” or “we must launch in time for the Christmas sales period”, etc. In these cases the negotiation stops being about time and starts to be about scope – if we’re going to make that deadline, we may need to cut something out…