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 measured, An Expected Gathering
…
Complexity is a Matter of Perspective 
Usually those are business decisions, not decisions controlled by an IT project manager. The business asks for a solution to perform some task and asks the IT team to implement it. I see the ‘timing’ and the Iron Triangle mutually independent in that regard.
That aside, it’s a valid point, but I wouldn’t put that on the IT manager nor does it take away from the value of the big three.
LikeLike
As “Quality is something that matters to someone who matter – at some time”, Yes it is a business decision. And no, everyone in the solution delivery (business and IT) must be aware what drives the decisions.
LikeLike
[…] did discuss scope, price, schedule and timing – along with bug […]
LikeLike
[…] considers the risks and mitigate them. They considers the risk, the minimum viable quality and timing of their delivery. If it’s buggy, hey no problem – in context. If testers aren’t […]
LikeLike
[…] In conclusion to the above analysis – Oredev have a majority of relevant tracks for the above business goals. But there may be other criteria – people for instance, cost and timing. […]
LikeLike
[…] also: Acceptance criteria are more than what can be measured, Look for Minimum Viable Testing, Without Timing – Quality, Schedule and Cost is nothing, Value of Information for Decisions , 16 points that may rock the boat, When do […]
LikeLike
[…] ratio has more checks..? That would depend on what the business would like to know (what is their perception of quality) and how well the domain is codified (Genesis / […]
LikeLike
[…] refinement, more testability and less “easy“. But this is what we have to work with for now. Even if we had all the time in the world (we don’t) – we would not be able to write […]
LikeLike
[…] similar research on high performing delivery teams. In the recording you can hear me talk about how Timing is Everything for working on bids and tenders. And contemplating the lessons from social enterprise networks […]
LikeLike
[…] – the more the requirement risks not addressing an up-to-date business objective. Timing is key. Some tools provide epics and user stories – but the structure is often misused to be a […]
LikeLike