About twenty years ago as a callow youth, I went for a job interview with a big bank.  I was working for a large Software House/Consultancy where processes were very ordered and strictly followed.  ISO 9001 was a prized compliance, used to sell how structured and disciplined we were.  Projects had to comply with the process regardless of their size and nature and as Agile hadn’t been invented yet, all projects followed a Waterfall approach.

 

I’d flown through the first interview spouting process and discipline and had been asked back to meet the deputy head of department for a second interview. At this interview I was confronted by what at the time appeared to be some sort of Luddite.  After I’d bored him senseless with half an hour of process speak, he told me that processes were oversold and that the reason software houses loved them so much was that most of their staff were new graduates who didn’t have a clue, so needed things spelled out to them.  His approach was to get small teams of highly competent and experienced programmers together, have them talk directly to the business and churn out applications………sound sort of familiar?

 

Very little is new in the world, Agile and Scrum seem mostly to be a formalisation of what was being done at that bank 20 years ago and the guy I talked to was simply using his imagination and experience to try to find a better way of delivering applications.

 

In 2015, Wrike reported that 38% of organisations were using Agile methods frequently, so it is likely that the majority of companies are still using Waterfall.   Both methods have experienced high profile failures and both have good and bad points, so is there a ‘best’ way of delivering projects?

 

Well after many years of witnessing huge successes and abject failures, I’d advise the following regardless whether you use Agile or Waterfall:

 

Keep it small 

Big projects go wrong, no matter whether they’re run as multiple Agile teams or as monolithic Waterfall projects.  They nearly all suffer the same fate.  Insufficient understanding of scope, risk and complexity, an obsession with paring estimates and timescale to the bone and a whole lot of politics usually leads to big cost and timescale overruns.

 

I worked on a project developing a chequing account for a bank.  We were developing it pretty much from scratch and it was a massive undertaking.  Initially it was planned to be implemented in three phases, but the bank’s management didn’t like that, they wanted it faster, so instead an attempt was made to deliver it as one monolith.  It failed.  Worse still, the whole concept of doing it faster was illusory.  By trying to deliver a massive system in one go, this actually slowed the whole thing down, because it became too big and unmanageable.

Develp systems in small chunks

 

Empower your developers

Command and control is a bad approach to managing anything.  While Agile emphasises empowering teams, the best Waterfall project managers have been doing this for years.  I’ve heard programmers in an Agile environment complain that they feel suffocated by the close monitoring of everything that they do in the daily stand-ups and irritated by their business partners who take collaboration to mean handing out orders.  I’ve also seen lots of control freaks in charge of Waterfall projects, attempting to micromanage everyone and everything.

Whatever development approach you take, people make best progress and work better when they're trusted

 

Be clear about where you are going

Waterfall tends to be better at this given that you, in theory, decide this up front.  However I’ve seen plenty of Waterfall projects with ill-defined requirements that simply run out of control.  Agile projects almost have an inbuilt tendency to meander given it’s often hard to spot when you reach the point of diminishing returns, where added functionality delivers decreasing value.

So have a clear statement of your project’s objective and make sure your requirements or product backlog gives a clear description of what is required. All of this needs to be in place before you touch a line of code.

 

Provide support from the top

All projects need support.  Companies need to recognise that a high proportion of what they do is project based.  These projects need active support.

Have a clear statement of your project’s objective and make sure your requirements or product backlog gives a clear description of what is required. All of this needs to be in place before you touch a line of code

 

Conclusion

Don’t expect that adopting one or another project methodology will be the saviour of your project portfolio…….worry more about promoting the right culture.  If you have a command and control culture or one that bullies big projects to quote to impossible deadlines and costs then you’re destined to fail.  If you don’t support your project managers and you have vague ideas about what you want your projects to deliver, then expect to be similarly cursed.

 

Gren Gale is a Project Management Consultant, author of Project Management for SMEs (and its sister edition Project Management for SMBs in North America), an expert on Project Management Software and owner of PM Results

Project Management for SMEs

 

Join our mailing list and receive our Free White Paper 'Choosing the Right Project Management Software'

 

Plus free project management, product development and procurement tips.

Thanks for subscribing - look out for the confirmation e-mail!