Baselines

Volunteering is a great way to give back to the community, meet new and interesting people, and keep me from playing Civilization until the wee hours of the morning. OK, sometimes not so wee. I know it’s seriously time for bed when I hear traffic on the road – that means people are heading in to work and perhaps I should think about it too. Fortunately I don’t do that too often. Anyway, one of the things I have volunteered for is to serve drinks at charity fundraisers. In Ontario, you are required to take a training program called SmartServe if you want to serve alcohol. One of the things they teach you is how to recognize the various stages of alcohol consumption, from slight buzz to slurred speech to pronate. In each stage the subject exhibits particular characteristics, and your job is to stop serving when the subject has reached the point where he or she is a danger to the rest of society or at least, your shiny clean floor. Keeping track of who is at which state in their progression toward inebriation is a challenging task, so it is a good idea to label each client according to the last state you observed them to be in.

Turns out this is a good analogy for large projects, where each sub-project is progressing at its own rate towards completion. Rather than forcing each sub-project to wait for all other sub-projects to reach the same state before they can all progress to the next state, you can baseline each sub-project as it reaches its various milestones. Baselining is a technique that dates back to the earliest days of configuration management. It can be applied against source code, requirements documents, documentation artifacts, test suites, and any other collection of artifacts. The baseline must be applied to every item in the collection so that you can look at one item in isolation and be able to reconstruct the progression of baselines. However, it is often inefficient to label every single artifact – there could be many thousands of them! Therefore under the covers the system typically labels only certain important artifacts – for example project containers, or document containers – and infers the baseline history on each of the artifacts inside the collection. As always, a well-designed information architecture relies on the user interface to fill in the gaps when the architecture can’t do it all.

Baselines and checkpoints are sometimes confused with each other. Both are used to reconstruct a portion of the system at a given point in time. Both are used to indicate the starting point for new changes. I think it is better to use the term checkpoint in the sense that it is used in database systems – that is, a stable state of the entire system that could be used to label a backup, for example. From that perspective, then, we can say that a checkpoint is a baseline that applies to the entire system at a particular point in time. Checkpoints are concerned more with data integrity. Baselines are concerned more with process integrity. Checkpoints are a way to communicate to only a few stakeholders in the project – typically IT staff and configuration managers. Baseline are a way to communicate to other stakeholders in the project that a well-known milestone has been achieved for the artifacts. Thus a baseline is truly a publication mechanism – a way to publicize achievement of a milestone. It is because baselines are important to so many stakeholders that their meanings should be very clear – in fact, whenever a particular baseline is presented to a user there should always be some sort of link (hyperlink, or otherwise) to the published description of that baseline. Most people don’t use baselines often enough that they will memorize this list – and besides, as your process capabilities improve the meanings will change constantly.

It’s interesting to note that processes change just like artifacts change – just a lot less often and when they do the impact is much greater. Even processes themselves can be baselined. If you belong to a large organization having many units at various levels of process maturity, it is a good idea to map out the progression of capabilities found in your organization and checkpoint particularly recognizable maturity levels. If each group is assigned to a particular process state then you may find it easier to transfer personnel around – transferring between groups at the same maturity level should allow for the easiest transition. Also, if you have certain centers of excellence – groups that have achieved high maturity levels – you can carefully institute a plan to disseminate good practices to groups with lower levels of maturity. One such plan might be to select leaders from groups at lower process levels, and have them work for a time in groups at higher maturity levels. Then when they return to their old groups they can bring ideas and tools that will help their group climb up to the next level.

Process maturity is a very big field these days, and there are a few models that claim to be standards in the field. Big companies tend to be higher on the process maturity index, though this is by no means a uniform rule. The bigger companies regard process maturity as a competitive advantage. It’s a way to prevent small companies from breaking into the highly lucrative markets where price is less of a factor than quality.