Get control of failing projects - be Agile

I've specialised in a particular area of project management called "Turnaround".  Where other project managers specialise in different aspects of project delivery I specialise in clearing up the mess that some of them leave behind.  If project management was a hospital I'm more the Paramedic or A&E specialist than the long term cardiologist or pediatrician.  You don't ask me to manage your long term care - just breath life back into the patient.

When my kids needed to know what I actually did when I left home for the day I found it a bit difficult to explain what a project manager actually does.  I tried lots of things but finally hit on the explanation that "Daddy's job is to stop the s**t hitting the fan - but when it does he has to clear it up afterwards".  As the years have passed I've realised that I've built my reputation up on the latter.

I'm often asked "... so how do you turn projects around?" normally followed by "... so what extra controls do you put in place to get it back on track?" or "...I bet you have to be tough with people?"

I've thought about it a lot this week, not least because I'm helping a new client deal with a failing critical project, and I've come to the following conclusions from my experience:

• Projects don't fail because of a lack of controls in fact the truth is the opposite.  There are so many controls in place that everyone is wasting time managing the control system and forgetting to actually do something
• Projects don't fail because stakeholders aren't managed properly. Most people in my experience go to work to do a good job not destroy things.  The problem is that we spend so much time "managing" stakeholders & teams that we forget that they need time to actually get on with what they're good at
• Projects don't fail because people don't know what they want.  They struggle because people just don't take the time to think about the best ways to communicate something and make sure that everyone has the same ideas.  No - we'd much rather have controls and detailed documentation that we read, review and comment on.  Wouldn't it be so much better if we simply chatted, agreed the best solution and then got on with it?  So much more effective & efficient
• Projects don't fail because we don't have enough resources, money or time.  They fail because we allow expectations to get away from us or become so intransigent that we oppose change even if the new solution would make what we do more useful and relevant
• Projects don't fail because we don't follow a "proper" process, don't have "proper governance", don't have "rapid action teams" or don't have "change control".  They fail because all of these things, if improperly applied, strangle the innovation out of the best of teams

My daughters still think its amusing for me to think that I'm now fashionable and cutting edge.  But me and my "project busting" compatriots who believe that projects are just containers for actually "doing stuff" are becoming the majority.

For me projects have two type of influences - Gains & Strains.  The higher the Gain to Strain ratio the more likely you are to keep it on track.  So when I'm faced with a failing project I aim to reduce the strains as quickly as possible. 

Typically this includes:

• Reducing command & control mechnisms to the absolute minimum
• Changing from "Project Review" meetings to more informal get togethers once a day to synchonise activity
• Stopping the "management" activity and emphasising the "leader/support" role
• Distracting company control freaks with "plans" and lots of activities that I need them to go away and deal with (that won't impact on the team or the project in any way)
• Taking on the role of dealing with the blockers rather than allocating the tasks

So I guess that means

People over process, Deliver over Control Documentation, Cooperation over Contracts and Change over Detailed Plans

Haven't I heard that before somewhere?

So it looks like my "secret" is that I make projects more agile.  I liked that in the past I was a maverick and did projects differently to everyone else.  Now agile's becoming mainstream does that mean I'm going to have to become a Waterfall evangelist now just to be different.  Now that's a scary thought!

Mike :-)

Lean Contracts & Trust - Are they really compatible?

I was asked an interesting question this morning - "Agile just doesn't work our work with fixed price contracts - so what should we do?"  I guess I understand the problem - when you're designing & delivering using an iterative approach it's pretty difficult to tie down what's the contract is all about.  If you can't do that then it's even more impossible to apply penalty clauses to incentivise suppliers.

The more I thought about it the more other questions came to mind.  Do fixed price contracts really work in any project environment?, Can we really define exactly what's got to be delivered in sufficient detail to deliver a truely accurate cost?, Do penalty clauses really deliver? and What do we have fixed price contracts anyway?  Now I've worked on a wide range of projects including so those with so called "Hard Deliverables" and, without exception, I can say that fixed price contracts never delivered what we expected - but that's in their nature.

There are two ways to look at contracts and it depends on what you believe.

Conventional view - Companies look out for their own interests and Contracts are needed to limit opportunism

Lean view - Assume other parties act in good faith, good relationships limit opportunism and contracts should encourage through incentives

So if we take the lean approach there are some key questions that will be worrying managers: Who takes the risk?  What's the price of trust?, How does our approach change? What does a Lean contract really look like? and Can it really work?

Now I don't profess to be a procurement expert but I do know that lean contracts are very effective in all environments - especially in software development and business transformation.  I've negotiated partnership agreements with suppliers based on Time & Materials with incentives and they've been extremely profitable for both parties.

Luckily for us though, Mary Poppendeck really explains the subject very well in her presentation Agile Contracts - What is trust? She tackles the difficult concepts for lean contracts precisely with good case studies and excellent practical conclusions so I'd really recommend a read.

I'll come back to this subject in the coming weeks.  I believe that extending Agility to partnerships & suppliers is the next barrier for Agile to overcome.  Pulling together the wider end to end team (partners, customers and suppliers) reminds me of the "Just in Time" projects I covered early in my manufacturing career and the key foundation of that was Kanban management....  Trust & partnership were the foundation of those phiolosopies as well and they've coped well over the years.

Maybe I can see a link here - Just in time->Kanban->Agile.  That's what I'm going to talk about soon in this blog.  There might just be a coming together of lean manufacturing & lean projects or BAU & Projects.  That sounds an exciting development.

Agile - it's not complex enough!

I've just finished Prey an excellent book by the late Michael Crichton.  It's a very scary book that follows the development of nanobots that evolve and form autonomous swarms. Although they have no individual intelliegence they demonstrate emergent behaviour in the same way that birds flock or termites build complex homes.  The moral of the book is clear - self organisation can be very effective - and of course dangerous.  It's also easy to see how the fictional story could become a reality - but that of course was Crichton's skill.

It got me thinking, what is this "self-organisation" thing anyway? Do self organising teams really self organise or are they really guided?  Apparently I'm not the only one who's throught of this.  A great presentation by Jurgen Appelo - What (else) can Agile learn from complexity looks at Complexity Theory and Agile.  Now before you click on that "back" button it really is worth a look. 

He looks at the key factors of complexity theory and applies them to Agile and there are some great quotes:

Darkness Principle

Each element of a system is ignorent of the behaviour of the system as a whole... if each element "knew" what was happening to the system as a whole all of the complexity would have to present in that element

This is one of the major issues that traditional management methods fails to recognise.  We believe that the more we know the better we can control something.  However, the reality is that it takes too much time and resource to try and control everything because the control system always needs to be more complex than the project we're trying to control.

Boundaries & Conditions

Self organisation requires that the system is surrounded by a containing boundary.  This boundary defines the "self" that will be developed during the self organising process"

Which implies that all Agile activities must have some form of wrapper.  The concept of a project is well know and tested as a container for self-organisation so why create a new concept.  Agile & Waterfall can co-exist and work together - in fact they're symbiotic.

Fitness Landscapes

The environment is not out there separate from us.  We can help to create the environment... The Spanish have a phrase 'My friend, these is no road - you make the road as you walk'

If ever there was an argument for emergent design in IS projects then this is it.  Emergent behaviour is apparent all around us.  No one "organises" the bread supply for London it just happens.  Our brains are a classic example of how independent elements can combine and a "self" can emerge from the chaos.  However, as we know it takes time for intelligence to evolve and most organisations simply don't have the patience or belief to wait!

Incompressibility

There is no accurate representation of the system which is simpler than the system itself.  In building representations of open systems we are forced to leave things out, and since the effects of these omissions are nonlinear, we cannot preduct their magnitude

Which means - we can't predict the future so why waste so much time trying to plan & deal with things that haven't, and probably won't, happen?


There's a lot more in Jurgen's presentation and I'd really recommend that you read it through.  I'd also recommend Michael Chichton's book because it's just a rally good story (and a lot more believable than Jurrasic Park!).


So does Agile need more complexity?  Absolutely - because it's only when we understand complexity that we can keep agile simple for the rest of us :-)


Happy Friday


Mike