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 🙂

Read the rest of this entry »

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. Read the rest of this entry »

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… Read the rest of this entry »

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.

Read the rest of this entry »

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?
Read the rest of this entry »