Very little is new in the world

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.

Recent surveys have shown that while Agile is definitely winning, Waterfall is still around and the percentage of companies who have truly gone for Agile is considerably smaller than those that are just being a bit more Agile.     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.

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.

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.

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.

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 and an expert on Project Management and Remote Working and named as one of the top 19 Key Opinion Leaders globally in Remote Work in Who’s Who in Remote Working?

Books:-
Project Management for SMEs (and its sister edition Project Management for SMBs in North America)
The Remote Project Manager
Remote Work The New Normal