Is Your IT Project Using The Proper Coolant?

 

The Agile/Scrum Project Management strategies and techniques were developed to address the business model needs specific to information technology (IT) projects, specifically software engineering work. The major driver, of course, had to do with configuration management. Traditional PM techniques for processing baseline changes typically entailed the creation of a Baseline Change Control Board that would meet once per month, and review the baseline change requests’/proposals’ (BCR/BCP) scope variations, along with the accompanying modifications to cost and schedule. One of three outcomes would be produced: the BCR/BCP would be accepted and implemented, rejected, or sent back to its originators with instructions on how it should be modified in order to gain acceptance. If either of the latter two outcomes were to happen to a critically-needed change to the project, the resolution to the subject BCP/BCR could potentially drag on for months, a time interval fatal to all but the most drawn-out of IT projects.

To accommodate the far more fluid and fast-moving IT project configuration management process, three “roles” are defined, specifically:

• Scrum Master,
• Product Owner,
• Development Team,

…with their specific functions and areas of authority spelled out in such a way as to allow for processing baseline changes quickly and efficiently, all while avoiding the outcome of a poor or non-existent configuration management process, the dreaded rubber baseline. There is, however, another aspect of IT Project Management that is also very different from its product or building-oriented cousin, and it has to do with the nature of the Work Breakdown Structure. To make this distinction, I want to propose a mental exercise that includes a water pump, the kind that’s installed on automobiles (well, the ones that burn fuel).

For those of us who haven’t had the experience of having to replace one of these things ourselves, the part is really very simple. It’s usually an impellor and a pully wheel on a shaft, with a housing and a pair of hose flanges in-between. They typically fail when the bearings that hold the shaft in-place wear down, and the pump assembly is no longer water-tight. When it’s working correctly, it pulls coolant from the heat exchanger (the radiator) and pushes it into the engine. From the engine, the coolant returns to the radiator, and the process continues as long as the engine is running. In fact, it’s a little amusing that the pump is still referred to as a “water pump.” These things haven’t been circulating just water for decades now. Indeed, some car manufacturers used to require a very specific coolant formulation (e.g., GM® and “Dexcool”) to avoid damaging the motor.

Meanwhile, Back In The IT Project Management World…

The focus of most IT projects is its eventual end-goal, a computer program. Veteran GTIM Nation members know of my basic Management Information System (MIS) architecture scheme:

1. The data is collected based on some criteria or discipline,
2. it is processed into information,
3. and transmitted to its intended audience in a manner that they can readily understand and use.

The end-product of manufacturing a water pump is, of course, an in-spec water pump. But data is different. An in-spec water pump for, say, a 1998 Cadillac Deville will be an in-spec water pump for its lifetime. For IT projects, though, one of Hatfield’s Incontrovertible Rules of Management (I forget its number) is that all valid management information must have the following characteristics:

• It must be accurate,
• It must be timely, and
• It must be relevant.

Old data can, and usually does, become irrelevant. Depending on the MIS application, this exceeding of the data’s shelf life can be measured in weeks, or days – or, sometimes, just hours. So, in addition to the configuration management challenges inherent in IT work, there’s also the issue that, even when the software’s function is performing exactly as intended, as time goes by the output is not only losing relevance, it may even be becoming misleading. It’s analogous to putting the wrong formula of coolant into your radiator. The water pump may be working perfectly, but what it’s pushing along is actually damaging to your business engine.

All of which brings us back to the WBS problem I referenced earlier. If the intended outcome of the IT project is delivering valid information to decision-makers, then we’re firmly in PM space. However, if the intended outcome is to simply pump coolant between engine components process the data into information, with the actual cooling of the engine validity of that information no longer part of the final scope, we have ventured into process management space, which is very different. Without some capability to ensure that the collected data is accurate, timely, and relevant, the best processors and programs in the world are going to fail to deliver pertinent information. It would be like putting green coolant into a radiator that’s only supposed to have orange.

And that would be bad.