What The Olympic Games Are Teaching Me About Maturity

Beijing_olympics_logo_4Like many around the globe, I've been watching the summer Olympics. And I’ve been struck by two realizations.

The first is obvious, but interesting. Olympic athletes vary greatly in culture, size, and sport, but also in age. A fourteen-year old British athlete partnered in a synchronized diving competition with a man 12 years his senior. And the oldest female gymnast in the Olympics performed - quite competently - next to athletes less than half her age of 33.

The second realization? We see these individual athletes age – and mature – in four year increments. Witness Michael Phelps. Four years ago he was a lanky American, who won a bunch of races. This summer, in Beijing, he displays a maturity brought on by four years, a champion’s focus, and the support of coaches, family, and teammates. The result? An Olympic legend.

So what constitutes “maturity”? Is it age? Experience? Or are those measures irrelevant? And how do you know that you're "mature"? How do you know that you're doing things the "right" way?

While a medal isn't at stake, IT professionals want and need answers to these questions. They need to know how to measure the maturity of “X”, where “X” is a practice, an individual, a team, a process, a product, an architecture, or an application. And, given the breadth of what we do, it would be nice we had a maturity model with components that applied across all our domains.

So work with me, folks. What constitutes our perfect maturity model? Does one exist already, or do we have to start from scratch? I'm proposing we start with the following components, but I'd like your input.

Strategic Maturity

  • Vision and goals - Do you have them? Are they documented and communicated?
  • Organizational alignment - Does the organization support your vision and goals? Are they aligned with the organization's goals and strategies? Are you regularly collaborating and communicating with your organization's stakeholders to promote buy-in?

Delivery Maturity

  • Individuals and teams - Are the roles and relationships of your practitioners (both staff and consultants) defined, documented, and communicated? Are you continually assessing their effectiveness individually and as a team? Do they have career paths?
  • Processes - Are your work processes defined, documented, communicated - and most importantly - followed?
  • Productivity tools - Are the enabling tools your team needs to do their jobs in place, standardized, managed, and enforced?

Outcome Maturity

  • Outcomes - What is the quality, scalability, flexibility, and performance of your outcomes? How do your deliverables align with the design for people, build for change imperative?
  • Managed evolution - Are you measuring the success of your practice and continuously improving it?

While app dev teams (like athletes) vary in culture, size, and “sport”, can we develop a maturity model that works for all of our IT practices? Let us know what you think.

Comments

re: What The Olympic Games Are Teaching Me About Maturity

Mary, yes - maturity is mostly experience. You seem however to conclude that maturity has to be defined, documented, followed and measured. The notion of a maturity 'model' misses it. When Michael Hammer wrote about processes he too used a sports comparison with a football team (Beyond Reengineering - 1997). The talented players would be trained (knowledge transfer from experienced (mature) coaches) but then they are on their own. While American football is I think the only sport where you have predefined plays (which is VERY American, BTW) the team has to use solely its own judgment to turn the play into points. No play can be excuted as defined because games AND life just aren't that way. Maturity also has to do with being confident and that once again comes from experience only. I see those IT kids with master degrees who think they know it all and that is a big problem we have today. But life (and IT) IS A GAME and does not follow rigid plans and procedures in stale structures.Evolution and ecosystem are as terms completely misplaced in IT as contradictions to planning! As the Austrian painter Friedensreich Hundertwasser said: 'A straight line is blasphemous.'

re: What The Olympic Games Are Teaching Me About Maturity

Mary, let me just add to clarify: I think we plan too much in IT .. we should treat it more like an ecosystem that evolves! The problem is that this requires totally different software concepts than the ones employed today. Which is why we are working on those. Thanks again.

re: What The Olympic Games Are Teaching Me About Maturity

Another term for "outcome maturity" could be "effectiveness." Perhaps what we really need, instead of maturity models, is effectiveness models. By nature a maturity model tends to focus on the process, the motions you go through. And yet we've all seen examples of two teams that seemingly follow the same process, but one outperforms the other by a factor of three.Measuring effectiveness, based on outcomes, is not the hard part. For Michael Phelps, in the end, it was the medal count. The hard part is knowing what to do to try to emulate that success.A certain part of this for athletes is just raw ability, and the same is true for developers (or business analysts, or testers) - intelligence, fortitude, creativity, motivation, etc., all play a part.We (Forrester) can play a part by studying organizations that are more effective, and reporting on all the practices that they exhibit. We also need to arrange those practices in a way that makes sense, in a model that organizes the way a manager would approach their implementation. But that approach is often not the kind of up-and-to-the-right view that a CMMi or COBIT assumes. Individual areas of action can be undertaken and bring results even if things that might logically be "to the left" of those practices have not been - or cannot be - undertaken. Traffic jam? Just go around it. And a GPS device with traffic avoidance can help your effectiveness in doing that...