“We’re still working on the previous high-priority work, where does this new high-priority request fall in priority?”
“You sent over multiple hot asks with a very short delivery time, what should we consider the highest priority?”
“If everything is an emergency top priority, then nothing is an emergency top priority.”
Sound familiar?
In part 2, we discussed Colomboism, product owners with short attention spans, and an unstable and constantly shifting requirements foundation. Now, I want to discuss a new form of organizational deviance: making everything a top priority.
The root cause tends to be related to mismanagement, or lack of management or existence of a project portfolio, a misunderstanding of key development terms (a new feature is never a hotfix, and, no, the tweak to functionality that you requested isn’t a bugfix just because you thought it would be better a different way), and in some cases, making everything a high priority to get exactly what the client wants from the project team, by lying about the impact (strategic misrepresentation).
In an attempt to discover why a previous organization insisted on always submitting requests as emergency high-priority requests, a manager said “if you want to be successful, the project team needs to move at the speed of business.” To that I say, fuck you, Jack.
Especially since companies move about as fast as a kayak would trying to tow the Queen Mary.
Look, I get it, projects are meant to provide value to the company, and the time spent not implementing that project is money lost (money is power, power is pizza and all that). However, it is imperative that stakeholders understand that the money lost by delaying the work on a project now, is money saved by finishing the work of the current projects in progress.
This is something that I think affects software projects more than, say, construction, which is why it’s important to…
Explain to the Stakeholders That Building Software Isn’t Like Building a House
If I had a ha’penny for every time someone has used a metaphor that compared construction to software development, I could have fucking bought Twitter.
Software development != construction.
In software development, we have legacy code, dependencies, black boxes, and code that only runs based on the collective fear that it will take down the entire system all while somehow hacking into NORAD.
A weird tale from development. In some legacy code was a jpg. It didn’t appear to serve any purpose, it was just there. When going through and refactoring/updating legacy code they decided to remove the jpg, and it took down the phone systems. No one knows what the fuck the jpg does, why it’s there, or what it’s propping up, but there it is… forever watching.
Now let’s compare that to the construction of a new home. Every time the painters come in, they discover that painting over the graffiti of the giant cock in the master suite, the foundation crumbles.
Software is weird. Stopping work, and coming back to it at a later time, after other work has been done requires rework. The rework might not be extensive, it might only mean some quick testing, but it still requires developers to take the time to revisit the code they wrote a month back to ensure that it still works as they intended it to. This costs time and money (money is power, power is pizza, etc).
Therefore it is of the highest importance to let the stakeholders know that stopping work on the past priority of the day will require a larger investment into it, thereby negatively affecting the ROI.
Dependencies Make Development Weird
Regardless of what many people say, making updates to a bit of software is never a standalone thing. So many things need to be taken into consideration when making changes, regardless of how small you might think they are. Two seemingly unrelated updates might share a common function or bit of code.
By rapidly cycling your priorities you introduce the risk that this bit of shared code will create a merge conflict. A good developer will catch this before it becomes a problem, but even the best developer in the world can miss the overlap between the requests and inadvertently create an issue.
When Projects Become Ephemeral
The problem with the rapid cycling of project priorities is that it frequently takes place outside of the project manager's purview. Since you are at the whims of the executive fates, what’s the point?
The solution is to argue for the importance of finishing what you started. Maybe play “Finish What Ya’ Started” by Van Halen softly in the background of the meeting. I’ve heard people refer to it as pushing back or standing your ground, but this I argue is different. It’s making a point to highlight the need to have the current priority aligned with organizational strategy. That is, finishing what we’re doing now will save us money, and allow us to capitalize on that work.
As a project manager, you have a better view of what is going on now, therefore, it is on you to ensure that it is being communicated back to the decision-makers what is going on. If they still want to reprioritize everything on a daily basis, just log that work was stopped, why it was stopped, and who requested it to be stopped in your choice change management system, and move on.
Stop It Before It's a Problem
Ok… let’s talk about portfolio management.
I believe the best person to manage a portfolio is the “stop and smell the roses, take life slow,” hippy type. An underlying cause of the rapid priority cycle is stakeholders and product owners getting excited about the new hotness and doing their best Veruca Salt impression.
What do you get when your POs a brat?
Always demanding this and that
Who is to blame when it all comes undone?
Isn’t project management so… much… fun?
“I don’t think we can do that”
Getting someone who is willing to slow things down, take the time to fully consider the various work in the pipes, and organize them in a way that prevents the priorité du jour is your first line of defense. This requires restraint, patience, and the ability to see things in much more detail, beyond just the value added from the request. It turns out that when you have someone that can view things from a 10,000 ft level, arguing the importance of finishing the work in progress is much easier.
Engage the Shit Out of Everyone/Give Everyone a Seat at the Table
It is extremely difficult to make a well-informed decision when you are not well-informed.
Therefore, it is important to engage the decision-makers and get them on your side. Your hippy portfolio manager is a good place to start. Your portfolio manager can provide broad context to the decision-makers that can better guide their decisions. However, engaging only with the portfolio manager and the stakeholders/decision-makers isn’t really enough. You also want to ensure that those who are working on the product have the ability to provide insight from the team's perspective.
Whether it is a developer explaining how far they are, rework that would be required should they stop work, or where in the SDLC they are, this insight is indispensable. It also goes a long way in building trust among the team as well as organizational commitment, but that was covered in part 1 of why your team sucks.
A lot of what goes into fixing these problems is not about being combative but instead about informing, providing context, and doing your due diligence to ensure that your project team is run as efficiently as possible.
So also…
Some People are Just Assholes
I acknowledge that some decision-makers are just going to be assholes, and demand that you comply with their demands… I get it… I’ve worked with plenty of people like that. It’s an issue of organizational culture, and in instances like that, it becomes impossible to engage with the stakeholders and provide guidance to the team. You are told you have to do something, therefore you must tell the team that they have to do something, even if it is going to cause a myriad of problems.
What’s more, people like this typically will see any sort of pushback as combative insubordination, challenging their authority, deliberately undermining their position, or (as an extreme) a villainous attack on their person.
In these circumstances, the most laidback of hippy portfolio managers won’t sway the dictatorial grip the asshole decision maker has. The only thing to do is to do your best. A vital part of being a project manager is leading people. It is important that you still engage your team, explain the situation, and allow them to voice their concerns to you. The point is to protect the team as much as you can. By trying to fight the asshole, you just open up your team to attacks or revenge for being the Delta Tau Chi team of the organization.
So you are aware. This article was shared to a FB group. It sparked a lot of outrage from people who work as POs and others managing priorities 🤣😂🤣.
The number of people that was defending everything being a high priority was pretty shocking. I'm not surprised that your blog has gotten the hate that it has.