Project Management

Relations with suppliers Last updated:5 October 2011

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. And that’s got be a good thing.

Laws of CRM and telephony projects Last updated:30 September 2011

Simon’s first law – Comms rooms

One or more of the following will apply

  • There will be no room in the comms room for the new server. Resolving this will necessitate anything up to and including an extension to the building.
  • There will be insufficient power supplies
  • There will be no spare ethernet ports

Note that these rules apply regardless of how recently a comms room has been built.

Simon’s second law – Address formats

No matter how unlikely it seems at the outset, there will be an intense discussion about addresses at some point, normally involving postcodes. This may well extend beyond intense, into heated.

Simon’s third law – head scratching

At some point more than three people will be observered clustered around the same screen with slightly vexed expressions on their faces.

Simon’s fourth law – telephony testing

You will, at some point, have your desk phone to one ear, and your mobile to the other ear, talking to yourself. It’s inevitable. Don’t fight it.

Simon’s theorem on development gurus

In normal circumstances, on any given development project, there’s someone who can fix anything. It may take you a while to work out who he/she is, and even longer to get his time. Slightly more than half of these people are called Dave.

Corollary to the theorem

If no such person exists, you’re in trouble.

Project management documentation Last updated:29 October 2010

A couple of weeks ago I ended up talking for a few minutes about project management and what it isn’t, and thought I’d post it here as well.

Lots of files

There’s a strange sort of mystique about project management and what it involves. Clearly project management is about getting your documentation right – plans, risk registers, PIDs, issue logs , change requests, progress reports. No.  Most of the really good project managers I’ve had the privilege to work with have used these things. But all of the project managers I would judge as less successful have used these as well. There is an unfortunate tendency to mistake intense activity completing all these things for actually getting something done.

I can illustrate this with a personal example. Way back before I was a project manager I was on the receiving end of a project, as it were, when I used to manage a call centre. Every Friday I – and five colleagues doing the same job elsewhere – had to complete a document reporting progress and risks and issues. I used to complete the form religiously. Far more religiously than my colleagues, it turned out, since I was publicly congratulated for doing such a good job. All well and good. The problem was that I was making a right hash of actually completing the project…..

In recent years one of the least successful programmes I’ve worked on used the most documentation and adhered most rigidly to project management standards. It passed two heavyweight QMS audits without any major problems. And yet, ultimately, this particular programme failed. Another instance that sticks in my mind, on a different programme, was the use of very detailed documents to specify the interface between two different systems. Everything you could possibly need to know about this interface was contained in a single document. Great, eh? No. Our supplier had a highly intelligent lead programmer working for them who really operated on a higher intellectual plane than the rest of us. He was heavily involved in all the discussion about these interfaces, but even he couldn’t understand the resulting document – it was too complicated. And if he didn’t understand it, what hope did the rest of us have?

At the other end of the documentation spectrum I’ve also seen a project deliver an application to 6,000 people pretty successfully, which never had a risk register or an issue register. (Actually, it did have one right at the end of the project because it got audited, and one was “found”, ahem, but that doesn’t really count.)

So don’t be fooled into thinking that project management is just about filling in documents. The difference between good and bad projects isn’t documentation and all the hideous apparatus of the project management textbooks. It’s the people working on the project.

We all know this anyway, because good people in any sort of work make things variously easier, quicker, cheaper, and even, perhaps, more fun. It’s no different on projects. Good project managers find it helpful to use risk registers etc to help them organise a project. The key word here is help though.

Risk registers and project plans are not an acceptable substitute for sensible project management.

Just start it… Last updated:29 October 2010

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…

Empowerment and accountability on programmes Last updated:29 October 2010

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 happen because business and IT are not linked hand-in-hand. I think this risk 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.