Short answer: Most of the project management problems on the standard top-10 lists are symptoms, not causes. The real causes are five practice problems: no forcing function against scope, velocity nobody trusts, standup as status theatre, a PM who can't decide what's next, and a tool that allows every shortcut. Tools fix the fifth one; the other four are on the team. Don't buy software to compensate for the four you have to fix yourself.
Some of the typical project management problems include communication, scope creep, unrealistic deadlines, resource constraints, integration of tools, lack of clarity in ownership, stakeholder management, risk management, motivating teams and once again scope creep. Almost all articles on the challenges in project management have the same set of points in the same order.
That list is accurate. It’s not worth it. It’s a catalogue of issues that, it seems, are merely challenges to manage and not actual evidence of something more structurally rotten. The underlying issue is not six things, if your team has six of those ten. Typically, there is one or two, the rest are downstream.
This piece is the version of the lineup that would truly be shared with a team in trouble. We’ll go through five very real issues that create most of the symptoms on the standard list, the two that really are the tool’s fault, and the situations where the problem cannot really be fixed by changing anything the team is doing. The target audience comprises engineers, anchors, and founders who have taken on the PM job without having received the training.
The list everyone runs, and why it misses the point
The standard list is a Wikipedia-like compilation of symptoms. Issues with Communication Scope expansion. Deficiency. Ownership ambiguity. Problems with tools. Every one of them is real. Your team would notice each of these but deep down they suffer from a different problem you are not looking for
When a team has a clear forcing function against scope, they do not have “communication problems” about new features. A planning meeting is held where the team expresses their refusal over a new feature they have in the backlog. A team which has a velocity number no one trusts does not have "unrealistic deadlines". Although the project manager promises "we can ship in six weeks," the engineering manager makes a face, and no one has the data to settle who is right.
The standard list looks at the team like a patient in a hospital with 10 ailments and prescribes 10 cures. In most situations, only one or two systemic problems will produce six or seven of the symptoms that have been listed. When the root problem is solved, most other problems vanish. If you try to fix the symptoms individually, you’ll spend a quarter chasing your tail.
After that comes the systematic list.
Scope creep is a forcing-function problem, not a discipline problem
Whichever team member says yes ten times in a row owns the scope creep. “Can we just slip this one small feature into the iteration?” Every team has had this conversation. The team that says yes is not irresponsible. The team that agrees is moving ahead absent a forcing function.
It is a requirement that every feature under consideration must answer one specific question before it is allowed into the iteration. The inquiry is whether this aids in reaching the success metric documented during discovery. When the answer isn't a yes, the feature goes to icebox. The team takes a collective decision. A governing principle that helps shape their decisions.
When teams do not have a clear forcing function to direct them, scope creeps in at the same rate as the loudest stakeholder can demand. When you have a deadline, teams do not wonder “can we fit this in?” but instead debate “is this aligned with the success metric, yes or no?” The second interaction is less emotional and concludes in the same manner each time. The discipline starts with setting a goal for your iteration during planning, so every story request has a metric to fail against.
Tools can assist with this. When a tool has a single ordered backlog and an icebox column, the forcing function is rendered visible and is slightly harder to evade. Any tool that has 8 customisable workflows and allows the PM to quietly add stories to the iteration without having a conversation in the icebox makes the forcing function disappear. The tool’s effect is not the cause; it enhances whatever direction the team is already inclined toward.
For more information about the ceremony, please check the ground rules that keep a software project on track
Velocity that nobody trusts
Another common issue is when velocity numbers pretend to forecast but fail to do so effectively.
In the majority of teams, velocity refers to either one of the three things. We feel like we can perform twelve stories. The PM sets up a target but doesn’t decide on it (e.g., “Our velocity dropped this week, what is going on?”). Alternatively, a genuine representation of accepted narratives throughout recent cycles, utilized as a predictive instrument, disregarded universally.
Forecasts provided by teams with the initial two variants are unreliable and their managerengineer trust gap Teams exhibiting the third flavor reference forecasts confidently while avoiding velocity charts during one-on-one meetings. The cleaner framing is to treat velocity as a measure of pace, not productivity and to keep focusing on predictability over velocity when sizing the next iteration.
The solution is simple. Your velocity is the rolling average of points from accepted stories (i.e. not finished, not delivered: accepted), tracked automatically over 3 iterations, used in planning to size the next iteration, not discussed except in planning. In the course of a quarter, following this rule ensures that the team’s velocity number drifts towards honesty. If a team does not agree to it, they will keep delivering a number that means whatever the loudest person in the room wants it to mean.
Almost all generic PM tools permit teams to define how to compute velocity. By default, engineering-shaped tools ensure only accepted velocity. The tool fixes structure, and in essence, the experiment works if the team agrees to keep the number alone between planning cycles. Also worth reading: velocity is not the goal)
Standups that became status theatre
The third problem presents itself in the form of a meeting which everyone agrees is just a waste of time and yet do nothing to change this.
An effective standup meeting of 15 minutes duration allows all participants to declare their next actions, blocks and requests for help. When a daily stand-up has rotted, it looks like this instead: each person reads their list of what they did yesterday. The PM makes some notes. Nobody in the team is blocked, because nobody admits to being blocked. The meeting overruns by ten minutes. That's just a status report in disguise. The most unproductive version of the meeting.
The restrictions placed on a healthy standup determine its type of agenda, which is why we ban statuses. This won't take you more than 15 min. It can’t be a place that describes the work in detail. Anyone that doesn’t pull stories cannot be included If any constraints fall apart, the meeting turns into the thing it was meant to preempt.
If you want a deeper teardown of what a fifteen-minute meeting should actually deliver, our field guide to running a useful standup lays out the rules we hand new PMs. The Atlassian agile coach on stand-ups makes the same point in slightly more diplomatic language. Standup rot is more than just a meeting problem; it's a systemic problem as it creates secondary symptoms across the rest of the team’s work. The product manager believes they have sufficient information on the product’s status, so they do not seek out other sources. Engineers flagging blockers say the meeting is not the right forum. Due to a lack of clear next steps, stories become less and less clear throughout the iterations. Fix your standup and you may find three other “problems” disappear within two weeks.
The PM who can't decide what's next
The fourth issue is around the PM who is in the role, but not doing the core PM job. The core PM job is to maintain a single ordered backlog. The top story on that backlog is what the team should pull next.
At times, this could be a skill problem. At times, it is an issue of confidence. At times, it’s a structural issue when the project manager lacks the authority to decide what’s next owing to overriding authority of every stakeholder. The team viewpoint finds all three indistinguishable. There are fifty stories in the backlog. The sequence appears unclear. There are multiple stories in the “next” category. The team is unable to draw from the top as it does not exist.
The solution is seldom to employ a superior PM. Usually, the solution is to empower the existing PM and protect their authority from being overridden mid-iteration by every passing executive. A PM cannot do the central job without authority. You can’t be good at your job if your manager is on your back.
An instrument can automatically implement the individual arranged register. The organization has to provide the authority. More than half the cases we checked, this was the case where the team had a tool problem that was really an organisational problem in disguise. Pair this with finding the right amount of backlog refinement so the top of the stack stays small, ordered, and ready to pull.
The two problems that ARE the tool's fault
And yet, going back to the tool itself, there are two real problems.
The first failure of the tool is that it allows fake velocity. What the generic PM tools do is mark the stories done on the click of a button by the engineer and then count them as the velocity. The number rises when engineers click buttons, with zero connection to the value actually shipped. Engineering-designed tools measure velocity solely on PM acceptance. A generic tool won't help no matter how much you try, the solution is structural.
"Generic project management (PM) tools are terrible. They have so many views that it makes it impossible to see the prioritised list. Board view, list view, calendar view, roadmap view, portfolio view, and then you get three custom dashboards. Too much clutter for something which is critical to success – focus." By selecting the appropriate view, you can prevent yourself from observing the actual ordered backlog. Tools shaped by engineering impose a single canonical ordering and resist attempts to fragment it. Having multiple views doesn’t fix the confusion around priority, it causes it.
The tool fails in both instances because it wants to support every workflow instead of enforcing just one. LiteTracker includes the features that are responsible for 80% of results, while the other features are actually what slow down enterprise tools. Choosing a tool with configurability to do anything means you're definitely choosing a tool that won’t help your team do the right thing at that time.
When the problem isn't fixable
In some cases, project management challenges are the result of external decisions. Three honest cases.
The team is the wrong size structurally. In other words, two engineers cannot possibly deliver a six-month enterprise project at a quarterly cadence. The problem isn’t the tool; it’s the hire or scope. The project is going to slip if you cannot do either. A better choice here is to be honest about that early instead of pretending the next sprint planning meeting will solve it.
An agile software is exactly the wrong tool to buy for a team that doesn’t want to run agile. It enforces wrong behaviour such as iterations, velocity, accepted-only stories. Imposing the tool will create resentment not lead to better practice. If the team has not even committed to the values in the Agile Manifesto, bolting on an iteration tool just adds friction. Use an appropriate tool if you want to take on that methodology.
The organization is constantly changing its contour of what is essential. When the success metric changes every two months, the scope getting big is not the tool problem or PM problem. It’s an organization misalignment issue beyond the team’s paygrade. Purchasing new software is the most costly non-fix in this category when the real issue is a lack of executive-level commitment to a clear direction.
As a tracker company, we say all this. We don’t need to be involved, if you’re a team of four engineers who deliver quality work on a Trello board. The reason of the tool is to fade into the work, not to take over the work.
Frequently asked
What are the most common project management problems?
The common list includes scope creep, communication, unrealistic deadlines, resource constraints, ownership confusion, tool integration, stakeholder management, risk management, team building, and inconsistent processes. The honest list is shorter: no forcing function against scope, untrusted velocity, standup rot, indecisive PMs, and a tool that enables every shortcut. The standard list is largely made up of honest list symptoms.
What's the biggest problem in software project management?
Usually, scope creep without a forcing function is the biggest single one. When a team unconditionally agrees to all new features, the backlog will constantly shift, the team will miss deadlines, and they will lose confidence in their schedule. Discipline isn't the solution; it is a decider that does the decision. Does this help the success metric yes or no? Not icebox.
Why do project management practices fail?
Practices may not yield results because they end up as ceremonies. If a team conducts a stand-up, planning, retro, review and more without understanding why each one exists, they will treat all of these as an obligation. They will easily drop whatever does not earn anything back. To fix things, it is best to have only those ceremonies which pay for themselves, and run them like an engineer, not like clergy.
How do you handle scope creep?
Make sure that every new feature must answer the question whether it helps us achieve the success metric we discovered. If the answer isn’t a clear yes, it goes to icebox. The PM is in charge of the icebox, the metric for success is available to the team, and a question gets asked when a new feature emerges. The conversation becomes less intense and more consistent over time.
Can a tool fix project management problems?
A tool has the capability of fixing two of these issues: phantom velocity, by enforcing accepted-only counting; and hidden priority, by enforcing a single ordered backlog. The remaining issues in the standard catalogue of problems are mainly to do with practices and organisation, or with unsatisfactory skills. Software isn’t going to fix any of those. Acquiring a tool to substitute for a lacking PM, a lacking forcing function, or a lacking success metric is the costliest type of non-fix in this category.
What's the difference between a project management problem and a project problem?
A project problem happens as a result of something specific to the work: the requirements changed, a key engineer left, the regulator moved the deadline. A project management problem is anything that has to do with how the runs, and is systemic (no forcing function, untrusted velocity, ceremony rot, etc). Problems with a project are often unavoidable; however, a project management problem is mostly avoidable.
How do small teams avoid project management problems?
Avoid unnecessary formalities. A team of five engineers does not require a PM, or a weekly retrospective and Kanban swimlane. It's essential to have one list of stories in order, a fifteen-minute standup, and a rule to say no. Introducing additional procedures at this scale causes more complications than it fixes.
What's the warning sign that PM problems are getting worse?
It is clearest that one planning meeting runs longer than the stand up. When two week planning, which takes three hours, leaves the team more confused than before the meeting, the underlying tooling or practice is forcing manual work, which should be automated. A healthy team doesn’t display that symptom; instead, you’ll notice it when one of the above systemic problems is unresolved.
Still stuck
If your team runs iterations, the PM owns the order, and standup is fifteen minutes, then your project management is not problematic. Your team is functioning perfectly. Almost everything on the standard top-10 list will quietly disappear once those three things are in place.
LiteTracker offers the best enforcement of accepted-only velocity (as it tracks only what is accepted in real time) via a single ordered backlog in a fixed iteration cadence. Best Use Cases: if you need to enforce both “accepted-only velocity” and single ordered backlog for your iterations. Sign up for free, with unlimited users and quick import! If your team is not yet running iterations, or three engineers and a Trello board is working, save your money and skip us. We prefer that you register when there is real friction.
Regardless, repair the practice preceding the tool. The tool merely amplifies what already exists.