A Rock n’ Roll Lesson for Software Development

John Lennon is quoted for having said:

Life is what happens to you while you’re busy making other plans

… as part of the lyrics of his 1980 single “Beautiful Boy”.

Whether the phrase originally belongs to Lennon or not is still up for discussion, and one could debate long and hard about whether this really applies to life or not. Still, what amazes me is how often this really does apply in the world of software delivery projects. So I’ll humbly take the liberty of rephrasing Lennon and say:

A project is what happens while you’re busy working on a project plan.

Not to diminish the importance of project planning, but more often than not project managers get carried away with planning.

I’m sad to say I’ve been part of projects where project planning generated almost as much documentation as the actual project did. Bear in mind, planning in itself is not added value. In fact, too much planning can sometimes cripple your project’s ability to deliver true value. Think about this, the minute you start using phrases like:

If the user now wants B instead of A, that’s a CHANGE REQUEST!!!

And all of a sudden you need approval from half a dozen senior stake holders and to review the entire 1+ year long plan to see how best to include B in scope and de-scope A and… I get tired from even mocking it. The point is this is a clear example of your steroids-pumped hulk of a project plan getting in the way of your ability to deliver true value.

Read the Agile Manifesto -yes, even if you’re still doing Waterfall, read it. You can still learn something very useful from it.

… we have come to value … Responding to change over following a plan

And just to put it into perspective, you might want to re-evaluate your project planning practices if any of the following ring a bell (some humour intended):

1. You’ve had to re-plan so often you’ve started numbering the versions of your gantt in funny ways like adding the date, time and comments to the file name -e.g. “project_plan_v0.8.a.1_the one without task X_201411041230_NEW.mpp”.
2. You have a detailed project plan that stretches beyond 6 months. As if you could tell for a certainty what you’ll be doing the next couple of weeks. Of course if you’re building the second Panama Canal a project plan for the next 2 years might make sense, but if you’re just building software and you presume to plan more than a couple of months down the line, “nothing is real”, you’re just kidding yourself.
3. When you print out your gantt diagram it makes you wish printers still used continuous form paper -just because you’re so sick of scissors and tape.
4. You have multiple 20+ slides worth of progress report decks being sent 3 or 4 times a week for everyone in the project to read.
5. Your project staff has to go to the extent of setting aside two hours of every day to fill in status reports so that the gantt chart will be as accurate as an atomic clock. Are you in the business of building software or are you in the business of reporting status?
6. The status report templates are being updated and “improved” every other day, and there are so many different versions floating around they’re causing generalized confusion and frustration across all teams.
7. Your PMO team is shunned as if they’re the carriers of a lethal pathogen. Your other teams won’t socialize with them and even avoid bumping into them in the hallways.
8. Your PMO people are constantly hunting down everyone else in the project about sub-sub-sub-task ‘X’ being one day overdue and them needing a new ETC ASAP or else the world could fall off its orbit.
9. You need an fully dedicated expert in MS Excel macro’s just to make sure you can continue to build your super-huge progress report from all the status spreadsheets your teams fill out.
10. Just the fact that you need a dedicated PMO team for one single project. I mean, what are your project managers and team leads doing then?
11. Your team leads are more concerned with not showing red in some RAG slide than with removing the actual obstacles that are causing them to be delayed -which just evidences you’re not only not embracing change, but you’re actually terrorizing people into lying about status.

If you’re a project lead and your project is in any way like this, I hate to break it to you, but your project is happening and you’re not tuned into it. You’re just playing around with your gantt chart.

I’m sure we can all agree that planning and reporting and giving stakeholders visibility of progress are all key success factors in a project, and “you may say I’m a dreamer but I’m” sure we can also agree that we can accomplish these things in much more efficient ways than the practices I’ve mentioned above.

Furthermore planning and reporting should be agile and simple enough that it should never distract your efforts or resources from the true goals at hand.

Finally, here’s my advice: Read a book on any agile methodology -a short one will suffice. Plan smaller iterations, even in a large corporate project, do iterations 4 weeks long max. Don’t put so much effort into doing overwhelmingly detailed plans for what’s going to happen more than two months ahead -chances are you’re just going to have to re-do all of that… more than once. Embrace change -It’s part of software delivery and it’s not going away.

I’m sure these lessons can apply to more than one industry but I still like to think that Lennon would have been a killer engineering lead if he had chosen software over music -and had been born a few decades later. And why not? after all, building software does rock.

Originally published at https://www.linkedin.com.