Only 4% of IT projects benefit from a double dream team effect!

I was debating yesterday about how a small, smart, agile, efficient, architecture minded developers team could achieve an IT project development in time, with high quality results and smiling end users. That is true. They can perform this better than a very much bigger team of less efficient developers. Not a surprise!

But what about the chances of meeting such a case in real life?
Let’s fire. Pareto principle derived and applied to IT field. For a successful IT project we need :

• a requirements team to describe needs and requirements in an exhaustive and explicit manner, with high ability to communicate this to the stakeholder and to the solution team. 20% of chances to get this team
• a solution team to imagine the best architecture for the project and code the application with efficient programming rules, with ability to get this simple for sustainability and bound to programming error free. 20% of chances to get this team.

So, 20% * 20% = 4% (sounds funny but that’s arithmetic!) of chances to get this double dream team.
Hum. How many chances for an IT professional to see this dream project? Once a life? Not even sure of that!

So, 96% of IT projects have to deal with not perfect teams. For sure, it’s an approximation. Maybe it’s 95% ;). And the consequence is that the existing IT asset is, apart from having costed too much for the delivered value, very often not as in good health as expected. Roughly speaking, having new requirements may be called IS Evolution, and having new solutions may be called IS Modernization (case which includes using new technologies, so-called IT Modernization). Anyhow, all these projects have to take into account that the teams are not perfect and so they need methodologies and approaches that are simple to understand and apply, and focused on producing explicit requirements and solutions.

Model-Driven Engineering (MDE) is a very good way to address “explicitness”, and to connect requirements and solutions. However, MDE may not be called “simple” by itself. That’s why we need MDE methodologies which bring simplicity on top of the MDE mechanism. At this condition, MDE can be used wider than today. And the good point is that MDE addresses IS Evolution, including development from scratch, as well as IS Modernization. Unfortunately, we are not yet to this life-cycle methodology step at which we have a standard basic answer.

There is no way to break the 4% double dream team limit, but at least we, the MDE community, should keep on trying to build the dream MDE methodology!

Featured image taken from http://stuart747.hubpages.com/hub/Dream-Team