Much like it’s rarely good practice to describe what something is by detailing what it isn’t, convention would similarly dictate that it’s not always useful to persuade of the benefits of doing something correctly, by highlighting the pitfalls of doing something incorrectly.
But, this is the age of Agile, where convention is unceremoniously cast aside in favour of adapting, adopting and improving old methods in direct response to new problems as and when they arise. And one such problem that we are becoming increasingly aware of is the persistence of outdated project management tactics that do nothing but demotivate employees and cause all sorts of dissonance and delays to an otherwise promising project.
So, let’s take a look at what these common glitches are so we can all know what to avoid in the future.
The old adage that goes ‘if you fail to plan, then you plan to fail’ will always hold true. But there is such a thing as restraint when it comes to planning your projects. Far too often this stage – which, in the age of Agile should really serve only as a guide from one iteration to the next (i.e. about a couple of weeks at most) – is allocated a disproportionate amount of time from the get go. Dev teams don’t need to be tied down to the drawing room for 6 weeks before they even start coding – they just need to start coding.
Indeed, the work – and even the world – is changing so fast that even planning for 2 months ahead can prove to be futile. A better approach is to plan in small segments – perhaps just from one week to the next. This way, everything is adjustable to any unexpected changes that may will occur.
Following on from the last point, too rigid project scopes (i.e. the hows) and too rigid product scopes (i.e. the whats) can be hopelessly detrimental to a project. When beginning a project, nobody knows for absolute certain what’s going to be needed 3, 4, 5 or 10 iterations down the line – so why should a project manager (PM) insist on how something should be done right at the start? Similarly, although the client will of course know what he/she wants the end product to do, flexibility of product scope is the only way to ensure delivery of well-designed, great product, as we need to account for all the lessons that are learned along the way.
Once again, continuous risk management falls beneath the over planning umbrella. It’s impossible to account for all possible risks, as these will continuously change in line with a flexible, Agile plan and scope.
One of the most demotivating habits of over-enthusiastic PMs is the incessant need to micromanage every single tiny piece of the project. Having someone breathing down your neck the whole time you’re trying to do what you do best – your job – is irritating in the extreme and, in the end, a complete hindrance to productivity. Indeed, the invariable result of such an approach is that the offending PM has no control over anything – other than a bunch of highly peeved employees who will be resultantly more prone to making mistakes.
Even the best of us can’t keep everything that needs to be done – nor indeed everything that has already been done – in our heads all at once whilst we’re trying to concentrate on our current project. And when a team relies only on verbal communication to organise itself, things very quickly become muddled and indeed forgotten. By writing things down, all team members are able to follow the workflow, trace back what has already been achieved, and what is coming up that needs to be prepared for. See ‘5 Communication Hacks For Building Great Web Applications’.
Following on from point 5, developing clear and written communication pathways is only ever as useful as your preparedness to document all correspondence. Therefore, once communications have been written down, they need to be stored somewhere – ideally online – where all team members can access them. See ‘5 Remote Team Management Apps To Rock Your Performance’.
In many ways, having a fixed mind-set is the error that summarises all of the above points. Indeed, if we as the human race had forever had a fixed mind set, then we would never have evolved into the great community-oriented people that we are today. Indeed, we would have stopped at the wheel, and never bothered to progress to the stage of motors, automobiles and all the rest. My goodness, if we had stopped with the calculator, then we never have had the internet! It doesn’t bear thinking about.
No, development teams need to take an evolutionary lesson and be always prepared to adopt a mind-set of growth, be willing to learn new things, and thusly grow and improve and progress and evolve. Great products are made only in such ways.
To err is human, according to Alexander Pope – and I’m pretty sure that even developers qualify as being human. And that means that from time to time they’re going to make mistakes. And so too are marketers, sales teams, CEOs, and even good ol’ project managers.
And mistakes are of course fine – so long as we learn from them and do not repeat them. Indeed, the smartest amongst you won’t even need to learn from your own mistakes – you can learn from those of others. And so I refer you to ‘6 Common Mistakes Project Managers Should Learn From’ for your educational pleasure. And, if you want some more, then take a look at ‘How NOT To Run An IT Project’ to really help it sink in.
So, now we’ve got a pretty grasp of what to avoid when it comes to managing our IT projects, I suppose you’ll be asking what we should be doing instead.
Well, firstly, we recommend you read our essential guide for PMs – ‘7 Steps To Successful Project Management’.