The difference between good and bad software development or project management is often how an organization implements patterns and anti-patterns. The more anti-patterns used to “solve” problems, the higher the chance of failure.
But there are ways to avoid falling into these destructive management traps. Here are seven project management anti-patterns and how to stop them from infecting your organization.
What is an anti-pattern?
Before we dive into examples, we should define what is an anti-pattern.
Think of them as the opposite of a best practice. Anti-patterns are worst practices. They are common solutions to common problems that aren’t really solutions at all. They cause more issues than they solve.
Allowing them to creep into your development or managerial ranks will lead to long-term ill effects and the need to unlearn many bad habits.
Anti-pattern #1 – Cart before the horse
This happens when project priorities are the opposite of what they should be. Too many resources are allocated to project segment that is dependent on something else getting done first. Without that other part in place, the “important” work flounders and fails, wasting time, effort, budget and morale.
This anti-pattern can be mitigated by proper research, planning and consulting. Do your due diligence to discover what parts of the project are contingent on others. Relay this information to your team or client and make the recommendation to tackle priorities in an order that leads to success. This will allow for better resource allocation during the development process and a more complete product being delivered by your deadline.
Anti-pattern #2 – Death march
A management team that denies the obvious failure of a doomed project, but still requires developers to work until it’s completed, is leading their team on a death march.
Some projects will fail. And that’s ok. The problem is not recognizing this early enough to re-work the project or pivot to something that will succeed.
No developer wants to work on something that has no chance of success or adoption. Managers need to be able to cut losses and regroup before a death march if they want to maintain team morale and not waste valuable human and capital resources.
Anti-pattern #3 – The 99% rule
You’ve completed 99 percent of the work. So, the final piece should be the easiest to complete, right?
If you believe this, you are guilty of the 99% rule anti-pattern. It’s a common mistake to underestimate the time and effort it will take to bring a project that last little bit across the finish line.
Granted, in an agile development environment, this is less of an issue. But, it could affect release deadlines and schedules if estimates weren’t made accurately in the first place.
Spending more time on understanding all the work involved and creating proper (and accurate) estimates will help spread the work out more evenly and allow for better time and project management.
Anti-pattern #4 – Over engineering
I’m a big fan of KISS. No, not that KISS. I mean Keep It Simple, Stupid.
We developers are often guilty of trying to build the biggest, best, flashiest thing possible. But, on tight deadlines and budgets, project managers need to resist the temptation to over engineer a solution.
Is there an already built solution that will meet your immediate needs? Can you build something quickly and then iterate to make it bigger or flashier?
There’s no need to re-invent the wheel every time you start a project.
Anti-pattern #5 – Scope creep
Call it scope creep or feature creep, we’ve all experienced this anti-pattern. A client adds more and more requirements until the project far exceeds the initial understanding. With all these new requirements somehow being of equal importance, they must all be built now, but within the original project timeline.
This is one of the harder anti-patterns to overcome. You don’t want the client to take advantage of your team. But you also don’t want to come across as combative, lazy or not providing the level of value the customer hired you for.
Constant and proactive communication can help keep scope creep at bay. Scope the project out to a granular level and get buy in from all stakeholders. If they want to add in additional requirements, remind them of the scope and see if there’s anything that can be substituted out. If not, consider altering release schedules or adding additional teams to handle to additional work.
Anti-pattern #6 – Smoke and mirrors
Pay no attention to the man behind the curtain!
If you’re involved in this anti-pattern, it means that you are presenting incomplete features in such a way as to make them look done.
Beyond the ethical issues, this anti-pattern locks you into an ever-decreasing productivity spiral. If you couldn’t complete the required features, you’ll have to jam them into the next one, or keep putting new ones off indefinitely.
Project managers must be upfront and honest at all demos and deadlines. If you are communicating effectively throughout the sprint, there will be no surprises when the project is delivered, complete or not.
Anti-pattern # 7 – Brooks’ Law
Brooks’ Law is the Catch-22 of project management. You add more resources to increase velocity, only to see velocity decrease because you’ve added too many resources. Rinse and repeat.
Adding additional resources doesn’t automatically lead to Brooks’ Law. It’s how and where you add those resources that makes the difference.
Project managers should look to add additional teams, not just more members to existing teams. This allows for continued productive communication, more accurate estimation, team cohesion and visibility to bottlenecks or other risk factors.
Don’t be afraid of multiple Scrum teams! As a project advances, you can merge or whittle them down. But, on large projects, parse the work up into smaller units to ensure continued high-velocity production.
No matter how hard we try, anti-patterns will never truly vanish. But, with proper planning, clear and open communication and the desire to learn from your mistakes, you can stem the anti-pattern tide and manage better, more productive projects.
– Robert Winkler, project manager