A really expensive experiment

I was speaking at a PMI conference in Sweden and took the opportunity to listen to some of the other speakers, one of whom was Henrik Kniberg. Henrik is a guru on agile and lean and he told the story of a rather large public sector project in Sweden. The inadvertent experiment was that they did the same project TWICE!
To start with, Henrik discussed what “success” is and he defined it as being happy customers, happy users and happy development team. With apologies to PMI’s “triple constraint” he said to forget about time, cost and scope . . . actually this bit of the talk mirrored the start of my own talk at that conference, so “Mr Classic PM” and “Mr Agile” are on the same page. Why you undertake work is more important than what or how you deliver.

Henrik's different perspectives on success, over and above the "triple constraint". This thinking matches my thinking in Project Workout.

Henrik’s different perspectives on success, over and above the “triple constraint”. This thinking matches my thinking in Project Workout.

Henrik’s case study was all about improving society by helping the Swedish police force work more effectively. You’ve all read those dark, gloomy Scandinavian crime thrillers, so you get the idea. As we were in Sweden in “Wallender” country, it all seemed appropriate.
So, the first project was like this:

  • Mission Improve society
  • Requirements Unclear
  • Delivery Agile (= Iterative/incremental)
  • User involvement Continuous
  • Team’s influence over technology choices High
  • Technical platform Java

It took two years and comprised a series of releases, starting with the first one after 6 months, which the police hated, then after 18 months a nation-wide release and ending up with something they all really liked. SUCCESS!

Then “someone” had a bright idea to rebuild the whole thing in Oracle Siebel as Oracle said it would be better and cheaper. And as they were in a hurry to save money, they would go “big bang”. After all, they knew the requirements as the project had already been completed. So this is project 2:

  • Mission Reduce maintenance cost
  • Requirements Clear
  • Delivery Big bang
  • User involvement None
  • Team’s influence over technology None
  • Technical platform Oracle Siebel

This turned out to be a train wreck in slow motion:

Stakeholder response: outrage
Cost 200m KR (double that of project 1)
Time 24 months (as opposed to 18 months for project 1
Measured impact: Police blocked from using it several hours a day; error rate increased.

Lesson to be learned

So, the lessons are:

  • Focus on solving user needs not just cost: effective nearly always out-strips efficient;
  • Deliver iteratively and incrementally if you don’t know what you really need;
  • Involve real users.

Beware of standard platforms:

  • They might not be as standard as you think;
  • Listen to your technical people not just to a vendor selling stuff.

How many of you are building major capabilities on the promise of using a “standard” platform? I can certainly think of one I was involved with recently!

How do you think the re-platforming should be handled? . . or even should it be done at all, if what is there isn’t broken?

What about migrating from one to the other? Should we always design this in from the start? Or is it like turkeys voting for Christmas?

So agile is always better, is it?

Oh, and the stuff about ‘agile’ and ‘big bang’? That is just a red herring. You should use whatever delivery approaches are appropriate and proportionate to what you are doing. I expect some people reading this have had senior executives issue an edict: “do all projects agile!” This approach is just as mistaken as not trying agile at all – it underlines the classic IT confusion between a development approach and a project method. It’s not a case of ‘agile’ versus ‘project management’. Nor of thinking ‘waterfall = project management’. ‘Agile’ and ‘waterfall’ are delivery methods. Project management is a wrapper, which can contain any number of delivery methods, depending on the type of deliverables being produced.

Functional thinking destroys business value

In my blog, Enemies within, I highlighted 10 reasons why projects continue to

People get cross with each other and, often, it's not their fault.

People get cross with each other and, often, it’s not their fault.

fail, despite all the methods, standards and training we throw at our people.  basically business leaders get the project performance they deserve as most inhibitors are institutional. This is what I said:

Functional thinking – not taking the helicopter, the organisation-wide view. This often happens when executives’ or individuals’ bonuses are based on targets which are at odds with the organisation’s needs, e.g. sales bonus rewarded on revenue, regardless of profit or contribution.

Let’s look at another aspect of this – cost management.  Most organisations set their annual budgets, top-down, based on an expectation of revenue and costs. The costs then trickle down to cost centres and managers of departments of functional specialists, or other segments of the organisation They have a budget for the year to work within. Sounds familiar? On top of that we put time recording and ever more rigorous (onerous?) procurement systems – after all, we must be hard nosed business people and make sure we only spend what is needed. Finance people then monitor the costs and do all sorts of jiggery-pockery to deal with their fiscal needs, accruals, internal transfers, prudence concept etc.

All this budget setting is done for a financial year, 12 to 15 months in advance.

Actually, that approach can work well for steady state bureaucracies, where next year tends to look rather like last year. It is what most people are familiar with and yet, how many people, nowadays, work in such a predictable, steady state organisation?  What if you are in a fast-moving, unpredictable sector where you are not sure what will make up your order book and what mix of resources you will actually need? They also realise that they need to deal with cross-functional projects and so they “interlock” the demands of the projects with the cost centre budgets.

A budget set to  12 to 15 months in advance on this basis looks rather optimistic. So what happens is this:

  1. department managers spend their all budgets (so they don’t lose it next year) regardless of the overall business need – after all they are targeted on their cost spend.
  2. projects get starved of resources, as the mix of resources and costs change as work is won (if customer facing) or initiated (if for internal transformation). This can be despite the “project budget” having enough funds, as all too frequently the departmental budget takes precedence.
  3. project managers get cross with functional managers who unilaterally withdraw their resources, despite the project budget being adequate
  4. department managers get cross with project managers for not predicting exactly what they will need up to 12 to 15 months in advance.
  5. it becomes a blame game
  6. the company and customer suffer

Managers:

  • who exceed their budgets are told they are bad managers
  • who undershoot their budgets are told they are bad at forecasting
  • who hit their budgets are told the budget was probably not stretchy enough.

So how can you deal with this?  The first thing is to realise that the above scenario describes a matrix organisation, where resources are shared across many projects and business activities. If you have a matrix organisation, the controls of the simple bureaucracy (cost centres) are totally inadequate – you need to have a full, matrix infrastructure in terms of portfolio, programme and cost management and for resource planning and assignment:

  1. Manage the business across the organisation not down the cost centres
  2. Allocate budgets and funds to projects (or other cross-company entities) not to cost centres.
  3. Create governance which crosses, the organisation, taking power off the costs centre managers
  4. Only give cost centre managers funds for training, management, holidays, sickness etc.
  5. Have a rolling monthly forecast, spanning financial years (“interlock” resets half yearly or even quarterly of often not enough).
  6. Let any person work on any work, anywhere in the company.

Done right, you will have a flexible, self correcting organisation, which is simpler to run and focused on business value not discrete costs centres. You will have tipped the balance of power away from the “silo” cost centres towards managing business value across the organisation.

Want to know more?

See the Project Workout, 4th edition:

  • Chapters 14 and 15 on matrix governance
  • Chapter 16 on resourcing
  • Chapter 17 on matrix systems to make it work

Whose success is it?

In my “enemies within” blog, we looked at how management get the project performance they deserve. In that blog we explored the important role of the programme and project sponsor in making sure that an organisation’s programmes and projects succeed. But what does “success” mean? Success is too often interpreted through the differing eyes of stakeholders.

Successful project management ensures the delivery of a specified scope, on time and to budget (PMI’s triple constraint). It is related to how efficiently a project is managed. This should be assessed during the project closure review, documented in a project closure report and measured by timeliness of delivery milestones, adherence to budgets and quality. This is commonly associated with the role of the project manager.

A successful project realises the business benefits it was set up to achieve as stated in a business case. It is related to the effectiveness of the project in meeting the objectives set. The post implementation review (post-project review) assesses this. Measures of success here must be indicative of the business objectives being achieved. This review therefore has to happen some time after the output of the project has been put into use. It is associated with the role of the project sponsor.

A successful organisation drives towards its strategic objectives while fulfilling expectations of shareholders, managers, employees and other stakeholders. Measures for this are at a corporate level and should be financial and non-financial, such as a balanced score card. This is associated with the role of the chief executive.

A project which has been successfully ‘project managed’, however, may actually deliver little of value to the organisation. Further, a ‘successful project’ may not further the strategic objectives of the organisation, as its objectives may be out of alignment organisations seeking to optimise their total portfolio of projects through the effective combination of project management, sponsorship and portfolio management. A failing company can be full of ‘successful project management’ and ‘successful projects’ all driving in different directions.

The PMI’s recent report, Pulse of the Profession 2013, has actually picked up the above themes, so may this will help senior business leaders realise the potential that effective and efficient project management has to drive their organisations.

Gartner goes one step further and state that organisations which grasp this first will have a enhanced competitive advantage over the others.

Whatever you do must help you move towards your strategic objective. Otherwise there's no point.

Whatever you do must help you move towards your strategic objective. Otherwise there’s no point.

References:

When efficiency has the opposite effect

If I make every part of my organisation super-efficient, I’ll have a really efficient organisation, won’t I?

Well, if you believe this, then the whole of the theory of constraints seems to have passed you by. Squeezing every bit of efficiency out of every bit of an organisation generally has the opposite effect. It can make matters worse or even prove disastrous. On a similar note, one part of an organisation making itself super-efficient may also make the whole organisation perform worse.

We live in the real world, not a theoretical world, things can and do go wrong (no matter how often you bang the desk and shout at people!). The world is too complex and inter connected to be able to predict causes and effects across an entire organisation and the environment which influences it. Against this back-drop, let’s look at these two cases.

Case 1 – a production facility
Take a simple factory line. Raw goods go in one end, are worked on in a series of machines and then finished goods come out the other end. Each machine has a probability of breaking down. The thing that matters is not that every machine is working to maximum efficiency, but that the throughput of the whole line, from raw materials to finished goods, is maintained and is efficient overall. If a machine breaks down, this stops downstream machines working as they have nothing to process. Manufacturers deal with this by having “buffer” stocks of partially finished goods, so the line can continue working even if an upstream machine is out of action for a time. The size of the buffer is related to the probable “outage” time. If there were five machines, each with a probability of breakdown of 0.1, then at any point in time there is a fifty:fifty probability the line will be out of action. If someone had insisted that the “buffer stocks” represented waste and required them to be removed, that production line would be out of action half the time. When any one machine breaks down, the whole production line stops. So much for efficiency!

Case 2 – having one really efficient part
In the second case, imagine a sales group who, in isolation, devised a really effective and efficient sales approach. They did this because they had an instruction, from on high, to be as efficient as possible. So like good corporate citizens they halved their sales costs and quadrupled the volume of sales. You’d think this was rather good wouldn’t you? WRONG! If the fulfilment departments couldn’t keep pace with the increased sales volumes, there would be a lot of dissatisfied customers.. . . in fact “service” may now be so bad, customers want their money back and will never buy again; and you get a slamming in the press. Not quite what was wanted.

So, when looking at efficiency, you cannot look at any part in isolation; you need to look at the whole chain and decide where the “constraint” is and manage it. Certainly you can improve efficiency, but it must always be in relation to the whole system. Find the constraint, remove the constraint, check the throughput and then move on to the next constraint.

In a later blog we’ll look at how theory of constraints affects project working . . . but I think that is enough for you to chew on, for now. In the meantime, if you want to know more about the theory of constraints look up Goldratt.