Project Warning Signs

//Project Warning Signs

Project Warning Signs

We often get asked to look at projects that have lost their way with the intention of looking to bring these back on-track.  The truth is that planning and organisation up-front in 99% of cases would mitigate issues; and this is perhaps more important of an Agile ran project than on a traditional waterfall model but is something that seems to be overlooked.  I think this is because “Agile” is meant to implicitly avoid these issues right?  So why do we still experience project failure?

On a project rescue engagement we break our analysis down into three key areas:  People, Process and Tools and we commonly encounter the following traits which are the result of underlying project issues regardless of methodology.  If your project sees too many of these issues then you probably have a problem which is only going to get worse unless you address the root cause.


  • Too much information is in people’s heads, or indeed a single individual’s head.
  • Team morale is low.  Often teams know there is a problem and know they are not delivering quality results but don’t know how to fix it which results in low morale.
  • Unwillingness and fear to change an established way of working.
  • People are working on multiple activities and possibly multiple projects and so are therefore unable to dedicate their full attention to the project.
  • Teams are unaware of each other’s jobs (eg: Dev, Ops, Test) and work in isolation.
  • Relationship between the business and delivery management is poor.


  • Inconsistencies in quality of deliverables.
  • Estimations are unreliable and releases / demos are always late.
  • Code drops are buggy and re-introduce old bugs – worse than this it is accepted that this will be the case.
  • There is no appreciation for triaging of bugs, at root cause analysis or estimation of fix times.
  • Estimation is a dirty word and “is impossible”.
  • Demos are rushed and the team are pressured to move onto the next Sprint without having time to really analyse and review the last work iteration.
  • Sprints undergo too much change with new features replacing others throughout.
  • All Sprints under-deliver with hope rather than analysis dictating the next Sprint’s target velocity.
  • Sign off of individual features is left to the last few days of a Sprint meaning that nothing is “done” until the last minute (code review, testing etc) resulting in poor quality.
  • Automation is minimal to non-existent.
  • Sprints start before much (if any) analysis of the upcoming features is undertaken.


  • The project knowledgebase is incomplete or out of date.
  • Coding standards are not checked.
  • Code quality checking is not considered important.
  • Setting up new environments is a feat of engineering matching that of constructing the pyramids of Giza.

This is not an exclusive checklist of areas to watch out for but does count towards the majority of common project ailments we see time and again.  If you are reading this and recognise some of these issues you should take heart that if these mistakes are being made over and over again by different teams that there should be simple fixes.  And you would be right.  There are fixes to all of the above issues.  In our experience perhaps the more difficult challenge is that of wanting to change because people have an in-built optimism (or their job is on the line) that things will get better and if we stay the course that little bit longer things will right themselves.  Clearly the phrase: “hear no evil, see no evil, speak no evil” has never been more relevant in IT today.

The first step is to recognise that there is a problem and then to get help to identify a path back to consistent, predictable and quality delivery.

By Paul Tough

By | 2017-08-31T10:14:31+00:00 November 23rd, 2016|Categories: Blog|0 Comments

Leave A Comment