Delivery by Crisis – taking pragmatism to extremes

Risk management conditions us to feel it’s vital to be cautious. We must plan properly, test thoroughly, document clearly and deliver with control. And these are principles that have stood innumerous projects in good stead.

But could there be another way?

Is there a devil’s advocate that appears in the form of a service crippling crisis?

When the lights go out a dust-covered candle stub shines as a bright beacon…

Because when nothing is working, you have nothing to loose!

I have witnessed occasions when technical solutions have been crash-delivered before they were properly ready in order to fix operational issues, when it has been worth cutting corners and dealing afterwards with the minimal amount of clean-up required. These urgencies have actually been to to mutual benefit – saving the project’s time and the operational team’s bacon

Did we forget to put our #1 deliverables in the plan?

Planning a project is a opportunity to look forward to what we expect to deliver, working out the list of activities that move us from where we are to where we want to be, and marking the major stages of achievement along the way.

Think for a moment about a very simple model of what we are working towards. In order to implement process A, we need delivery framework B to connect system C to information source D, then we provide training E to customers F. Doesn’t that sum it up in a nutshell?

But hang on, how come we are even doing this in the first place? What was it that justified our very existence as a project? Well, chances are that someone pitched a business case to some executive sponsors and showed how a short term investment would bring long term benefits, either by increasing revenues, or as so often with major operations by reducing costs.

Do alpha releases deliver value? Maybe more than you think!

When you’re planning a project or designing products, you know that you don’t need to produce any early mockups because you, and possibly many of the team, can see the vision already. You don’t need to see anything tangible before it’s due because you believe in what it is going to look like, way before you can hold it in your hands. Seeing as you’ve got so much ground to cover before then, its not worth delivering a symbolic item so early.

However, not everyone shares this same vision so clearly, and there can be so many advantages to producing and making available early beta and even alpha versions because tangible articles, even if they’re a long way from the final embodiment of perfection, are sometimes the best way to avoid very common obstacles.

Here are four that spring to mind immediately…

Technical governance entities

I was happy to read a Rich Maltzman post on the “lifecycle of assumptions” (Scope crêpe: The biology of assumptions). Its reassuring to see that others place similar importance in tracking such potential bumps in the road, and realise that they can morph from one from into another.

I began some work a few months back into defining what I called Technical Governance. The classic entities used in project governance are known as “RAID”,  for Risks, Assumptions, Issues and Decisions. Two of the simple lifecycle stages I identified were that

• Issue =  circumstance that requires an Action that is not yet in the plan
• Risk = Issue that has not yet matured (or might not at all)
• Assumption = unvalidated fact that potentially leads to a risk

Although this was becoming promising, my focus was pulled away before I could complete the circle with with some earlier work on Requirements. Working on technological projects requirements are not just an important tool, they are fundamental. In the past I have had to widen the consideration of what constitutes a Requirement:

• Goal – top level requirement that guides choices in downlevel requirements and design
• Benefit – implication that a requirement will deliver a service improvement or cost reduction
• Standard – requirement implied by someone who is not a direct stakeholder
• Constraint – negative requirement (“must not” or “won’t”)
• Dependency – an outgoing requirement, where something is needed from someone else
• Assumption – made in lieu of a requirement

Here you can see Assumptions in another guise, where they are stated for clarity and audit traceability – better to have an assumption stated in the workings rather than hidden in someone’s head, where it can become really dangerous. Remember that with all of these entities it is important that all stakeholders can see them if they are interested – awareness is the first step to resolution.

I note that Rich describes an Assumption maturing into into a Risk as either as a Threat that something will get worse or as an Opportunity that things will improve. I’ll have to make sure I carry forward this idea that Risks can be positive as well as negative, because it is always so common to focus only on the potential for disaster – not what you need when your trying to make serious progress.

Another link between RAID and requirements is a Decision – if its a choice
made during design, it may lead to fresh constraints and dependencies.

As you can see there are plenty of ways in which you can get value from observing and understanding the behaviour of these various entities, to watch their lifecycles and the way they interact. I believe that Ethology can help Technology, but I have yet to convince my project manager that a day at the zoo will help us meet our milestones.

A project blogger’s secret power comes from his impotence

I’ve heard discussions about why collaboration platforms and social media can help on projects, but some people are somewhat sceptical about blogging on projects. However, I would like to demonstrate how even on a busy project a blog can be a poweful means of communication.

I’m sure you’ve been there yourself, when your email inbox gets snowed under. When it turns into a mountain of issues lurking, waiting for the moment when a single loud bang can cause an avalanche of responsibility wars. How can any EXTRA incoming communication possibly be a good thing?

Well, think about the nature of items in your inbox. When the going gets tough, mails turn into gotchas-in-waiting, as they are easy to misread when you skim hundreds of messages a day. Some mails are magnets that make you inadvertantly pick up actions, others snare you into unwitting sign-off, and others tick silently like timebombs that will be trumpeted later as evidence of passive malpractice on your part.

In this tidal wave of potential traps, what could be more welcome than a new message which no-one will expect you to act upon, which you will not be berated for not fully digesting, which in fact its not at all in your jobspec to even bother opening. The mere fact that you “can safely ignore it”, makes it a more welcoming read. Not only will it not put more furrows in your brow, nor increase the statistical likelihood of any follicle producing you a grey hair – it may actually stimulate you to think about something refreshingly unpressing, in a positive and supportive way.

Reading blog articles is specifically anti-pressure, because you CHOOSE to do it. When everybody around you is crumbling under the oppressive regime of their mailboxes, what more powerful way have you to communicate than something which will be read and seriously considered, simply because people have the right to ignore it completely, if they want.

Complex designs come unstuck on the simple things

I used to think that the most difficult part of creating a complex infrastructure design was fretting over the important technical choices that would affect the configuration of deliverables. Once those were sorted then I could get on with listing the order in which elements needed to be implemented, and producing a list of all the technological resources needed to implement them.

Over time I’ve come to realise that this is actually the wrong way round. Often design choices are the easiest stage, partly because many infrastructure components work best when following vendors’ best-practice configuration guidelines (or even just set up as they come out of the box). Also, because most configuration is soft, its easy to make such choices at the last minute and still deliver it right and on time. The more important elements to get right up front, however, are those that require the time and the money, also known as dependencies and resources.

Releasing the nightmares

So once you finally get the green light for your programme, you begin to let loose the dogs (that had been snarling and growling in early design stages) and you suddenly find that you’re in a project versus operations, us-against-them situation.

What you need to grease the wheels is a decent bit of Release Management (RM).

But what exactly is it?

Making durable decisions easy

Making decisions always seemed simple and satisfying, and easy to change to suit circumstances.

But that was back in the days when they were design decisions, and I had developed a number of tools and techniques to help me shake the pieces into place. Things like evaluating requirements, identifying options, noting constraints, and twisting and turning the results until clear winners start to emerge. And of course – number one rule – note it ALL down. You need to know how you got where – and most importantly why, because then, once you plug in the newly changed circumstances, the design could flex and easily produce new results.

But now it all seems to revolve around money – the cost of doing something versus the cost of not doing it. Early attempts to record decisions were far from perfect. Scoping the decision was not a problem – describing what we need to decide and giving weightings to the factors that would help us decide. Nor was it difficult to list out costs, benefits and risks of the different options. The biggest issue turned out to be the inter-relation between the different options – the benefits of one option were to avoid the risks of another, or the risks involved not achieving the benefits. Tedious, repetitive and confusing!

So the solution I am using for now is to assume that the benefits (positive outcomes) and risks (negative outcomes) are all “theoretically possible” across all options, marked on a scale of 0% to 100% probability of maturing. This means the difference between the options is expressed as a combination of negative versus positive probabilities. I have stopped short of allotting a price to the benefit or risk, because these are so often subjective – in the eye of the beholder. Still, seeing the balance of plus and minus percentages should help people do their own calculations from their point of view. After all, many would-be decision-makers work from preconceptions, and massage the statistics to make the formula give the result they want, so no point in putting them through the unnecessary effort, is there?

In some ways commercial decisions are less complex than technology design, because there are fewer dimensions to consider. Money, however, can cause rather emotive reactions in people, and hard cash can boil things down to black and white results that might not have been obvious when you first asked a technological question.

Potholes in your CMDB roadmap

Implementing a Configuration Management DataBase (CMDB) is not a single action, but a gradual process that may take months or years to establish. Even after that, it is subject to change and improve like any area of your IT operations, especially as your business changes around you.

In many organisations there can be similar pitfalls when tying to create an effective CMDB, and the best way to avoid them is to be aware of them, and plan around them. Here are my top three:

1) Ownership and dispersed authority – the information that must be captured and held within a CMDB typically extends into the domains of many teams. Although one of these teams has overall responsibility for the “whole”, there are people in other teams who truly hold the knowledge and are aware when fundamentals change – it can be difficult to pin the responsibility on those other people for keeping their part of the database up to date.

2) Inequality of investment and return – by its nature, a CMDB is unfair to its various clients. The people who get the most out of the system do not have to put much effort in. Yet the people who have to spend most time putting the information in are rarely interested in getting anything out of it.

3) The value is in relationships, not data – many people see “automatic data feeds” as the nirvana for maintaining a good CMDB. Yes, it’s true that you can get rafts of detailed configuration information automatically imported in the blink of an LED, but that is only half the story. What SMS, Insight Manager and CiscoWorks can’t give you on a drip-feed is the richer knowledge about how systems interconnect and inter-depend. That’s stuff that IT folks typically carry around in their heads (or store on complex and un-referenced Visio diagrams that are never collated into a single repository). These system relationships are what let you analyse your ability to resist points of failure, to predict the likely impact of planned change, and to ensure that you really understand exactly how your customers make money using the iron you manage. If you manage Change, Configuration and Release, you are at the best point to keep track of such interdependencies over time, but don’t expect the machines to do all the hard work for you just yet.

What can I do to manage these risks?

Whether managing the technical detail of a project, or the overall project details that might affect scope, budget, timescales, or quality, you often come across risks. Typical attributes you log about risks include: what’s the Probability it will mature, and what Impact would it have, and which area it Affects.  Great, but what can you do about these risks.

Here are the four broad categories of action you can take to manage risk:

Accept – brace yourself for the possibility that you will feel the impact (e.g. warn people what might happen)

Control – modify the action plan to reduce the impact or the probability (e.g. do it at night or test it better first)

Avoid – don’t go ahead with the action that could incur the risk (e.g. shelve that part of the plan)

Transfer – arrange that someone else feels the impact (e.g. sign an insurance agreement or a service delivery contract)

The most common actions are Control (we mitigate risk by reducing the probability or limiting the impact) or to simple Accept what is going to happen. In any case, I find it practical to have this list of the types of action, to avoid keep (mis-)using the word mitigate.

If you want to read a little more around the subject, you’ll find the Wikipedia Risk Management article a useful starting point.