As I mention in the post below we are looking at re-branding Kubernetes and re-vamping the website.  During the process we will be prototyping ideas using the current format which may make the site look a bit odd and more difficult to use.  Bear with us and watch this space……

I’ve been musing (and occasionally ranting) about the procurement process over the last few months and have finally started writing a white paper on the topic.  Some of the issues were brought into sharp relief by two conversations yesterday.

On one hand I was talking to a prospective client where he highlighted that one of the questions with DSDM is “How do you procure system development services from a 3rd party when the features / requirements of that system are either not fully understood and / or expected to change”. He then went on to highlight the issue of which party is taking what risks.

This is one of the core tenets of traditional / competitive / confrontational procurement: in theory the procuring party is transferring risk to the supplier. In reality this is not the case as the lawyers and commercial people in the supplier are typically more expert in assessing the risks and making sure that their organisation does not accept more risk than necessary. This is because they deal with the area of expertise in focus all the time, where for the customer it may be the first or infrequent purchase of its type.

I don’t yet have a complete answer for this question and I know this is something the DSDM community is looking at more generally. What we are looking for is a model for collaborative procurement; so meeting one of the key principles of DSDM. By definition, this could be seen to be the polar opposite of traditional procurement.

I then went to meet one of the people that I have asked to quote for re-branding and re-vamping the Kubernetes website. Again by its very nature the output of a branding exercise is unknown at the start, there is likely to be a known process but being definite about how long it will take and how much it will cost is difficult.

What did I do? Lapse straight back into a competitve procurement mindset! It was only on the train home I realised the hypocritical hole I had fallen into.

So today’s task is to work out how to procure my re-brand collaboratively….. or at least to accept my latent hypocrisy!

I had a very interesting conversation with Arthur op den Brouw, Creative Director of Designation about business values and how they relate to an organisation’s brand. Arthur’s key assertion is that an organisation’s values are the ones they actually take action on, rather than what they might have decided in a executive meeting.

This problem is that if the “values in use” are different to the “espoused values” then brand positioning, general marketing and even sales suffer as the customer’s experience is different to the expectations that have been set. There is a particular problem in that branding is very much about the intuitive part of the brain rather than the rational and so a customer, partner or employee that sees espoused brand values not being acted on in practice will typically have a negative emotional response; potentially destructive to the organisation.

In short, do what you say you are going to do; or at least be honest about who you really are!

Updated 15th April

I note that two BA Directors have left the company as a result of the T5 problems.  Not sure if we should conclude that the problems were mainly on the BA side but it seems that way.

2nd April

I can’t let the current controversy over Heathrow Terminal 5 go un-commented. From a project management perspective it will, I’m sure, become a very interesting case study. What the press reports in the last few days seem to have forgotten is that the construction itself was delivered on time and to budget; a genuine triumph of project management. One of the principle reasons for this seems to have been that BAA accepted all the risk on the construction project i.e. set up a collaborative rather than confrontational relationship with their sub-contractors and suppliers. This is a lesson that other major projects could learn from particularly in government.

So if the building was delivered correctly and on-time what went wrong? It looks as if the baggage systems (and by system I mean both people and technology) had not been tested with the volume it was expected to cope with. BA seemed to have decided to move nearly all its flights at once in a “big bang” implementation. As most project managers know, this is an extremely high risk approach only to be used when there is no sensible / economic alternative. The key question is did they HAVE to go “big bang” and if so why were the systems not tested properly in this scenario. This seems to be backed up by suggestions that BA was warned that not enough people had been properly trained

How it seems to me is that there was either a poorly planned, poorly executed or possibly no proper change management programme inside BA. Which it was only the insiders will know, but an organisation with a long history of poor relationships between management and staff should have realised that they needed to make a special effort with a high profile project like this. It could have provided a “clean start” for labour relations and at one point BA was hoping for this. However the bruising battles with the unions about changes in working practice for T5 seem to have spoiled the opportunity.

If is is mainly a BA failure then BAA should have learned the lessons in collaboration gained from the construction; as their reputation is being dragged through the mud alongside BA’s. This is only adding to the calls for BAA to be broken up e.g. in Jeff Randall’s article in today’s Telegraph.

I commented about the project management problems for Network Rail at Christmas. It will be very interesting to see if they do any better in delivering on time over Easter as there is a significant amount of the network out of action.

Update 25th March

Still making headlines….. “Engineering overrun causes rail travel delays”

Update 28th March 

Jeff Randall makes some useful points in the Telegraph today

It is not surprising that the government couldn’t manage the complex stakeholder requirements that I analysed a couple of weeks ago. It was one of those “no win” situations where whatever they did someone (possibly everyone) would have been been unhappy. One of those lessons that we keep re-learning about public-private partnerships is that the stakeholders have to want to work together and clearly this was not the case.

What surprises me is that people keep talking about nationalisation as being the only option left i.e. if a private sector solution won’t work then the public sector has to pick it up. What they seem to have forgot is that there is a 3rd sector, the mutual and co-ops, e.g. John Lewis and Co-op Bank, that run reasonably good businesses. This is ironic given that Northern Rock was a mutual in the first place.

By this I mean that if taxpayer’s money is being used to prop up the bank I think that it is only fair that taxpayers have a direct vote on how the business is run. This one vote per investor, irrespective of size of investment, is the hallmark of a co-op/mutual

It would be reasonable to ask how this might happen and perhaps the only way might be via nationalisation i.e. government passes legislation to nationalise, restructures it as a mutual and then issues “shares” to all UK taxpayers.

This would have the additional benefit of minimising political interference in the running of the Northern Rock (building society).

Common sense isn’t it? The people who provide the investment controlling the investment. However because it is common sense it won’t happen.

Updated 13th Feb

The presentations this morning convinced me that test driven development is the way to go at an engineering level.  Not only does it provide a way of flushing out the  detailed requirements, it minimises the risks of defects in the final product.  The only challenge is that to do it properly needs automated test tools and they seem to have finally matured with opensource products like Fitnesse competing with commercial alternatives.  It was really quite uplifting.

Updated eve 12th Feb from the conference

Interesting day in a number of ways, not least of which was UNICOM’s laptop deciding to hibernate about 2/3rds of the way through Steve and I’s session. Hopefully we managed to cope OK even though I filled the gap with part of my standard rant about risk and procurement (it will appear here at some point soon, really).

The final presentation is here UNICOM NPWD Final Presentation

The best quote was from Chris Ambler Head of QA for Electronic Arts when referring to testing a 1st person shooter game. He was taken to task for not testing all the scenarios in a game after an obscure one crashed the server; his comment “How can you completely test something that uses AI (Artificial Intelligence) to fight back”. The important point is that in complex systems (all systems in reality) not every scenario can be tested.

I had a couple of very interesting conversations at evening drinks. One was with Peter Measey about the difference between a project and a programme. He insisted that a a programme was a group of connected projects that deliver business benefits; effectively a “change programme” that does not have a proscribed end. My position was that, in the agile world, the whole focus of projects is on business benefit and change and shouldn’t a change programme have measurable end in the same way as projects? If you accept this then surely a programme is the “macro-project” that all the other projects are “workstreams” from. More to come here as well I think.

The other conversation was about the difference between project management and project facilitation which I need more time to digest.

Monday 11th February

I am presenting a case study of the National Packaging Waste Database project with Steve Watkins of the Environment Agency tomorrow at this UNICOM conference. Wish me luck!

I’ll try and blog from there as well as there are some other interesting looking presentations.