A Time for Change...

Nothing endures but change.
- Heraclitus

The ink wasn’t even dry on the Constitution when the first 10 amendments, the Bill Of Rights, were approved in 1791. Everything must adapt to the world as it changes, and in the information age, the pace of change has increased. The systems and applications we develop for my agency are not immune to these phenomena. Regulations are crafted from statutes and policies from regulation and any or all of these are shaped and molded with the intent of helping people. Since the system or application is the personification of these policies, regulations and statutes, the system or application must adapt to these changes as well. That is why the ‘Set it and forget’ approach can never be applied to information systems at any agency.

Recognizing this fact is the first step to beating it. Too frequently people think that they can avoid change or wait-out the change. Those are the people who are put into a difficult situation and are forced to react rather than proactively manage change. Change will be required, but we can take steps to plan for and implement change over time. The first thing to do is to charter a Change Control Board. This is a vital component to managing change because we often want a lot of change, but have limited resources. Thus it is the job of the Change Control Board (CCB) to review and prioritize and approve changes for the system or application.

The next important component is to have a Requirements Baseline. A lot of projects fall down in this area. They want to measure and manage change, but without a requirements baseline, from what are you measuring? The Requirements Baseline includes project objectives, the project charter, the requirements specification, and the design specification. These artifacts describe the system with increasing levels of detail. The important thing to know is that the Requirements Baseline must be written down and approved in a document. A Prototype or Proof of Concept is not a Requirements Baseline. If you have a system or application, do you already have these artifacts? If not, I would recommend a change for your CCB to consider, “Develop the Requirements Baseline.”

The tool used to record the prioritized changes to a system or application is a Change Control Register (CCR). It does not, and should not be complicated. Each change must have a unique number for tracking, a description of the change, a status (new, completed, under development, rejected), priority, and history of actions. Excel is a great tool for developing a CCR. I like to have all my active changes on one worksheet, all my completed changes on another and my rejected changes on a third. This helps the CCB to focus on the changes that are important today and not on the changes that have already been addressed. It is important though that you not lose track of either the completed or rejected changes. I find myself referring back to them frequently.

Finally, the CCB must meet on a regular basis to solicit and consider changes and changes that may have been furloughed due to lack of funds.