Configuration Management is one of those loaded terms that can mean different things to different people. Before I go any further, we should have a common understanding of how I use the term here.
On some projects, configuration management is simply version control over a few critical documents. For example in construction, control is needed for the expensive materials (windows, mechanicals, etc.) and critical documents (blue prints, environmental impact studies, regulatory approvals, etc.).
In some industries and domains, CM is far more extensive. For example, aircraft design requires control over a very large number of items (engineering documents, physical parts, work in progress, timekeeping, changes to plan, etc.). If the work is classified, project security requires even more need for control.
What I mean in general terms by configuration management is that the
team knows where things are kept, which version is the right one, knows the change process for each, and important dependencies between things. A project team can apply configuration management to customer documentation, construction plans, assembly-line analysis, project decisions, code builds, 3rd-party software, productivity tools, various engineering artifacts, meeting minutes, action item logs, risk registers, project schedules, staffing plans, plan iterations, plan updates, manufacturing designs, contracts, contract-performance records, time-keeping records, and on and on.
Configuration management can be an exceedingly dry topic. Not everyone has an affinity for CM. I’ve seen many a technical manager and upper manager avoid it like a dirty diaper. They just want it taken care of without having to get too close. Good CM is as critical to a project team as working plumbing is to a hospital. There are people who keep their personal records at home in excellent condition. Not everyone thinks it’s worth the effort until the IRS tells you that it will audit your tax returns from several years back.
If you don’t have good CM on a project, then little else matters. Without good CM, requirements don’t matter, morale doesn’t matter, process compliance doesn’t matter, and your risk plan doesn’t matter. Even the plan of record doesn’t matter. Why? Because without good CM, how do you know what you’ve got? You can’t be sure of what you are looking at and whether it’s all there. Bad CM is a source of such stratospheric risk that it should dominate your mitigation planning immediately upon detection.
Once you know that the stakeholders are squared away (previous post in this series), aren’t there other things to worry about first? What about the schedule? What about morale? What about replacing the key person who just quit? Yes, they are important and need attention. But not before CM. CM is really that important.
If CM is really this important to fixing a project, why don’t we hear more about it in the literature? Frankly, I’m not really sure. I suspect that CM is viewed as an uninteresting detail. One analogy I find appropriate is that of payroll in the business world. Business literature covers a variety of important topics, yet little is said about payroll.
At the same time, it is very well known that if you do not manage your payroll well, your workforce will leave and your business will suffer. Managing payroll well seems really important to me but it’s hardly mentioned. Perhaps CM, like payroll, is just not very sexy, and the average profession takes it for granted. If CM is taken for granted, this explains why I have frequently found a root cause for project problems in CM.
So how do you find out what needs CM and how it’s managed? If there is no CM documentation, the next best starting point is the WBS. PM professionals should know that the superior form of a WBS is a comprehensive decomposition of all project deliverables (not a decomposition of project tasks like MS Project would lead you to believe). If your predecessor left no WBS, you piece it together from available documentation. Since you know what the stakeholders expect, you can assess where CM should be. You must decide which work products need control, and find out whether the CM process is in place for these items, whether it’s being followed correctly, and what needs to change—if anything.
Once again, I want to add an important footnote about time management. While you are dealing with CM, there will be some spare time to look at other areas of the project that need attention. So you can still work on several problems at the same time. The priority list has to do with allocating your time and energy. Whenever you can move forward on CM, set aside those other things for later.
I was assigned to a project that was having all kinds of problems. I was not assigned as the project manager but as someone to help the leadership team in whatever way I could (probably my most open-ended assignment ever!). It’s important to realize that you don’t have to be the project manager to contribute as one. Although my role was “other assigned duties,” I kept my PM cap on and looked for trouble to dig into.
I started with stakeholder management. I could quickly determine that it was in good shape. I moved on to CM. At first blush, the CM looked good. Release management had good control, the doc people had their act together, and the code repository was not an issue. So can I call CM okay? Well, not so fast.
This is where it is so incredibly important to understand the subtleties of CM. It turns out that the little CM piece that was in fierce disarray was control of the issues list. It existed in a distributed fashion among several smart but terribly burdened minds. In other words, it was not written down. A variety of team inefficiencies (rework, miscommunications, etc.) all had their root in this CM oversight.
Some could argue that I’m stretching what CM refers to. I don’t think so. We can easily get stuck dogmatically on how we use our terminology. To see the value of my point, you need to drill down to the spirit of what CM exists for in the first place.
The spirit of CM is having the right amount of control for the work products that need it. CM is about maintaining rigor and discipline for controlling things and rightsizing that control for the needs of the business.
I then tackled the problem in 2 steps. The first was data gathering. I was assigned the help of a junior engineer who was very sharp and just needed a little coaching. She and I spent about a week and half interviewing and documenting and fitting all the issues into a format that line management could easily use to track and act on. Step 2 was setting up a process to keep her in the loop so she could track and maintain the list on an ongoing basis. The second step allowed me to disengage because the team was self-sufficient at that point.
Does this example seem small? I mean, an issues list? Really? Well, yes actually.
A team that can’t get at the root cause of its dysfunction can’t fix it; it can only palliate its problems. The issues list on this project was a small item with big consequences. In fact, I like this example because it demonstrates a lot about the mindset for fixing projects. As the old fable teaches us, the kingdom was lost for want of a nail.
CM for the issues list needed better discipline. There are a million ways to go about it ranging from useless to overkill. Two weeks after implementing a simple solution, that issues list was shortened to a third its size. Within a month, it rarely had more than one item on it at a time. Team efficiencies picked up quite noticeably.
Until you have good control of all the important work products on a project, your attention to the actual work products themselves is a lower priority. You might find there are no CM problems at all. But you still have to check. And that’s my main point. You need to take the time to check the health of CM before you worry about the remaining problems. Assessing CM and deciding corrective actions usually goes pretty fast.
(Stay tuned for part four of this series next week)
very nice article…
A bit of a delay in responding to your feedback, but life got busy since July. I’m glad you liked this article. I continue to refine my understanding based on my experience and other people’s as well. I would be very interested to learn of any specifics you found particularly helpful. Thanks. –Bob
Thanks. I’ll let Bob know.