Famous: Iron Triangle
The iron triangle must be respected. The iron triangle refers to the concept that of the three critical factors – scope, cost, and time – at least one must vary otherwise the quality of the work suffers. Nobody wants a poor quality system, otherwise why build it? Therefore the implication is that at least one of the three vertexes must be allowed to vary. The problem is that when you try to define the exact level of quality, the exact cost, the exact schedule, and the exact scope to be delivered you virtually guarantee failure because there is no room for a project team to maneuver.
It’s better to think of it as an “elastic triangle” and vary the cost, schedule, and/or scope as required. It is critical to understand how flexible you are with respect to each vertex. Perhaps your resources are limited due to financial cutbacks but you're willing to develop less functionality as the result of lower expectations due to the cutback. Perhaps the schedule is critical because you have a legislated deadline (e.g. for Sarbox or Basel-2) to meet, and due to the potential repercussions senior management is willing to spend whatever it takes to get the job done. Once you understand your situation, you can choose one of the following strategies for elasticizing the iron triangle:
Vary the scope. You can do this by timeboxing, which enables you to fix resources and schedule by dropping low-priority features out of iteration when you’ve run out of time. It is interesting to note that many agile development processes, such as Scrum or Extreme Programming (XP) take this sort of approach with an agile strategy for change management.
Vary the schedule. You can set the scope and the resources and then let the schedule vary by varying the number and type of people on the team which enables you to deliver the required functionality at the desired cost. If you're tight for budget, a small team may deliver the same functionality that a large team would but take longer calendar time to do so. The more people you have on a team, the greater the amount of money you need to spend on coordination and therefore your overall costs increase. Furthermore, a handful of highly productive people may produce better work and do so for far less money than a larger team of not-so-productive people.
Vary the resources. If you set the schedule and scope you may need to hire more and/or better people to deliver the system. However, remember that there are limits to this approach: nine women can't deliver a baby in one month.
You can read more about iron triangle form here.It’s better to think of it as an “elastic triangle” and vary the cost, schedule, and/or scope as required. It is critical to understand how flexible you are with respect to each vertex. Perhaps your resources are limited due to financial cutbacks but you're willing to develop less functionality as the result of lower expectations due to the cutback. Perhaps the schedule is critical because you have a legislated deadline (e.g. for Sarbox or Basel-2) to meet, and due to the potential repercussions senior management is willing to spend whatever it takes to get the job done. Once you understand your situation, you can choose one of the following strategies for elasticizing the iron triangle:
Vary the scope. You can do this by timeboxing, which enables you to fix resources and schedule by dropping low-priority features out of iteration when you’ve run out of time. It is interesting to note that many agile development processes, such as Scrum or Extreme Programming (XP) take this sort of approach with an agile strategy for change management.
Vary the schedule. You can set the scope and the resources and then let the schedule vary by varying the number and type of people on the team which enables you to deliver the required functionality at the desired cost. If you're tight for budget, a small team may deliver the same functionality that a large team would but take longer calendar time to do so. The more people you have on a team, the greater the amount of money you need to spend on coordination and therefore your overall costs increase. Furthermore, a handful of highly productive people may produce better work and do so for far less money than a larger team of not-so-productive people.
Vary the resources. If you set the schedule and scope you may need to hire more and/or better people to deliver the system. However, remember that there are limits to this approach: nine women can't deliver a baby in one month.
Hiya Kashif,
ReplyDeleteGood post as always. I remember the last time I looked at this was writing the paper on Developer-Tester ratios and the project management ‘theory of constraints’. Talking with a project manager they described how projects can be ‘resource led’ or time or investment led and that would give the primary constraint.
You post covers a great example of the broader knowledge that we as test professionals must have if we’re to be effective. It’s essential that as test professionals we understand how the business and other professions work – as it impacts how we work and operate in the organisation. Of course it also means we can avoid fighting for more time, resource and investment when it isn’t there! How often do we see more ‘junior’ professionals doing that in ignorance of the kind of points you made in your post.
Thanks for posting this, chat soon.
Mark.
Thanks Mark for such an encouraging feedback, I really appreciate.
ReplyDelete