I’m a big fan of lists. Heck – show me a project manager who isn’t a fan of lists! I’m especially fond of lists that explain how not to do something. This way, I feel as though I’m learning from the expensively-gained experience of others.
The list isn’t meant to be exhaustive and isn’t meant to be in order, but I hope this list proves useful to someone, somewhere:
Mistake #1:Keep the team and the stakeholders apart – I’ve worked in some (large) organisations where the lead developers are on good drinking terms with the Directors. I’ve worked in other organisations where there has been a wall of separation between the people who have the business vision and those who actually need to build the tools to deliver that vision. In one memorable case, the only contact the team was permitted to have with stakeholders was a set of documents written by business analysts from another part of the business. Of course there always has to be a balance struck between proper use of time and the importance of the project, but communication, especially at the outset of a project, is vital.
Mistake #2: Communicate infrequently – If the project is important, people will be interested and should be asking as much as being told how the project is progressing. Frequent, early communication allows for project plans and budgets to become exposed to real life challenges and be up for discussion. Early communication allows stakeholders to see what they’re getting and reject or change it early. Frequent communication builds up an important level of trust: that the stakeholders care what the team is doing and that the team is doing its level best to deliver what the stakeholders need. This trust is a useful currency for when the challenges come later in the project.
Mistake #3: Save all your testing until the last minute – If you’re running an agile project, you’re likely to be testing every 2-4 weeks, depending on the length of your sprint. “Fail Early” is the philosophy here. If you’re doing things in a traditional waterfall manner, you’re probably hoping that there’ll be only a handful of defects revealed during your testing phase. Consider instead breaking your project into a series of mini-waterfalls that will allow your testers to get on the case as early into the development process as possible.
Mistake #4: Don’t tell a client when they’re wrong – The client has brought you in for a reason, so you shouldn’t be afraid of making suggestions on how to best set up the project for success. Of course, there are diplomatic ways of doing this, and it helps to know when to exercise discretion.
Mistake #5: Put the client on the critical path without telling them – Working in collaboration with a client means that very often, you’re dependent on them for things like servers, meeting attendance, approval etc. Make very clear up front just what you need from the client and when you’ll need it by. If you’re nervous, keep it on the risk log for regular review with the client (you’re doing that, aren’t you?)
Mistake #6: Focus on contracts not collaboration – Something unexpected always happens in a project. If things go very wrong, there’s always a temptation to throw blame around and cover your back. It’s just the human thing to do. It’s also the wrong thing to do. Both you and the client have a lot invested in a project; financially, emotionally and in terms of career. It’s in both your interests to find a way out of a problem together: fix the problem not the blame: focus on working together, rather than scoring contractual points and you’ll be much closer to a positive result for all.
Mistake #7: Mix your methodologies – Are you running this project in Agile or in Waterfall? Does everybody share the same expectations about how the project will proceed and what their responsibilities are? A common mistake for newcomers to Agile is to fix your time, scope and cost on a project, which is fine if you have contingency, but Agile doesn’t work like that. Similarly, people who have dipped a toe in the Agile water and have decided it’s not for them often take the bits they like, such as the great flexibility in accommodating changes to requirements, and try to apply this to Waterfall – this is dangerous because waterfall projects, by their non-iterative nature, don’t allow for iterative changes without some significant upheaval or nimble footwork.
Mistake #8: Just get on with it and never look back – Make sure you kick your project off well. At no other time in a project do you get such a golden chance to motivate your team by sharing the vision with them, agreeing ways of working, setting expectations and understanding risks. Simillarly, take time throughout the project (and again at the end) to look back and see how you’re all working, what to keep doing and what to do differently. Agile calls these moments retrospectives, but you can call them whatever you like.
Mistake #9: Extract every waking hour from your team – Overtime is quite often a fact of life, especially at the end of a marathon project. Overtime is demonstrated to give your team a performance boost in the short term, but carry this on indefinitely and you get burn out, a dip in quality and a loss of momentum. Swapping out burnt-out people is costly. Not to mention, it’s not very nice to put people in this position in the first place.
Mistake #10: Never, ever change your plan – Again, this is where project management is as much art as science. Be risk averse: We project managers love risk and issue logs. Change is as often as not a good thing. If a plan changes throughout the project, it’s a sign that it’s being used, understood and reflects reality. If the plan isn’t changing, perhaps nobody’s actually following it.
Well, I had quite a few more than these 10, but I think I’ll keep my powder dry for another post. Of course, I’d be very grateful for your comments and suggestions for the next 10.