Archive

Archive for June, 2010

Notes from a Post-Implementation Review

June 28, 2010 Leave a comment

One good practice in software development that is noted more often for its breach than its observance is a formal Lessons Learned review at the end of a project. Recently I took part one for a major project in which I had played a key role, which was only the second time (in over 15 years) that I have been involved in such an exercise. It is likely that others with a development background like mine will have attended these as infrequently as me; here are a few thoughts about how the exercise was conducted.

It was taken seriously. The bulk of a day was set aside well in advance, and a detailed agenda was circulated to all interested parties. This was important as I was able to collate the thoughts of my senior colleagues to present to the meeting. They were happy to supply me with comprehensive and refreshingly honest (!) feedback to pass on.

The agenda divided into two parts. For the first session we discussed what went well and what didn’t during each stage of the project from initiation to handover (15 were identified in all). The second session used a formal Lessons Learned template to feed back the consensus of the project on a number of standard statements. On the whole the free discussion of each stage was more revealing and generated more useful feedback.

The organiser had taken care (a lesson learned from a previous review, perhaps?) to appoint one person to act as timekeeper and take notes. We didn’t always keep strictly to the agenda as it often made sense to address related issues out of order, but the timekeeper was good at assessing where we were starting to let time drift and force us to wrap up discussion. In the end, we completed our discussions early as the later agenda items all went quite well and didn’t require much discussion.

I felt we ran through the agenda too quickly, as we had to cut short a lot of worthwhile discussion. On the other hand the meeting was long enough already. There hadn’t been any other reviews at key points in the project (at least, not in my time) and given that the project had run for 4 years, it would have made sense to have held reviews for earlier stages nearer to the time, when the right people were available. Then the scope would have been more manageable.

All main groups were invited; most were represented. Importantly, the business stakeholder and key business user represented had both been involved throughout so we had continuity. A QA auditor was present, who had not been personally involved, to ask searching questions from a neutral standpoint. It was interesting that the groups who had contributed disproportionately to the things that didn’t go so well chose not to attend.

The best thing about this review was that it was carried out in a good spirit. There was no confrontation or finger-pointing. A genuine attempt was made to highlight both the good and the bad. As a supplier (and the only external person present for much of the meeting) I was considered to be part of “the team” and treated like anyone else.

I wonder whether the impetus to hold this meeting was partly because the project was successful – it achieved its ultimate goal on time (just) and within budget, the only one of a dozen or so major projects running during the same period to do so. Would the meeting have been so positive if we had failed? What were the other reviews like, I wonder? Did they even happen?

The output of the meeting was complied into a comprehensive report. I’m unlikely to be in a position to judge whether any long term benefit accrues. Even if the more strategic lessons are dodged by senior management, at least we recorded some of the lower level lessons that are within the power of a project team to influence.

My own view having taken part is that it was well worth my time, and I wish it happened more often. Several of those present are continuing to work together in a follow-on project, and can take some of the lessons learned to improve things going forwards.

World Cup Fever

June 18, 2010 Leave a comment

Flags

My part of London has come out in a rash of flags flying from cars and houses as people display the Cross of St George to show their support for the England football team.  More central areas reveal their more cosmopolitan nature by a colourful smattering of other flags too.

Inconveniently, the final group match is scheduled for next Wednesday at 3PM.  Several of my team are avid football fans and naturally want to watch the game as it happens even though it falls during normal work hours.  So, what should we do?

(Declaration of self-interest – I’d like to watch the game). 

Work or Watch?

One school of thought is that we are paid to be at work during normal office hours, whatever might be happening in the rest of the world outside at the same time.  If our contract says we should work from 9:00 to 5:30, then our professional response must be to do just that, without complaint.  After all, we agreed to those terms when we signed our contracts. 

The down side of this is that inevitably the match will be a distraction.  Some people will simply listen via earphones or check the internet every 5 minutes anyway, and you can be sure if there is a goal we’ll all find out about it pretty quickly and will sit around discussing it.  Undoubtedly some will resent not being allowed to watch the game, however unjustified that might be.  Either way, most people will probably not have their two most productive hours of the week.

The opposite view is that we are paid for what we produce, not for being in attendance.  Often we can do much of our work just as easily at any time of the day.  It is better for team morale to treat everyone like adults, and allow them to make up for lost time by starting early or working late another day. Football haters may not want to join in so this must be optional, and in fact they will benefit too, by having a much quieter working environment than usual. 

The down side to this that not everyone enjoys football, and others do not receive the same favour when their own pet interest coincides with work.  Others will be required to work normally due to the nature of their jobs. There is a risk of resentment among these groups if there is a perception that all are not being treated equally. 

What we will do

I believe it is much better to recognise the team’s collective desire, and plan to go and see game as a team.  This gives an opportunity to bond as a team socially, and also to show that individuals are valued and trusted.  The company often demands “flexibility” from its employees (i.e. unpaid overtime); this is a chance to give something back. 

We have a second consideration, as we are based at our client’s office, so we have to take their policy into account.  Clearly if they expect all their staff to work as normal then we have to respect that.  As it happens there is no specific guidance and it has been left to local management discretion.

So, we will be in the pub.  Come on England!

Who’s the real customer?

June 8, 2010 Leave a comment

Like many others in IT, sometimes I have worked on a project that successfully delivered what was specified, but which wasn’t what the customer actually wanted.

It’s hard enough to deliver anything at all sometimes, so when this happens it is just so frustrating. Usually it turns out that by the time the requirements reached the development team, they had become somewhat lost in translation. I am a firm believer that it is the job of all developers, however junior or technically-minded, to try to get as close as possible to the real business users, and really understand the subject matter.

But there’s more to it than that. Those of us who work for IT consultancies recognise the duopoly inside most of our immediate clients’ organisations, where we are engaged directly by their internal IT function, but in practice the end customer is in a business department, and sometimes kept at arm’s length. But often they are not the real customer served by our software, which should be helping them to serve their own customers better.

But who are the customers of that business department? How far removed are they from my project team? And what is it they want?

Over the years I have worked on several projects for the UK’s railway infrastructure owner, Network Rail, so I shall use them as an example. For one recent project, which was a billing system, at first sight the customer was obvious – the Train Operating Companies, who are charged for running trains on the network. They receive invoices backed by detailed reports showing how the charges are calculated, and their finance departments care very much about their accuracy.

(Note: In the UK since rail privatisation in the 1990s, there is a split responsibility between infrastructure ownership and train operation. Network Rail owns the tracks, main stations, power supply etc – while other companies run trains over them. A bureaucracy supports this structure to ensure everyone gets equal access, share out the costs, and attribute blame. For a fuller explanation, see the Wikipedia entry for Network Rail. Other European countries all seem to be adopting a similar model)

But what if I broaden my view, to the customers of Network Rail as a whole? How many organisations are involved before the link becomes too tenuous?

Ultimately, it is all about the customers of the trains – or passengers, as we used to be called! All we want is for trains to arrive on time and to take us quickly to our destinations. Everything Network Rail does (and therefore everything I have done for them) is aimed at running more trains, more efficiently.

But as well as passengers; we must not forget freight customers. Behind the freight Train Operator is a much longer chain of customers. Firstly there is a customer whose load is being carried, e.g. the manufacturer of construction materials being delivered to a building site. Then there is the builder receiving the delivery, who may be relying on a Just-in-Time distribution system to deliver materials as they are needed. And at a stretch we can extend it further to the sponsor of a major construction project on a tight deadline, whose deadline simply must be met (London 2012).

For intermodal freight we can add an extra link in the chain, as it may be the container operator who hired the train to carry the container on behalf of their own customer.

So how many parties is that?

IT supplier –> Network Rail IT –> Network Rail business department –> Freight Operator (e.g. GB Railfreight) –> Container Operator (e.g. P&O) –> Manufacturer in China –> Builder –> End customer. A total of eight!

And that is assumes that each organisation engages directly with the next, without adding in agencies, freight forwarders or sub-contractors. For example, my employer might not be the Prime IT supplier on a large project.

Returning to my example, the builder might require delivery by 07:30 on a Monday morning because that’s when a squadron of fitters will arrive ready to start work. It’s no good if the bathroom units needed are still sitting on containers in a siding at Felixstowe, because the train couldn’t run. This might be a very big consideration for (say) an engineering system, to minimise line closures.

I’ve used the rail industry as an example, but I’m sure similar examples could be made from most market sectors. Ultimately we must bear in mind that the person who cares most about the benefit delivered by our application may be at six or seven removes from us.

I wonder how much gets lost in each link of the chain, and how many of the end customer’s needs are lost by the time requirements reach us?

Categories: Work Tags: