Baselines – The end of the road in Configuration Management?

End?, No Way! A Baseline is just the beginning……

When you have a complex problem, it is always good to ‘set some bounds’¹, ‘divide and conquer’² and ‘place a line in the sand’³. That’s 3 so far on the cliché count, but they are all true reflections of baselines and configuration management processes.

Baselines and Configuration Management. No real life project is static, it never has all the answers available up front and even the most basic of tasks is likely to have a change to its requirements. Changes can range from an alteration of delivery date or change of colour, to a whole change in direction caused by a change in circumstances, finance or regulation. If we’re not careful, project managing this changing landscape⁴ the ever changing goal posts⁵ puts project completion at risk.

We need to be clear that the proposed system requirements matched up to the user requirements at a particular point in time. Recording a baseline is that proverbial ‘line in the sand’. A baseline records the conditions at a point in time. The initial user requirements right at the beginning of the project would make an ideal baseline. It gives us a foundation to work from⁶. From there we can record, measure and control how the project develops. Far from being the ‘End’ of a project lifecycle, a baseline is a really good beginning.

Point of Decision

Now that we have our foundation, we can decide whether it is solid enough to build on. At present it may be more akin to a trench with some hardcore in the bottom, and nothing ready for a wall. However, we can now discuss these baselined requirements/or characteristics before moving on.

“Is the wall definitely in the right direction?”,  “Is the wall to terminate at the end of the garden and no further?” (Setting the bounds) “Are you happy for us to quote for the full wall on this basis, or do we need to set a half-way house⁷ at the first course and then re-evaluate?” (Divided and hopefully conquered).

If all is well we can specify the system requirements and get the concrete poured. This firming up of the foundations⁸ would be another good baseline point.

Managing Change

“The neighbours have complained, the wall is too short to keep the dog in”.  Back to the drawing board? Not quite, we can go back to the baseline and check what the agreed characteristics of the foundations were. We can’t build the wall higher in solid blocks as the  foundations were not laid with sufficient margin for the extra weight. However, building the top part of the wall in decorative open block-work will meet the changed requirement and satisfy the user. Costs adjusted, new quantities calculated and time to take a new baseline.

Whilst ideally the project would have been planned from start to finish, before the first components were laid, this is not always possible or practical in real life. Recording when and why changes were made will help us make decisions based on firm ground⁹, rather than walking on sinking sand¹⁰.

Far from being end points, baselines should be seen as stepping stones to your goal¹¹. However, they should not be seen as a linear path. There may be more than one path across the river¹², and not all routes will lead successfully to the other side. Assume the neighbour decides to move and takes their dog with them. We can rewind to the baseline taken at the foundation stage and progress down the original planned height in solid bricks as we have the record that this was a possible solution at that point in time¹².

Baselines and Configuration Management (CM)

CM is a process that aims to establish and maintain the quality and consistency of a system’s performance, functional, and physical attributes throughout its life. It is tightly linked to the Quality Management System (QMS) and Requirements Management System (RM/REQM) employed on a project. Deciding when and whether items should be baselined, would generally be subject to review (QMS). Providing traceability through the project’s lifecycle also a QMS function. Gathering, eliciting, and decomposing requirements is an RM function. Dealing with change, would need elements of all three. Whilst it may be fun playing cliché bingo, it really is time to place a stake in the ground¹³ and record milestones in your project¹⁴. Don’t delay baseline TODAY!