A project usually has to be on target on Quality, or at least on agreed quality. 

A project usually has to be on Schedule, or at least on agreed schedule.

A project usually has to be on target regarding Costs, or at least agreed costs.

It is an ancient IT project manager mantra, to control these parameters using change requests and change management – typically due to events during the project. It takes to long, it’s too buggy, it costs more etc. etc. To change one parameter – you have to change one of the others. In example (and strictly in some context) – even adding more testcases will increase cost or influence the schedule (discuss).

But there are plenty of examples (of Government IT projects) that are on schedule, on cost, on quality – yet they fail the timing and after a number of years delivers a system on an obsolete platform [true story]. More recent examples – bank D launches their banking app first, get all the press – and a month later bank N comes around – on agreed schedule, agreed costs, agreed quality… and get very little of the “hype”.

When contemplating the business decisions – what seems right now right now might be wrong later – considering the Timing.


Acceptance criteria are more than what can be measuredAn Expected Gathering

I’ll fix this later :-)