I’ve recently been reading Standards Australia’s publication HB280-2006: "How Boards and Senior Management Have Governed ICT Projects to Succeed (or Fail)"¹. Just yesterday, Pat Weaver blogged some related analysis which ultimately spurred this post.

Both sources draws similar conclusions about the need to identify the delivery aspect of a project as just one component of a larger game. Ultimately, both sources then attribute this responsibility, and thus commonality of project failure, to senior management.

I particularly like this quote from section 2.2.1 of the handbook:

The case studies provide quite strong evidence, that in general, ICT projects deliver benefits by enabling process change, and project management, user support and all the other traditional prescriptions are less important than senior management support. Only senior management can resolve the political issues that arise as a result of conflicts in objectives caused by change.

Within the software development community, we almost always view software projects as changes themselves rather than simply an enabler in a wider organisational change program. While we talk about needing product owners from the business to elicit requirements and resolve implementation questions, we don’t look to them to act as a change champion in anywhere nearly as structured a way.

Food for thought: Perhaps we need to move towards reducing the number of people tasked with gathering requirements (business analysts and subject matter experts) to make way for some people to be actively pushing change back on the business? Both Pat’s post and the handbook talk about this as the responsibility of senior management, however I think they can reasonably be assisted in a structured way, similar to how we employee business analysts rather than expecting the project champion to understand and document all of the requirements.

Certainly, the measure of overall project success needs to shift away from on-time/budget/scope delivery towards an assessment of organisational change and benefit realisation. This is a core principle to any form of Lean-based delivery, however is yet to make it’s way into the world of organisations still addicted to Waterfall-derived delivery models, or in most cases, even Scrum.

Finally, it is encouraging to note that I came across Pat’s post via a discussion thread in the Australian Institute of Company Directors LinkedIn group. This is a group very heavily comprised of senior managers, and consequently a great place to see these questions being raised.

---

¹ Warning: The publication mechanism for this handbook is positively horrible. After handing over AU$114.27 for a legitimate license, you receive it as a rights-stripped PDF, that requires a third-party DRM plugin for Adobe Reader, which only lets you open it on one computer ever, only lets you launch the print dialog once ever, prevents you from highlighting even a single word, and prevents the accessibility functions from working (in breach of the Australian Disability and Discrimination Act). To top it all off, they still feel the need to print your full license details down the side of every single page. You’ll need to be downright persistent to even make it past page 1 as a legitimate user, which is sad considering it’s otherwise interesting content.

I’ve just finished reading Atul Gawande’s somewhat self-assuredly titled The Checklist Manifesto: How to Get Things Right. Trepidatious about reading an entire book dedicated to the unassuming concept of checklists, it had slipped in my reading queue. The result was however a pleasantly educational and entertaining surprise – he’s a good writer, with an extensive repertoire of experience. There’s even three hours of flight time left for me to knock this post out.

The foundation is simple: we’ve entered an era that’s encumbered by our ability to apply knowledge (ineptitude), as opposed to lacking it in the first place (ignorance).

Half a century ago, heart attack treatment was non-existent; patients would be given morphine for the pain, some oxygen, then sent home as, what Atul describes, “a cardiac cripple”. In contrast, responders are now faced with a wide gamut of therapies and the new challenge of implementing the right one in each scenario. When they fail, beyond the obvious downsides, blame is frequently attributed to the professional who ‘failed’ to apply a body of knowledge they have been given. As this becomes an unachievable task, we need to adopt better solutions.

Without detracting from the value of investing a few hours to read the book yourself, I wanted to tease out a few of the points I found interesting. If you find these even vaguely interesting, I really do suggest that you grab a copy.

An Emphasis on Process

Atul cites that the master builder approach to construction has been replaced with specialized roles to such a degree that we really need to call them super-specializations. It started with dividing the architects from the builders, then splitting off the engineers, and so and so forth. As a surgeon, he jokes that in the medical world he’s expecting to start seeing left-ear surgeons and right-ear surgeons, and has to keep checking that this isn’t already the case whenever somebody mentions the idea.

In the advent of this, certification processes have also evolved. Where a building inspector may have historically re-run critical calculations themselves, modern building projects involve too many distinct engineering disciplines, drawing on too many bodies of knowledge, for this to be practical. We could build a team of specialized inspectors, except this rapidly becomes unwieldy itself. Instead, building inspectors have taken to focusing on ensuring that due process has been followed. Has a particular assessment been completed by the relevant parties? Did it have the appropriate information going in? Did it produce a satisfactory outcome? Great, move on.

An almost identical construct exists in Australian employment law. It doesn’t matter if somebody is completely incompetent (or inept?); you still have to follow due process in order to disengage them. Employment courts, despite already being a form of specialization themselves, are not interested in or capable of assessing an employee’s performance. They are however capable of asserting that the correct steps were followed in issuing warnings, conducting performance management, and so forth.

Here was my first face-palm moment: I’d made the mistake of considering a checklist as a list, with checkboxes. There’s a whole set of gate, check and review processes which I’ve always mentally separated from the concept of checklists. Beyond the semantics, I found this to be a valuable light bulb moment when considering some of the other ideas.

Communication

Atul’s passion for checklists comes from leading the World Health Organisation’s Safe Surgery Saves Lives program. In trying to solve the general problem of ‘how do we make surgery safer?’, the program ended up rolling out a 19-point check list, with amazing results. It’s no small feat to cause behavioural change across literally thousands of hospitals around the world.

There were actually two behavioural changes required. First, they had to get people to actually adopt the checklists as a useful contributor to the surgical process. They had to be short, add demonstrable value, and so forth.

The second challenge was getting people to talk to each other. Some of the statistics he quotes about the number of people involved in the surgical environment are amazing. One Boston clinic employs “some six hundred doctors and a thousand other health professionals covering fifty-nine specialties.” The result of this is that operating teams have rarely worked together prior to any particular case. Having clear specialities makes it functional to have an unacquainted collection of professionals achieve an outcome, however it doesn’t facilitate an environment of team work when something goes awry. Instead, these autonomous professionals become focussed-in on achieving their individual goals.

To combat this, one of the checklist points is actually as simple as making sure everyone in the room knows everyone’s name and role before the surgery begins.

Fly the Airplane

Some Cessna emergency checklists have an obvious first step: fly the airplane. While we wait for evolution to catch-up, our brains are still wired for a burst of physical exertion to combat panic. Otherwise common mental processes go by the way side and we do something stupid.

I like the simplicity of this point, and see it being useful in a operations environment.

Pause Points

In early trials of their new safe surgery checklist, participants found it unclear about who was meant to be completing the list and when. A similar problem plagues most development ‘done criteria’ I’ve worked with. Yes, everything is meant to be checked off eventually, but when?

Airline checklists instead occur at distinct pause points. Before starting the engines. Before taxiing. Before takeoff. In each of these scenarios, there’s a clear pause to execute the checklist. The list is kept short (less than a minute) and relevant to that particular pause point.

The next time I work on defining a done criteria, I think I’ll try and split it into distinct lists. These points must be completed before you push the code. These points must be completed before the task is closed.

“Cleared for Takeoff”

Surgical environments have a clear pecking order that starts with the surgeon. Major challenges of the safe surgery campaign were getting everyone to apply the process as a team, and ensuring individual members of the team were empowered enough to call a halt if something was about to be done incorrectly. To achieve this, nurses had to be empowered to stop a surgeon.

In one hospital, a series of metal covers were designed for the scalpels. These were engraved with “Cleared for Takeoff”. The scalpel couldn’t be handed over for an incision until the cover was removed, and that didn’t happen until the checklist was completed. This changed the conversation to again be about the process (‘we haven’t completed the checklist yet’) instead of individual actions (‘you missed a step’).

I think points like this are small but important. And definitely interesting.

—

Now, go and read the book.

The book is an extension of a 2007 article by Atul, published in The New Yorker. I haven’t read the article, but some Amazon reviews suggest it covers the same concepts with less text. Most of the book is just stories, but I found them all interesting nonetheless.

I’ve been involving in some tracing work today where we wanted to make sure each request had a correlation id.

Rather than inventing our own number, I wanted to use the request id that IIS already uses internally. This allows us to correlate across even more log files.

Here’s the totally unintuitive code that you need to use to retrieve this value:

var serviceProvider = (IServiceProvider)HttpContext.Current;
var workerRequest = (HttpWorkerRequest)provider.GetService(typeof(HttpWorkerRequest));
var traceId = workerRequest.RequestTraceIdentifier;

(A major motivator for this post was to save me having to trawl back to my sent emails from 2009 the next time I need this code.)

Update 28th Feb 2013: Some people have been seeing Guid.Empty when querying this property. The trace identifier is only available if IIS’s ETW mechanism is enabled. See http://www.iis.net/configreference/system.webserver/httptracing for details on how to enable IIS tracing. Thanks to Levi Broderick from the ASP.NET team for adding this.

Lately, my business partner and I have wanted to try some shorter ‘build days’. The idea of these are to start with a blank canvas and an idea, then deliver a working product by the end of the day. This is a very different approach to the months of effort that we generally invest to launch something.

Today we undertook our first build day and delivered Give Us A Minute, an iPad-targeted web app for managing wait lists:

It was a fun experience trying to achieve everything required in one day, but I think we did pretty well. We managed everything from domain name registration to deployment in just under 9 hours. One of the biggest unplanned tasks was actually building the website to advertise the app; we hadn’t even thought of factoring that in when we started the day. The photography also took up a bit of time, but we needed to do it to tell the story properly on the site. Also, it was nice to be required to go and find a beer garden with a tax-deductible beer each so we could get that bottom-left photo.

As part of staying focussed on the idea of a minimum viable product we dropped the idea of accounts very early on. At some point we’ll have to start charging for the text messages, but that then implies logins, registration, forgotten passwords, account balances and a whole host of other infrastructure pieces. In the mean time we’ll just absorb the cost of message delivery. If it starts to become prohibitive, it’ll be a pretty high quality problem to have.

The next step is to get this out on the road and into some businesses. We’ll start by approaching some businesses directly so we can be part of the on-boarding experience. Based on how that goes, we’ll start scaling out our marketing efforts.

We also need to get ourselves listed in the Apple App Store for the sake of discoverability. The ‘app’ is already designed with PhoneGap in mind, but we’re waiting on our Apple Developer enrolment to come through before we can finalise all of this.

http://l.tath.am/cssquiz-5