button1-projectconsultingbutton2-learning and developmentbutton3-managedservicesbutton4-cloudmanagement

17 October 2016

Why is a failing project like boiling a frog?




If a frog is put suddenly into boiling water, it will jump out, but if it is put in cold water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death.

Similarly, projects don’t go wrong overnight, but gradually and under the radar, until they are cooked to death.

The lesson here? You need to check your frogs….

two frogs

Watch out for the tell-tale signs:

  • Late working – one or two days is okay, but if sustained…
  • Re-planning – “every project is on time according to the last plan written”
  • Re-Scoping – features being removed – especially easy to hide in an Agile project
  • “It will do” mentality – perhaps accepting poor performance of some code rather than fixing it
  • “We will catch up” mentality – denial can waste valuable recovery time, don’t leave it too late to review and call for help
  • Surprises – we identify technical risks and deal with them up front or in a Proof of Concept project


Two or more of the above and your frog is cooked!

Each of the below should be considered as turning up the heat on your frog!

  • Increasing management involvement – can be overdone
  • Preoccupation with bug counts and burn down charts – Not all bugs are created equal
  • Requesting additional staff – pulling from other projects – Natural team size for work, adding cooks can actually slow things down…
  • Stakeholders missing meetings – lack of engagement/interest
  • “Don’t bring me bad news” culture
  • Presence of a “Project Monitor” rather than a “Project Manager

Two or more of the above and your frog is cooked!

Now – have a look around you – are there any frogs slowly cooking?? 

28 September 2016

Agile and the Seven Deadly Sins of Project Management




A talk on Agile by Mike Cohn

At the Better Software Conference in June 2008 Mike Cohn presented this talk on Agile entitled ‘Agile and the Seven Deadly Sins of Project Managing‘. It’s a great talk and still absolutely relevant, exposing the ‘sins’ that we are all guilty of often.

4 November 2015

Benefits realisation: When success is not a benefit…..




 … A PARADOX!

You’ve delivered your project on time, within budget, the customer has signed it off and you’ve completed your closure report. You’ve done your job, right? Time to move on to the next project, right? It depends.

It depends on what kind of Project Manager you are and what success means to you and your organisation.

Essentially a Project Manager is accountable for the success or failure of a project. So far are we in agreement?

Typical responsibilities of a project manager range from planning, executing and closing projects to managing teams and stakeholders but indulge me for a second, who ensures projects deliver the benefits detailed in the business case are realised. In my experience no one does. I will return to this point later.

John Thorp (The Information Paradox) based his new approach to benefits realisation on the following premises:

  • Benefits do not just happen.
  • Benefits rarely happen according to plan.
  • Benefits realisation is a continuous process.

This “benefits mindset “, as John Thorp coined it (in 2003), has not been adopted and as such even today, investment in IT enabled business change is still not translating into business value. Why is this? Paraphrasing Michael Krigsman (of ZDNet) here, but people don’t know what they want. Permit me to add an addendum. If they got it (what they asked for) they wouldn’t know it.

“REALISING BENEFITS – IT’S WHAT PROJECTS ARE FOR!” Gareth Byatt and Jeff Hodgkinson said this. It sounds simple, right?

“REALISING BENEFITS – IT’S WHAT PROJECTS ARE FOR!”

Yes, but why then do upwards of 70% of projects fail (ESP Solutions Group, Gartner and ZDNet all back this up with their findings from as far back as 2008 to present day). So why is this?

The process of benefits realisation should begin at the earliest stages of initiation and should continue after the project deliverables have been met. Benefits should be defined in the project business case and should be related to advancing the organisation’s strategic objectives. Otherwise, adapting what Gareth Byatt and Jeff Hodgkinson said what are projects for?

From theory to practice, at The Project Foundry, the benefits realisation process is broken into four stages:

  • Identify: What is the problem you are trying to solve?
  • Define: Benefits should be clearly defined. For a project to be measured against benefits, these [benefits] must be defined as tangible, measurable benefits.
  • Plan: These [definitions] must be built into the specification of the project deliverables.
  • Realise: Once the deliverables are commissioned, these [changes] must be embedded so as they can become the “new business as usual” with the organisation’s performance targets [KPIs] adjusted to incorporate them.

At The Project Foundry, advocates all of John Thorp, I will leave you with one of his three necessary conditions for changing the way people think and manage “activist accountability that includes the concept of ownership”. With a willing client, benefits can be delivered, but only if the business sponsor is (willing) to take ownership and accept clear accountability for delivering the [project or program] benefits.

Finally, let me leave you with this thought? Ownership and accountability don’t have to be scary words. Benefit is good, right? Yes. Being accountable and owning something good is even better. We can empower you to make this happen.

WHEN SUCCESS IS A BENEFIT… CERTAINTY

A-Z of Project Management

Sign up to receive the A-Z of Project Management direct to your inbox