Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
We all of a backlog of requirements and projects that we need to manage. In most cases we wait until a project is finished to assign the resources to the next project, but in some cases we must drop what we are working on and start on the highest priority project. Do you have any examples of this in your career?
Project & PMO Manager | Research & Enterprise Mentor| GFB HoldingSouth America, Brazil
Yes, resource juggling in PMO is indeed like tightrope walking, balancing backlogs, completions, and sudden pivots while minimizing disruptions. In my career managing PMOs for tech firms, one standout example was during a major client merger project. We had a team deep into developing a custom CRM integration (80% complete), but a C-suite directive came in for an urgent regulatory compliance audit due to new legislation. We reprioritized immediately: pulled three key developers and a tester to the audit team, which delayed the CRM by two weeks but ensured we avoided multimillion-dollar fines. We mitigated by cross-training backups and using agile sprints to fast-track the pivot, keeping overall portfolio velocity intact. Another instance hit during a product launch cycle at a manufacturing client. Our core team was finalizing a supply chain optimization tool when a high-priority factory shutdown loomed from equipment failure, demanding instant allocation of our data analysts and PMs to crisis mode. We dropped the tool mid-sprint, reallocating 60% of resources overnight, which pushed the launch by a month but saved production lines worth $5M. The lesson was pre-building a resource buffer via capacity planning tools like MS Project and fostering a "priority matrix" culture, where teams score demands weekly to preempt such malabarismos and reduce cancellation risks. Saving Changes...
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
It’s not ideal, but sometimes necessary. The key for me has been making the trade-offs very clear, what is being paused, the impact, and what needs to be protected before shifting resources. Otherwise, you end up affecting both projects instead of just delaying one. Saving Changes...
Stop might be too strong a word, in some cases. It's been more "put on hold" unless the project was completely abandoned. It's been kind of nice - at my last couple of employers they understood the value of stopping a project. I've worked places where it felt like every project request was accepted and every project had to be finished, whether or not it made sense to continue.
It can be a pain when priorities shift quickly and often, and it seems like a lot of companies aren't as good at pivoting as they like to think they are. However, circumstances change, new risks opportunities arise and existing work can become obsolete.
The last time one of my projects was stopped was due to 1) circumstances changed such that the planned value was no longer realistic/possible, and 2) project resources were needed for a newly prioritized project. There was still some value in completing the project, but more value in pursuing others. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Lot of times. Mainly because I was assigned to projects "on fire". But to be honest, why you are asking about that?. It has no problem to move from one to other project. Sorry if I am not understanding your point. Saving Changes...
Yes, I have encountered situations like this throughout my career. I would describe it as pausing work on an active project to address a higher-priority issue or project
While managing multiple IT projects for a release, a critical production warranty issue required immediate attention. I asked the team to pause current work, reallocated key resources and redirected their focus to the high-priority issue.
I communicated the change in priorities, timelines and business impact to stakeholders and adjusted the project plans accordingly. As a result, the team resolved the production issue promptly with minimal disruption. We then resumed the paused projects and successfully delivered them based on the revised timelines. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Constantly. Ideal? Definitely not. Justified? Sometimes yes, often no. When not justified, I believe it is a symptom of bad product management/ownership. It is not, or should not be, the PM's call as to which project takes priority, so if priorities flip-flop, it is normally due to a lack of big picture thinking by product management Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
This situation is more common than most teams admit and it is rarely a resource problem, but a governance and decision-quality issue.
Yes, I have had to stop active projects to redirect effort toward higher-priority initiatives. But the key distinction is this:
Interrupting work is not the risk. Doing it without clarity, criteria, and accountability is.
In well-governed environments, this shift is not reactive. It is structured around three questions:
• What value is at risk if we do not switch? • What value is being sacrificed by stopping current work? • Who explicitly owns that trade-off decision?
When these answers are explicit, reprioritization becomes a strategic move. When they are not, it becomes hidden cost, loss of focus, rework, and erosion of trust.
Mature organizations do not rely on heroic interruptions. They design systems where trade-offs are visible, discussable, and owned.
So yes, it happens. But the real signal is not the interruption itself, it is the maturity of the system that makes that decision necessary.
Financial Management Specialist | US Peace CorpsYaounde, Centre, Cameroon
Apr 09, 2026 5:50 AM
Replying to Luis Branco
...
This situation is more common than most teams admit and it is rarely a resource problem, but a governance and decision-quality issue.
Yes, I have had to stop active projects to redirect effort toward higher-priority initiatives. But the key distinction is this:
Interrupting work is not the risk. Doing it without clarity, criteria, and accountability is.
In well-governed environments, this shift is not reactive. It is structured around three questions:
• What value is at risk if we do not switch? • What value is being sacrificed by stopping current work? • Who explicitly owns that trade-off decision?
When these answers are explicit, reprioritization becomes a strategic move. When they are not, it becomes hidden cost, loss of focus, rework, and erosion of trust.
Mature organizations do not rely on heroic interruptions. They design systems where trade-offs are visible, discussable, and owned.
So yes, it happens. But the real signal is not the interruption itself, it is the maturity of the system that makes that decision necessary.
Yes, this does happen in real-world delivery environments, especially when governance and priorities change. However, in my experience, it works best when there is a clear prioritization framework and formal change control in place.
The key is not just switching tasks but ensuring impact assessment, stakeholder alignment, and controlled reallocation of resources so that critical work is prioritized without causing unmanaged disruption to ongoing projects. Saving Changes...
Community Champion
