My daily business is software development. I live, breath and practice it from the evil and deviant perspective of Scrum. Scrum is a lightweight framework for complex product delivery. Although the focus is on a product being created, built, maintained, much software development work is organised in projects. There is -semantically- nothing wrong with a ‘project’ in itself. A ‘project’ can be described as a focused endeavour towards an objective. The real problem in the world of IT is the past, and at many places still current, interpretation and definition of a project as a ‘fixed price’ project, a project in which price, scope and time are fixed. A viable return on a project however can only be achieved by balancing 3 elements: time, scope and budget. If there’s no active balancing act (one of the elements is forced or twisted beyond some boundaries) the only element remaining that can vary is… Quality.
Sidenote: if there are no frequent, intermediate releases -see the time constraint- there is also no guarantee on the optimization of value, regardless whether the 3 expectations of end_time+budget+scope are met.
I used to illustrate this ‘fixed price’ mechanism by representing a project as a machine with 4 levers, where the lever for Quality is non-negotiably fixed at ‘High’. As the operator can only move 2 levers at the same time, the last, free, lever will automatically re-position. Trying to fix the last lever will break the machine.
Although I still like my machine metaphor, let me hereby revert to the more known iron triangle. And let me start by emphasizing that, although unfortunately often forgotten, there is a 4th element, the inner element, Quality! My triangle with its three project controls on the legs is a music triangle. If one of the legs is deformed, clinging the triangle will lead to an ugly, out of tune, non-qualitative sound. Fixing scope, time and budget will lead to a terrible sound.
Let me use the iron triangle representation in another area to explain where another ugly sound originates from.
In my software business there is a typical and deluding career path, i.e. the virtual ladder that forces people on the path of ‘growing’ from developer to analyst to project manager (and beyond). Scary, enforcing the Peter Principle like that. I fight this unfortunate hierarchical vision by always referring to ‘roles’, and never ‘positions’. And ‘roles’ have everything to do with talent and insights, and not with bossy importance.
My triangle of Valuation illustrates this vision upon the core idea that every person should look for a balance in (1) interests (the love for a ‘role’), (2) the talents to perform well and the ability to do it in an appropriate (3) (working) domain. The outcome of such balanced iron triangle will be proper Valuation, the fact that people feel and are respected. Respect should be interpreted in a broad sense, i.e. financially & in various non-material ways.
Does this model solve everything? Of course not. One’s talents might be big in a domain that the person doesn’t care about. Or a person may believe in having a certain talent, that aligns with his/her interests and make it a working domain. And still not be valued. Might be that your talent isn’t what you hoped it is. Might take time to get valued. Might never come. If you’re happy and having FUN, you might not care and keep believing.
An Agile approach to Human Resources policies does not only respect people (as individuals and as Teams) and promote sustainable pace (to name a few). But well performing in ‘Roles’ will be valued more than striving for positions, and the iron triangle of (work) Valuation is a better reference model to have a good (frequent) dialogue over the balance in it, job satisfaction, performance and… Valuation.
