The Next Generation: Enterprise CM

(and tools) in place for a project.  It's quite another thing to do so across the enterprise.  The move from CMMI maturity level 2 to 3 deals primarily with establishing a common CM process across the organization.  How does one do this?

One of the big problems is that organizations often dictate a tool to be used across the enterprise.  If they pick the right tool, great.  But the vast majority of the time the wrong tool is mandated, resulting in budget crunches, resource crunches and capability shortfalls.

Establishing an enterprise-wide tool requires understanding the CM/ALM process across the Enterprise, and then selecting tools that can be used to support an overall process and framework.  This requires expertise and experience.  One project is not the same as another.  An Agile project which is delivering a constant stream of releases to stay ahead of the competition is much different than an infrastructure project which is occasionly upgrading repository technology.  A development team of 3 or 4 is much different than one of 300 to 400.  Yet these variations exist in any large corporation.

Initial CM standards, trying to cope with the various project attributes, were very generic in nature, adding insufficient process guidance for any project.  However, with time and experience, these CM standards are improving.

The process needs to be complete, but architected in such a way that the project variations can be supported within an overall framework.  Supporting Agile and Traditional development models really isn't that different.  If you think so, take a look at the artifacts that are needed and that have to be produced.  It's the packaging of the project management that makes the difference.  Unfortunately, a lot of the key players make the mistake that says a release process that occurs every two years doesn't have to be as efficient as one that occurs every month.  In other words, the goals aren't as lofty.  Continuous integration works quite well in a traditional model, as does frequent customer evaluation and involvement.  Yes, design is different - analysis gives way to production prototyping, but there is a mix of both in either model.  The CM process must cater to supporting the same elements in both models.  The tools must re-inforce this support.  It's the use of the process and tools that can be adjusted to fit the model, that is, as long as the process and tools have been defined in such a way as to support both.

So process has to be carefully architected, with non-negotiable elements, but with the capability of weaving together these elements to support each project's unique requirements.  Perhaps a number of pre-canned variations can be established as part of the process architecture to help minimize the amount of weaving required.

Just as important though is the selection of tools.  You can't take an Open Source tool and impose it on Ares V development, at least not with the state of current Open Source tools.  But the same goes for most commercial tools as well, with only a few exceptions in my opinion.  Tools must be process centric, but even more than that, they must be easily customized.  It must be possible to extend the tools to support the particular functions of each project.  But customization and extension is not sufficient if they require too much effort.  And it must be possible to evolve process and tool customization over long periods of time, because needs will change constantly.

Enterprise Process and Tools across the organization will give a great benefit if users can move from project to project without having to undergo significant