Expanding The Iron Triange

As I have mentioned in my previous post I don't presume "The Iron Triangle" as a right approach to desribe project parameters. Instead of this I prefer to consider four parameters: scope of work, project duration, monthly cost and quality.
These are, roughly, parameters that can be discussed with a client at the moment of forming a vision of project. If you fix two parameters then the other two will depend on each other, if you fix three then the forth will be defined automatically.

 Some of parameters are really composite ones and the scheme can be made more complicated if desired. In example monthly cost includes employees salaries, cost of hardware, software, hosting, subcontractors' fees and so on. Employees salary in turn defines a number of team members as long as seniority distribution is chosen. Where does this distribution appear from? Generally it is defined by your company policy. If your company does not have one, then you may need to consider the number of people as another parameter.
Everything is more complicated with such parameter as risks. As there are different types of risks, they can be included into duration, monthly cost or product quality. Again, generally, risks handling is defined as company poilcy - roughly, it is common to add additional percent. But nothing prevents you to consider this paramenter as a separate one if it is required.
Finally, overal project cost is a multiplication of monthly cost and duration. 


I'd like to note, that relations between parameters are mostly non-linear. In example, if we fix scope and quality and reduce duration then monthly cost will grow very rapidly starting from a certain point. It is because of the fact that increasing a number of people in a team leads to increasing the number of communication chains, makes process more complicated, etc.
Finally we will be held back by native restrictions - no matter how much money you invest, it is not possible to implement Photoshop in a week, or in other words, "nine women are not able to born a child in a month" (though I don't like this proverb).
From the other point of view if the duration is increased dramatically for account of decreasing number of people, from a certain point it may appear that one person should incorporate several skills (i.e. programming and drawing).
One more, the last one, example is an attempt to have an ideal quality, which leads to non-linear increasing of duration and/or monthly cost.

Как я упоминал в прошлом посте, я не считаю "железный треугольник" правильным подходом к описанию параметров проекта. Вместо этого я предпочитаю рассматривать четыре параметра: scope работ, длительность проекта, стоимость-в-месяц и качество.
Это, грубо говоря, те параметры, которые можно обсуждать с клиентом на этапе формирования вижена проекта. Если зафиксировать два параметра, то два остальные будут зависеть друг от друга, если зафиксировать три,  то четвертый будет определен автоматически.
Некоторые из параметров на самом деле составные и при необходимости схему можно усложнять. Так, стоимость-в-месяц включает в себя как зарплату сотрудникам так и стоимость оборудования, софта, хостинга, сабконтракторов и т.п. В свою очередь зарплата сотрудникам в месяц определяет количество людей в команде, при условии определенного распределения сеньорити. Откуда же берется такое распределение? Как правило, определяется политикой вашей компании. Если же никаких правил на эту тему нет, то, возможно, стоит считать количество людей еще одним базовым параметром.
С таким параметром, как риски, все обстоит сложнее. Поскольку типы рисков бывают разные, то они могут быть включены в длительность, стоимость-в-месяц или качество продукта. Опять же, как правило, учет рисков определяется политикой компании - грубо говоря, принято накидывать определенный процент. Но никто не мешает вынести этот параметр отдельно по необходимости.
Наконец, общая стоимость проекта - произведение стоимости-в-месяц и длительности.


Хотелось бы отметить, что зависимость параметров в основном не линейная. Например, если мы зафиксируем scope и качество и будем уменьшать параметр длительность, то стоимость-в-месяц будет с определенного момента расти очень быстро. Это связано с тем, что увеличение количества людей в команде приводит к росту количества коммуникационных цепочек, усложняет процесс и т.п.
В конце концов мы упремся в естественные ограничения - сколько не вкладывай денег, невозможно написать фотошоп за неделю, или иными словами "девять женщин не смогут родить ребенка за месяц" (хотя я и не люблю эту поговорку).
С другой стороны, если сильно увеличивать длительность за счет уменьшения количества людей, то с определенного момента может оказаться, что в одном человеке надо сочетать несколько навыков (например, программирование и рисование)
Еще один, последний пример, это попытка добиться идеального качества, которая приводит к нелинейному росту длительности и/или стоимости-в-месяц.