Posted by Mary Gerush on August 18, 2008
Like 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.
- 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?
- 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?
- 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.