Programmes are the reason so many projects are deemed to have failed.

Build a dungheap and the insects will come

I just left a meeting where we discussed a large and complex programme of work and my mind kept going back to recent discussions about why projects fail. We have been talking about project managers who stay in the office playing with gantts and charts and PMs who know nothing about their subject matter, but see themselves as traffic coordinators. These are real concerns and they are at epidemic level at least and need to be discussed and resolved.

Take one step back from this discussion,however and place yourself in the average programme office
.

If the Project manager rarely sees the battlefield, and spends his time constructing fantasy plans without ever checking with reality and assuming that things will stay the same, then imagine how far removed the average programme manager is.
Today I watched just such a Programme manager going through a programme plan and showing the position of each project and of each tranche and giving a thoroughly convincing performance, but based on a few conversations with project managers before I went in, things were not at all like the programme manager’s presentation suggested. Not only was he highly removed from the truth about the various projects, the truth of which was obscured behind vague and even pointless KPIs, but he had no idea of the true situation within any of these projects. One project had reached it’s milestone just ahead of the presentation by launching something totally flawed in the knowledge that it would not be found out for a while and if they hadn’t fixed it in the meantime they would deal with it then and feign ignorance of it. The KPI was declaring completion, not passing though any realistic test of completion.

How can you risk manage a programme without total honesty and a powerful beam of light?

I dread to think of the consequences for his programme of a key project on the critical path getting into serious trouble. If he is measuring the programme with this type of metrics and this lack of control, what chance is there of coming anywhere close to success?
As it happens that project is a critical one and it can stop the entire programme., it should be the focus of major attention until it is out of trouble or the whole thing is abandoned.

There is no difference between this handling of projects and programmes and the commercial practices of reporting false profits to keep shareholders happy and  keep the capital flowing your way.  We have created the conditions for failure and it will continue to happen regularly just as a pile of compost left in the garden will attract plant life.
Is there a realistic answer on either front? I will have to think about this one.

One note in my notebook is quite revealing, no member of the board was present to learn how things were going.

 

 

Whose fault is it anyway?

 

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake
Contract negotiation and on we go
Whose fault is it anyhow ?

 

23% of European projects cancelled, more than half overran by 50% or more.

When projects grow to any size, they invariably lose sight of the basics and especially they lose sight of the goals.

In the above study the authors uncovered weaknesses that have reached epidemic proportions, i.e

  •  inability to distinguish the critical success factors from Prince 2 speak ( total faith in methodology alone).
  •  Wrong KPIs from day one.  Inability to define and agree requirements. 
  •  Poor programme and business management leading to people believing they have done well when in fact they have missed the target completely, or that they are failing when in fact they are performing well.
  • Poor estimating of cost and time leading to inaccurate plans and poor management failing to follow good plans.
  • The wrong person in charge.
  • The wrong reason for starting in the first place. 
  •  Bad decisions made for the wrong reasons.
  • Unspoken political issues that were well known from the start, but could not be spoken of openly.

The most common failings are at the early stage and they are failings to understand:

1. Failing to understand what is best for the client. It doesn’t matter who is responsible for identifying and solving the problem, client or trusted adviser.  Things will go badly for both sides of the relationship unless it is done well before proceeding to delivery phase.

The challenges here are well understood, new technology in anything from fighter planes to productivity software is a challenge to understand, explain, evaluate, risk manage and decide on.
When it comes to an independent adviser this can be a little easier, but when the adviser is the supplier then it is more difficult to evaluate the accuracy of the material before making decisions. One of the biggest root causes of failing and vastly underperforming projects is poor choice of solution either through misunderstanding the problem, the operating climate, or the proposed solution.

The client has to take responsibility here, there is no alternative.

2. Understanding the problem and knowing what solution is chosen, but not understanding the macro and micro detail of exactly how the solution delivers and whether it really will fit in, switch on and work well enough to deliver on the promise.

Let’s say our customer is solving a scheduling problem and has agreed to invest in an automated scheduling solution. At this point it is hard to fault the logic. This is macro level. Now at Micro level our customer will have discussed certain things like how it interfaces with his ERP system and details like how it chooses who to send a particular emergency to.  All the big stuff and all the sexy stuff tends to get discussed.  What nobody has looked into is whether this system can deal with the fact there are many jobs where a dozen or more customers have to be visited at once in close proximity ( a warden controlled environment for the elderly is just one case).  This is the type of thing that is completely missed out on and grinds everything to a halt at some point, sometimes to the extent of scrapping everything and starting again, but more often by adding to the time and budget estimates, or dragging down the project slowly by reducing the benefits and spoiling the expected return.

3. Understanding the problem and the solution, but failing to understand the ambient climate that affects whether an expected outcome can be reliably predicted, or whether a more conservative approach is required, or perhaps and “all-in” gamble when there is nothing to lose and all to gain. Certainly there is a marked difference between the decisions being made today and those being made prior to August 2008.  I saw EDI solutions implemented at enormous cost at a time when a web page with HTTPS could have solved the same problem.

These three aspects are just small but very important reasons why projects will continue to struggle until they are taken more seriously.

Working relationships have to be enabled and supported, or they will hover close to litigation.

There are no big companies, just people who work at them and most decisions are based at some level on selfish motives. More often than not a supplier’s representative has to meet certain targets and will play the game to defend his margins.

In order to meet you half way he has to feel very confident that you can be trusted and he has to be motivated by gain. Don’t read this wrong, the gain I am referring to is the gain that results from satisfying his superiors, or exceeding their expectations, the gain for a customer representative is very similar though it will often be motivated more strongly by personal risk aversion.  Few organisations reward risk taking and even fewer forgive the risks that mature.

Easy solutions with negative undertones

The easy solution for the sales director, or suppliers project manager is to record what you ask for, make sure it is sufficiently close to what they are offering to keep them on a safe legal footing and then proceed in the knowledge that whenever it goes a little wrong, they will be very sympathetic and give you a bit of a discount on the extra work you needed. This strategy places all the risk on the customer and the further in the he commits the business, the less likely he will be to walk away and admit defeat. This strategy has developed into an art called “contract re-negotiation” that has begun to appear on CVs.

The easy solution for the customer project manager is to ignore the details and make it appear that he is placing all the responsibility for detail on the supplier. Then when it goes wrong they will wrangle and resolve it and he will continue to maintain his innocence and to castigate the supplier.

 

The correct solution is to negotiate the contract correctly from a position of enlightenment and to identify and spread the risk evenlySimplest case

The easy solution for the customer is to hire a red hot BA to document in great detail every aspect of the required solution, ask every question that needs to be answered and double check the fit with the business requirement, business strategy, prevailing conditions.  Having signed this off with business stakeholders, the risk has now been spread evenly and fairly.

The business makes a business decision and takes the strategic risks, the supplier works to a precise specification and prices the job accurately to leave an appropriate margin, the delivery team have only to concern themselves with identifying the risks that remain managing them attending to dependencies and keeping everything on track.
Any unexpected issues are easily categorised as such and there is a clear path for handling them appropriately.

More complex case

Many projects carry with them an element of innovation, this is the stuff of progress and it is critical not to smother it, but to do it well requires a marriage, or at least a fairly resilient affair between the business and the technology partner.

The answer is not surprisingly a combination of the two previous approaches. First of all a BA must do the job of defining the part of the project that is well understood in terms of business need and the supplier must bid for this as though it were the whole project, initially at estimate level.  The areas requiring innovation and carrying higher risk must be evaluated and risk managed so that a maximum cost and a likely cost can be established and the risk level can be well understood.

Once this is done an approach is defined that tackles the biggest impact risks as early as possible in order to allow an early exit if things go wrong.  Regular stage gates are planned so that there are opportunities to revise risk and cut losses early.  Managing the risk in this way makes this aspect of the project less likely to fail catastrophically and brings it out in the open early.  Working relationships tend to prosper in this type of environment and good relationships deliver good outcomes.

Risk management is like charity, it must start at home.

The first and by far the greatest risk to every project is the culture of the organisation.  As this report supports, many project managers turn a blind eye to political situations that can’t be discussed and proceed in the hope that all will be well.  Some of these situations include: mixed feelings in the boardroom and tripwires around every corner, Gadget freaks in the senior management who want to add on stuff they would like to play with.  Management who shoot the messenger, but can easily be fooled. People who get involved with the suppliers or their staff socially and undermine the project team.  There are many more examples of very serious risks that remain unspoken, but are responsible for a great many failures.

 

 

Reblog this post [with Zemanta]

Contract negotiation and on we go

Previous installments

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake

A shock for the project manager

In the last instalment we discussed the way in which a vendor had been chosen that near total disregard for the goals of the project in the course of making that decision. Now we will look at what happened after the decision was made.
The next agenda item directly after awarding the contract was to negotiate and agree details and on this occasion it was lead by the vendor’s legal team and the sales rep.  The atmosphere was very warm and jovial and nothing was too much trouble in the vendor’s quest to make the new customer happy.

So far so good

The contract was agreed just after lunch on day two and everyone went away with a sense of achievement.
Deliverables were carefully defined and the acceptance criteria was very forgiving. It would have been clear to any pro that there was a lot of stuff not mentioned that would need to be done and paid for, but it was not brought up.  The bulk of the cost was loaded up front with a year’s licenses to be paid for immediately and support to begin charging on contracted release day.
There was an SLA, but it gave no guarantees of times to fix issues, only times to address them. The rate for professional services was a little steep at £1400 a day but it seemed academic.
The real problem with this contract was that it never referenced the now academic requirements documentation (In any case it was pretty useless) and
the contract revolves entirely around delivery of a certain feature set as described by the vendor in features language, not in business need language.
Success criteria is defined as delivering this feature set by a given date and to a given cost
At this point we have two teams involved; a project team that is now providing services to the vendor to get the job done and a vendor with the goal of delivering the described features and getting paid.   Our initial problem of lack of experience and know-how in the sales and marketing teams has never been addressed and is not on anybodies radar and there is nothing anywhere, either spoken or written to say that delivery of this feature set will solve the defined problems I.E. the business case has been forgotten. In fact the thing that really swayed the decion on which vendor to use was a very sexy system that lets  the user record telephone conversations and the hardware to make this work pushed up the cost.  
Here’s the shock for the project manager.
The sales rep is now cosy with another potential client and the project manager is now dealing with the professional services team tasked with delivering the project to  tight budgets.   Now he’s dealing with a real project manager and a hard nosed business man who survives by taking no prisoners and earns bonus by growing the contract value through extras. He is a past master at dealing out the rope and charging to reel it back in and he’s seen all the snivelling before. He is the essence of tact and diplomacy but his hand is firmly in the project managers pocket.

The roller coaster

Within two weeks of contract completion, the mood has turned frostier and it is clear that this is not precisely what the project manager had expected and hoped for.  Everyone is now locked into a roller coaster of milestones and budgets and the reason for it all is completely forgotten. That was handled in phase one, wasn’t it?  You get on in the corporate world by meeting milestones, not by delivering results and certainly not by making waves.

We are where we are

We are now on ride that won’t slow down until this thing, whatever it is going to look like, is delivered and we can start the job of making it work and getting people to use it so we don’t lose face.
Nobody who suspects the truth, if such a person exists, has the seniority or the courage to step out of the line shout horses@”!* and nobody with the authority or the presence to do something has any idea that things are not what they seem.

 In the next installment we will look at the the end game

About the author