Eight project management anti-patterns and how to avoid them

Boots standing next to pile of shattered glass

Put our talent to work

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 project managers and software development teams use to “solve” problems, the higher the chance of failure. But there are ways to avoid falling into these destructive project management traps. Here are eight project management anti-patterns and how to stop them from creating bad practices within your organization.

What are anti-patterns?

Anti-patterns are the opposite of best practices. They are common solutions to common problems that aren’t really solutions at all. They are worst practices that cause more issues than they solve. Allowing them to creep into your development or project management ranks will lead to long-term ill effects and the need to unlearn many bad habits. For project management and software engineering, it’s best to solve recurring problems holistically. Finding good solutions and creating better workflows now will help save your team time and resources in the future. Here are eight common project management anti-patterns and how to avoid them.

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 a 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

Cue the Star Wars music. 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. Project 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% 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 final 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. Set and keep regular development team stand-ups to ensure timelines remain on track. 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. 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. There’s no need to reinvent the wheel every time you start a project. Project managers need to remember that design work or overcoming technical debt could add complexity or time to a project. 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? Answering these questions ahead of time can expedite the build and require less refactoring for future improvement.

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 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 can’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.

Anti-pattern #8 – Copy and paste

In software development, copy and paste programming is when a developer copies and pastes source code without debugging it first. This leads to less code readability, increased maintenance cost and reduced code reusability. In project management, “copy and paste” may look like using the same workflows and modules for two different projects. Project management workflows shouldn’t be templated. Each project contains a unique combination of requirements, technologies, processes, people, timelines and deliverables. This requires unique workflows for each new project. If you copy and paste a project plan, you risk overlooking important variables that can throw off project timelines, leading to extensive development rework, delays or even project failure.

Create streamlined workflows for project managers and development teams

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 software development projects. Our project managers and development tems know what to look for and how to avoid these common mistakes. They are available on demand to create streamlined workflows that result in projects coming in on time and under budget.
Related Posts
Scroll to Top