1. Every organization has blind spots - people focus on what they do very well and tend to stay focused on these issues to try to spur further improvement. As counter-intuitive as it sounds, this doesn't work in RDM and you get a false sense of continuous improvement. In RDM, you have to find the blind spots, the stuff you don't do well, and fix those to really make gains.
2. People define RDM "maturity" in different ways, either narrowly describing it <<<shiver>>> as merely having a stable documentation template that is used across the corporation, or more properly, a unique process within the organization that is defined, resourced, and supported.

So, simply - what is RDM maturity?  Process Maturity is all about the degree to which an organization can be repeatable, consistent and efficient in execution on a process - same thing with RDM.  Organizations with no defined process, or a process that is defined but not enforced, would have low levels of maturity, just like organizations with well described, institutionalized and optimized process would have high levels of maturity.  The issue is that it is not just process you need to look at, there are six underlying capabilities:

• Process - What people need to do.
• Technique - How people will do various steps in the process under certain variations and conditions.
• Staff Competency - The skills, roles, functions of your people and their alignment to this target currently and in hiring practices.
• Tools/Technology - The support and automation used to complete tasks.
• Organization - The framework of doing requirements, infrastructure backing it, the services offered to the organization, and approach to managing resources.
• Deliverables - The actual artifacts, deliverables and work products needed to make the process work.

Here is where most people fail...  they don't look at ALL the underlying capabilities.  An example organization might have well defined process and deliverables, but a terrible definition of the staff competencies needed and little training and support to build these capabilities.  How effective is this organization going to be if they are essentially defining what they want people to do, but not giving people the skills to perform those tasks?  If you believe yourself to be a high maturity organization, look across all six capabilities - which is your weakness?  That's the one you need to focus on.

The other mistake people make is in thinking of requirements as only documentation, or only elicitation.  In fact the "process" of requirements is made up of a number of really important processes like:

• Requirements Planning and Management
• Requirements Elicitation (requirements gathering)
• Requirements Analysis and Documentation
• Requirements Communication
• Requirements Implementation

In reality, and organization may think it is very good at one or two of these process areas, and therefore consider itself mature, but few organizations look across all the process areas and understand their strengths and weaknesses. Again, just because you are great at one thing, does not mean the entire process is particularly efficient or predictable, and that means that it cannot be considered mature.

Getting maturity in your requirements organization might sound complicated, but it's really all about being honest with yourself in looking at the organization and accepting that there are always areas of improvement.  Most of the time, these improvements are in areas that the organization does not see - it's blind spots - so often, it's necessary to bring in outside people to assess the organization... just like you would with auditors.  So organizations often go around thinking they have a more mature organization than they actually do... and they miss out on the benefits thinking there is limited room for improvement.  On the upside, high maturity organizations have exception on-time, on-budget, and on-function performance - they also tend to deliver applications at about 40% of the cost of their low maturity competitors.  I'm wondering:  what other investment in IT yields so much just from being very frank with yourself?

Don't forget to leave your comments below