10 Rules of Project Management to Start Breaking  

Most of us started with the same advice. You follow the process, document everything, communicate often, and try not to rock the boat. At least that’s how it was presented in training. The books and courses gave us the picture of a well-run project and the rules of project management. One where the steps line up, the people cooperate, and risks are handled like clockwork.

That’s not what usually happens, though.

Projects have edge cases. People don’t always follow the plan. Budgets move. Priorities change. You work with incomplete information most of the time, and even when you try to “do it right,” it doesn’t always translate into progress. So some of the things we were taught? They don’t hold up.

What follows is a list of ten project management rules that sound fine on paper, but in practice, they often get in the way or fall short. As an experienced project manager with over 20 years experience, I break some regularly, others I treat more like judgment calls than hard rules. IN this article I’ll explain why breaking these rules of project management in certain situations can help you win.

Let’s start with the first one, and I think a lot of people will relate to it pretty quickly.

1. Detailed Project Plans Work on Paper, Not in Practice

“Start with a detailed project plan that covers all tasks and dependencies.”

It’s hard to argue with the idea of a well-thought-out plan. That’s something most people want at the start of a project. They expect to see a clean list of tasks, timelines, and maybe a color-coded milestone chart. At first glance, that approach looks like preparation. It makes leadership feel like things are under control. But the truth is, plans that detailed tend to fall apart the minute things start to move.

In real conditions, what usually happens is this: you build the plan, then reality changes three steps in. Something shifts upstream. A team is short-staffed. A system won’t behave the way it did in testing. Suddenly the project schedule is outdated, and no one wants to admit it. So people keep referencing a plan that doesn’t match what’s really going on. That creates more confusion, not less.

You can still plan. I do. But I stop short of writing down every task. Instead, I focus on the key pieces.

• Set the milestones
• Name the people responsible for them
• Work to understand each dependency

I leave room for change because I’ve rarely seen a project follow its original layout without some kind of shift. The goal is to support action, not to create more checklists.

Some folks still swear by full work breakdowns. If they have the staff and the time, maybe it works for them. But most of us have to be more flexible. And the more rigid the plan, the less likely it helps when problems start to come in from the sides.

2. Project Charters That Drag Momentum

“Every project should begin with a full project charter.”

Charters are supposed to create alignment. That’s the goal, or at least the reason they’re often included in project templates. In some organizations, it’s expected that every effort gets one, even the internal ones. The issue isn’t that a charter has no value. The problem comes when the time spent drafting it outweighs the benefit it brings.

For smaller efforts or things with a quick turnaround, the process of getting a charter written, reviewed, and signed off can slow everything down. You might lose a week or more waiting on feedback that never really changes the direction of the work. I’ve seen people go back and forth editing a single paragraph about project purpose, while the actual tasks are stuck in limbo. That kind of delay hurts delivery more than it helps with structure.

There’s a difference between getting agreement and getting caught in paperwork. What I’ve found helpful is using a shorter doc, something I call an approach summary. It lays out the goal, the scope, what might go wrong, and who’s involved. It doesn’t take long to draft, and it’s easy to update if things shift. That approach gives me what I need to keep work moving while still offering stakeholders a way to see the intent and give input.

For larger projects or those with outside vendors, a full charter might still be useful. But in most cases, if a project can be kicked off in less time than it takes to finalize the charter, that’s probably a sign you’re spending too long setting it up.

3. Project Kickoff Meetings That Waste Time

“Hold a formal kickoff meeting for every project.”

There’s nothing wrong with wanting to start a project on the right foot. But too often, kickoff meetings turn into scripted slide shows. People nod along, someone reads the timeline, a few questions get asked, and then everyone leaves the call without much being clearer than before.

The real issue is whether the kickoff adds anything. If the team members already know each other, and the work is well-defined, forcing a formal kickoff can feel more like an obligation than a useful step. I’ve seen situations where the kickoff slides were assembled in a rush just to meet a calendar invite deadline, and most of the time went to walking through content that everyone already reviewed in an email.

That doesn’t mean you skip it every time. But it does mean you think about what it’s for. On internal upgrades or smaller systems work, I’ll usually send a short written summary with the key points. That way, people get the details without spending half an hour in a meeting that repeats what they already read. If someone wants to talk more, we set up something separate that’s specific to their concerns.

For larger programs or anything involving new stakeholders or a high degree of complexity, an actual meeting makes sense. But it still helps to keep it focused. The goal is alignment, not presentation. If the meeting doesn’t move the work forward, it’s worth asking whether it needs to happen at all.

4. Tracking Every Task Creates Noise

“Track and document all tasks and changes for accountability.”

There’s a fine line between staying organized and micromanaging your own team. Some project tools make it easy to log every move someone makes. You can track a fifteen-minute slide change, a short Slack exchange, or a tiny fix in a config file. But just because you can track something doesn’t mean you should.

I’ve worked with teams that spent more time updating tickets than doing the actual work. Someone would fix a small issue, and then lose twenty minutes writing a status note that no one was going to read. You multiply that across a few people, and the time drain becomes real. That kind of tracking doesn’t help. It makes the team feel like their work is being managed for reporting, not for results.

I prefer to keep the focus on the things that matter. I log milestones, decision points, and major blockers. The rest lives in the conversations, shared notes, or wherever the team naturally works. Most professionals don’t need a status field to stay on task. What they need is room to think and the ability to adapt without updating five places every time something small changes.

If tracking every single item brings you clarity, and your team’s fine with it, that’s one thing. But if it starts to feel like you’re managing a report instead of leading the work, it might be time to back off.

5. Formal Change Control for Every Change Slows You Down

“All changes must go through formal change control.”

Change control has its place. On high-risk projects or anything with compliance concerns, it matters. But if you treat every small adjustment like it needs a formal process, you’re going to stall out.

I’ve been on projects where the smallest scope shift triggered a three-step review, a form, and two follow-up meetings. The effort it took to approve the change was more than the change itself. Meanwhile, the team had to sit on their hands waiting for someone to sign off on what was really a minor update. That kind of delay doesn’t protect quality. It slows momentum and frustrates people who are trying to keep things moving.

What I do now is draw a line. Major shifts still go through the right channels. But for low-risk tweaks or quick decisions, I’ll loop in the right people directly, confirm alignment, and move forward. The key is being honest about what actually needs control. If everything is treated like a fire drill, the process loses credibility.

Most projects benefit from flexibility in the small things. It lets the team respond to what’s really happening without feeling boxed in by forms. The formal review should be reserved for the stuff that actually changes the path of the project.

6. Too Much Emphasis on Listening and Research

“Start by listening deeply and conducting research before acting.”           

There’s no question that listening matters. You want to understand what your team is seeing. You want to hear concerns early and make room for input that might not surface in a status meeting. But if you’re always gathering feedback and running research loops, you can lose time that the project doesn’t have.

In theory, deep listening and strong research help you plan better. In practice, they sometimes keep people from making choices. I’ve seen projects stall out because people were still trying to gather more context before moving. You can only learn so much before you have to commit and deal with what shows up later.

What seems to work better is setting clear limits. Ask the questions. Get what the project manager needs. Look into what might impact your path. But then decide. Teams get uneasy when things drag. Momentum fades, and it becomes harder to rally people when the work finally starts. Listening has value, but so does action. At some point, the project needs a direction more than another meeting.

You can always adjust along the way. What matters is knowing when listening turns into avoiding decisions. If that happens, it’s time to shift.

7. Stakeholder Identification Without Relationship Building

“Identify and document all stakeholders early in the project.”

Just because you listed a stakeholder doesn’t mean they’re engaged. You can name them on a RACI chart. You can give them a role in your documentation. That doesn’t guarantee they’ll help you when it matters.

We have all worked on projects where someone was marked as a decision-maker, yet they never answered a message. They didn’t show up to meetings. When things hit a wall, nobody could get a response, and the entire timeline slipped. The name was there, but the relationship wasn’t. That’s what makes the difference.

A lot of PM templates emphasize identification. Find the players. Map the roles. But that’s just step one. What actually moves things forward is whether those people trust you and whether they believe the work matters. You can’t get that from a spreadsheet.

If I’m being honest, building those connections takes time. It also takes being present and not just checking boxes. You listen and follow up. You keep things from falling into silence. A real partnership gets stronger as the work progresses. The early role assignment only gives you a place to start.

8. Requirements Over Benefits

“Gather all requirements before starting the project.”

You can meet every requirement and still fail the project. I’ve seen it happen more than once. The checklist gets completed, but the end result doesn’t actually help the people it was supposed to. That disconnect usually traces back to a fixation on features instead of outcomes.

Most project briefs start with a long list. Here’s what the system should do. Here’s what must be included. Teams rush to cover every bullet, and the energy goes into hitting those marks. But in the process, the purpose can get blurry. What is the team solving? What pain is this supposed to remove?

If the only question you ask is, “Did we build it like we said we would?” you’re missing the one that matters more: “Does this actually help?”

Sometimes the fix is small. You shift the conversation from what’s being delivered to what people will be able to do differently after they get it. That’s usually where the useful conversations start.

So yes, gather requirements. Just don’t mistake the list for the goal. Your real objective is to bring value and achieve project success. The spec should serve that, not replace it.

9. Ignoring Team Assumptions

“If it’s not in the requirements, don’t worry about it.” (implied rule)

It’s easy to assume everyone’s on the same page. You say something in a kickoff, people nod, and you move on. Weeks later, you find out half the team had a different understanding than you did. And by then, it’s baked into the work.

That happens more than people admit. It’s not just miscommunication. It’s that most of us carry quiet assumptions about how the work should go. We think we’ve made something clear when we haven’t. Or we think others share our priorities, even when they don’t. It gets missed because nobody’s trying to be unclear. They just don’t realize there’s a gap.

One way to catch it is to ask people what they’re solving for. Not in a formal way. Just ask. What’s your take on the goal? What part of this feels like the most risk? If you get five different answers, you’ve probably uncovered a few hidden landmines. Better to find that out early, before time and budget get wrapped around a misunderstanding.

Assumptions grow in silence. You don’t need a workshop to fix that. You just need to ask better questions, a little sooner than you think you should.

10. RACI Doesn’t Fix Role Confusion

“Use the RACI model to define roles and prevent overlap.”

Most project templates include a RACI chart. You’ve probably seen one built out in Excel or a PowerPoint slide. Someone has Responsibility, someone’s Accountable, others are Consulted or Informed. The whole idea is to make roles clear before things get messy.

But here’s what usually happens. The chart gets filled out early, then forgotten. Or worse, it looks right but doesn’t reflect how people actually work. You’ve got names in boxes, but the team still trips over each other. Decisions get delayed. Ownership stays fuzzy. RACI didn’t prevent the confusion, it just documented it.

This doesn’t mean role clarity isn’t important. It is. But RACI isn’t magic. It’s a model. Sometimes it works. But on smaller efforts or fast-moving teams, the real clarity comes from constant interaction, not a static grid. People need to talk, shift roles in real time, and adjust without checking a matrix every time someone jumps in.

If you’re using RACI and it’s helping, good. Just make sure it’s grounded in how people actually operate, not just how someone planned the project on day one.

Conclusion: Rules Are Tools, Not Laws

Project management rules serve a purpose, but only when they match the situation. Most of what gets taught in formal project management is built for projects with high risk or lots of moving parts. Those rules are built to keep things on track. But not everything you manage will need that level of structure. Smaller projects or fast-moving teams often get slowed down by the same rules that are meant to help.

If the process adds more work than value, that’s your cue to pause. Not every change needs a form. Not every plan needs ten layers. You still need to lead the project with care, but that doesn’t mean following every step blindly. Good project managers adapt the process to fit the work, not the other way around.”

The job isn’t to follow every rule. It’s to move the work forward without losing sight of what matters.