Project Management

Empowerment and accountability on programmes Last updated:5 December 2009

I was thinking last week about empowerment and accountability within a programme structure.

If a programme is going to deliver something of value to a business, the programme manager or director needs to be accountable to the rest of the business – fine. But the business also needs to give the programme the space and resources and trust to deliver. Critically, once the programme structure and responsibilities are agreed, the business needs to step back and let the programme get on with it.

If the programme is delivering into an existing business structure – and most do, of course – the business is going to need to be kept informed of what’s going on (quite apart from any implementation management activities). There’s a danger, however, that the business switches into “can’t let go” mode, and micro-manages, effectively disenfranchising the programme. This is a slippery slope. If this happens the lines of reporting and control get confused, with clear control and accountability for decisions being lost, with project managers, for example, reporting to many masters.

I’m not for one minute trying to say that the programme should ignore the business. Far from it. A lot of IT problems go wrong because business and IT are not linked hand-in-hand. I think this is best enabled by embedding business people within a programme or project, and empowering them to represent the business within that structure. These people are accountable to the project for agreeing requirements etc, and also accountable to the business for representing it accurately. The business needs to trust (there’s that word again) these people and, again, let them get on with it.

So, give the programme accountability, empower it, and then give it enough space to do what it’s there for.

Just start it… Last updated:5 December 2009

Sometimes the best thing to do with a project task is to start it…

Sounds a daft thing to say, but there’s sometimes a danger of over-planning and over-analysing a task, instead of actually getting on and doing it.

I can think of two personal examples. A few years ago I was managing a complex set of interfaces between two systems. One of our suppliers was reluctant to sit down and talk about it because they wanted more preparation. However, we gained more from a rough and ready two hour meeting with everyone round the table than we would have done from a couple of weeks planning. The supplier was generous enough to agree this as well.

My other example concerns a web tool which had been discussed for a long time at high level, to the extent that everyone thought it was a difficult task. Again in a couple of hours, by talking about some detail and the sort of data we wanted to display, we were able to take a big step towards understanding what we were trying to do, and realise it wasn’t quite as hard as we thought.

Sometimes you just need to start talking about something – it’s pretty certain that talking discussing some detail will focus thoughts and help get a clearer idea of what it is you’re trying to do.

Here’s a great quote on the subject:

“Whatever you can do or dream you can, begin it.
Boldness has genius, power and magic in it.”

Aside: This quote is generally, but incorrectly attributed to Goethe, but in fact was introduced as part of a “very free translation” from Faust by John Anster in 1835. Now you know…

Relations with suppliers Last updated:2 April 2009

Some little time ago I came across a job ad looking for a project manager (and I quote) “to bludgeon the supplier into submission”. I’m not quite sure whether the agency thought that this was a good way to attract high class candidates, or what. The sad thing is I suspect it wasn’t a joke.

Subsequent reflection on this got me thinking about really productive working relationships I have had with different suppliers. One common characteristic of these successful relationships has been the old fashioned virtue of trust. However, I’ve never trusted the supplier. I have trusted the people who work for the supplier. I’ve trusted them to bring their specific expertise to the project and I’ve trusted them when they’ve told me that things are impossible, and I’ve trusted their judgement when we’ve discussed problems. I flatter myself that, again in the most productive relationships, the trust has been mutual. The supplier project manager has trusted me to manage things at my end, believed me when I said some elements are essential however difficult they might be, and so on. These have been relationships of equals, not assailant and victim. There has been a remarkably small amount of bludgeoning.

So how did I get to this position of trust? I had been conscious for quite a while, having worked with suppliers on many different projects, that the situations which I felt to be most useful were face to face meetings with people. No big suprise there. But actually I realised it was a bit more specific than that – in many cases the most productive discussions were actually the informal ones. The circumstances varied from sitting next to a developer and chatting about an issue, talking with a supplier project manager over lunch during a more formal meeting, even chatting to potential suppliers during a coffee break during a tender presentation. My experience of projects is that it’s usually a few people who are in tune with each other who are critical to the success of a project. And it’s the informal contact that builds this set of people who are in sync, and who trust each other, just as much as the formal contact. None of this is to say you don’t need formal meetings – of course you do. But don’t neglect the opportunity to build the relationship through the informal contact.

I am not normally one for reading learned articles on project methodologies – but there’s one I came across called “Characterizing people as non-linear, first-order components in software development” written by US methodology guru Alistair Cockburn in 1999. Normally the title of this alone would have been enough to put me off, but in fact the more I read, the more I found myself in tune with its substance. Cockburn notes that a commonly quoted factor in successful projects is that “a few good people stepped in at key moments and did whatever was needed to get the job done”. Additionally, he concludes that the most effective way to communicate is to have two people standing at a whiteboard, and that the further you get away from this situation the less effective the communication. He doesn’t make this specific distinction, but this implies to me an informal meeting rather than a formal presentation.

The relationship with your supplier becomes more important when problems occur – and things always go wrong during projects. Coming back to the start of this article, bludgeoning the supplier into submission isn’t very likely to help. I’ve never seen a project fixed by people shouting – and I’ve seen a fair amount of shouting. I’ve seen projects fixed by sitting down and talking about them. I’ve seen projects not fixed by either approach. I’ve certainly seen shouting make suppliers less co-operative. In my experience, sitting down and talking calmly about the problem is usually the best approach, and certainly the one adopted by all the most impressive project managers I’ve worked with. The better your relationship with the supplier, the easier this sort of meeting is likely to be, another benefit of getting to know the people you’re dealing with better.

Looking at this from the point of view of less successful relationships I have had, they support the same conclusion. In a few cases I have not had what I’d call positive relations with suppliers. These have pretty much coincided with situations where I haven’t been able to establish good relations at a person to person level – either because of geographical separation, or in some cases, cultural differences.

In conclusion, remembering that the people you are dealing with are just that, people, and taking every opportunity to build relationships with those people, is a significant success factor in projects. The fringe benefit, of course, is that it might actually make the project more enjoyable as well as more productive.