My Thoughts about the CMM

I always have seen the capability maturity model (CMM) as a great tool to evaluate development efforts or performance of a company from the IT perspective.  Depending on the role their IT department want to play there will be some resources involved and so there will be some benefits that upper management will expect in return for committing those resources.  And this is regardless the role the company decides to play in terms of IT which can be the role of adapters, adopters or inventors.  But in general I see the Capability Maturity Model or CMM as a good reference to manage those results.  The CMM is a good reference point once managers achieve to relate its phases with the current activities of their IT platform.

In my opinion, in managing an IT group it is very important to know how to assess the position of the group activities in the CMM.  The purpose of this is not to see how great it is but to have a solid criterion to compare with on how things should be done against how things are being done.  Therefore, a must for this is having a complete honest evaluation and the first step is acquiring some tools and knowledge to complete this evaluation.  The next step could be designing the strategy to move to the next level in the CMM together with the group activities necessary to take the group closer to the general objective.

One strategy or at least part of the strategy includes providing developers with the tools to speed up development tasks and aligned the effort to the organizational purpose or objectives.  These tools come in many forms like RAD tools or in house made libraries like developing a Data Access Library that connects any application to any database table in the organization.  It is my intention in this small article to explore some ideas about developing in house tools to improve performance.  These small tools can make a difference in producing results. 

In terms of productivity, the front line (developers work) performance determines the benefits for the organization and that affects directly the bottom line.  The development effort in this case is centered in enterprise level applications architecture rather than independent efforts of development to provide single applications for specific tasks.  From the management perspective the goal is to build a pipeline to provide diverse software development services to different internal customers in a continuously changing environment with limited resources.

There are tools that can be developed in house to be available to developers so they can have a handy set of pre-programmed solutions that they will use to produce what the organization needs at any time.  And more important (well not more but it is very important), having these tools designed in a proper way (from the big picture) will provide flexibility in a way that the whole organization can adapt quickly to any disruption in the market.  Moreover, since we are talking about market disruption, these tools may provide the foundation so the company can become disruptive in its market.  These tools may become an enabling technology for the company to not just adapt to market changes but to trigger those changes.  These tools become the means through which the company obtains a competitive advantage.

 Under this context, there are two important question a developer leader or manager usually come up with.  First “What does my company need”, and second, “what does my company will need” (Where we are and where we are heading to).  And thinking about these two questions will position the manager first in understanding the mission of the company and second, the vision of upper management; then he/she will have a compelling need to evaluate his current position and come up with a plan to move ahead.  I’m not sure if this can be done the other way around because if we don’t know or don’t have an idea of where we want to go we may not have anything to compare our actual situation with.  Probably he/she can compare it with the past and chances are that the present will look better and then he will be stuck in time.  And two years from there he will be doing things the way they are without innovation, without vision, and probably without enthusiasm. 

Now there comes a big question:  Why to invest resources to develop these kind of tools?  The answer looks simple to me and it would make sense to upper management because it can be translated easily in numbers that at the end represent money.  There may be many benefits.  From the Knowledge Management perspective there are reasons too (future blog) but as software engineers, we need these tools to make development an easy task, as easy that any junior developer can be hired to produce what a senior level developer would do without those tools.  Of course it is not as simple as it sounds, another important element needed is an enterprise framework.  For now, having in mind that is chipper and increase productivity having a senior developer leading the job of three junior developers than three senior developers doing the whole thing (I think this falls into what reengineering is).  And at the end besides providing a production benefit there will be a technical benefit like we will be one step closer to that important part of the CMM that says: “making the process repetitive”.