It’s hard to believe that, after a number of years working with project-based teams, the greatest lessons learned are hardly ever remembered from project to project. Most of the mistakes made are avoided simply by treating your project team right, trusting a proven process to run its course, setting and managing expectations accordingly, and learning to admit when you’re wrong. And yet for a myriad of reasons — fear of delivering bad news, ineptitude of the people involved, among them — a project can swiftly become doomed.

That said, if you want the project to fail, I’ve compiled a list of some pointers, guaranteed to ruin any project to some degree. This is, by no means, an exhaustive list. If you have more, please feel free to leave a comment:

#1: Never, under any circumstances, should you share your project plan with the team. Not even your clients.
As manager of the project plan, it is your responsibility to break down all of the tasks from your project, provide estimates for each of those tasks, put them in the most logical order possible, and inform the client of all milestones and their dates. While it’s perfectly acceptable to receive input from your project team, they certainly aren’t qualified to help you out, and some would argue they can’t be trusted. Instead, always trust your gut, heart, or any other non-logical organ, withhold the details of your plan from your team and the client, and only tell them what the important dates are.

#2: Never keep your project team involved in the estimation process.
Your team should be allowed to give their task estimates once and only once, and you should never give them an opportunity to revise those estimates. While some consider this a chance to provide more informed estimates — because the requirements have changed or some other silly reason — you should think of this as hedging or second-guessing. Dismiss these feelings and move forward with what you initially got. The team will thank you for trusting their first instincts.

#3: Give unrealistic estimates for tasks, and count on the best possible outcome for the project.
Three-point estimates — best possible, most likely, and worst case levels of efforts for tasks — are really a waste of time, especially when you’re absolutely sure the project will go off without a hitch. A high-performing team with solid requirements, a kick-ass design, a proven development methodology, and a cooperative client firm in its beliefs and decisions are destined to succeed, and your project plan should reflect this reality. Therefore, always count on the best possible estimate for tasks, and rest easy knowing that the team is going to deliver.

#4: Remove any and all contingency from the project plan. Use the 24-hour shift and/or weekend days to bring the delivery date in, and never factor in any vacation days.
Because the work you’re doing is so intriguing and ground-breaking, and the people with whom you work are willing to walk through fire for you, you should count on them showing up to work everyday, bright and early, and staying till all hours of the night. Things like vacation days and weekend time with loved ones are secondary to the success of the project. Personal sacrifice of home and health is best rewarded through free, late-night meals.

#5: Once you’ve completed the project plan, it should never change.
Assuming that the tasks have been properly estimated and sequenced, once the project plan has been sent off (you know, if you’re into that sort of thing) or printed, it’s done. There is no going back on your word. Changing the project plan now is simply out of the question, even if requirements change, or if a task is, for some reason, wrongly estimated. Your project plan ceases to be a living document, an artifact worthy of comparison to the Ten Commandments.

#6: Queue up all of your issues so you can deliver them all at once and at the right time.
Never bother the client with an issue here and there, because, not only it is annoying, but also it gives the impression that there are many things wrong with the project. Instead, make sure that the issues are captured in a document, and present this to the client when s/he is in a good mood. Inform the team that they should move forward as if there were no issues, or better still, make up the resolutions to the issues if you haven’t had time to present them to the client. You will ultimately be rewarded for your proactivity and thought leadership.

#7: Always rely on your project team to go above and beyond what they’re capable of, especially over long stretches of time. Never be limited to the 24-hour workday. You can certainly squeeze more effort out of your team.
Fortunately for you, your project is staffed with superheroes. They will walk through fire for you to get this project done, and they will pour their souls into the project. Motivational speeches and talking big are almost certain to energize your team to perform at unimaginable and awe-inspiring levels.

#8: Focus solely on process, not on the people (taken from The Eight Ways to Project Management Failure).
It doesn’t matter what type of people you have on the project, so long as the process that you’ve put in place involves many, time-intensive steps that guarantee that only the right decisions and answers are given. Some people may consider this bureaucratic, but you know that it’s methodical. Your team can move forward without these important decisions, because the assumptions they make will almost certainly be aligned with what ultimately gets decided.

#9: Only hold your project team, not the client, wholly accountable for tasks.
If, for some reason, you’ve assigned tasks on your project plan to the client (shame on you), make sure you don’t follow up on those to get status updates. Because the client is completely invested in the project, you should be able to count on them to perform all of their tasks with the highest quality. Your project team, on the other hand, as high-performing as they are, need to be micro-managed to complete their tasks on-time and on-budget. You should also take the opportunity to challenge your project team to perform, by calling them out in front of the client for tasks they haven’t yet completed. Negative reinforcement is a powerful motivational technique, and you should use it often.

#10: Don’t let minor changes to scope affect your project plan. You’ll still be able to hit your dates.
The client is always allowed to change their minds on decisions, no matter how big or small. They should be considered as minor roadblocks to achieving your goal of finishing the project on-time and on-budget. While you’ve established a cumbersome process for running the project, you don’t need to do the same thing for tracking any and all changes that come up.

#11: To remove distractions and focus the team on their tasks, limit the amount you communicate.
Why pull the team away from their important tasks to have them read emails or attend meetings about project status? It’s not like any of this information is going to help them at all. Tell the team only the information they need to know, and nothing else. Over-communication is a burden that eats up valuable time, which is best spent working.

#12: Keep working in silos. Eventually, all pieces of your project will fit together nicely.
Along the same lines at #11, over-communicating to the team and letting others know what everyone else is up to is simply a waste of time. The design you have ensures that everything you’re developing is all going to work when it’s time to integrate. Besides, if there was something important that needed to be shared, wouldn’t it have been identified as an issue?

#13: Your project is special and unlike ones in the past. You should treat it as such, which means you shouldn’t rely on best practices and past performance.
Every project is different, whether you’re talking about the technologies you’re using, the people involved, or the design you’ve come up with. While you have a process in place, you shouldn’t be afraid to try new things on the project, such as writing code first and deriving requirements from there, or scrapping the project plan altogether in favor of a more organic approach to project execution. Who cares about what’s worked in the past? You’re all about the future, and your project does not fit the mold of your past endeavors. The team and the client will appreciate your fresh ideas and maverick approaches to project management, even if your peers and the industry may criticize you for not using “best practices.”