40 Common Project Issues, Errors, & Warning Signs To Watch For
Hi Tribe -
It’s been awhile.
Hope you all are staying safe & healthy. I have not had time to think or put aside for writing in awhile. My son turning one year-old and my new role as Director of Program Management has been all time consuming. I have mad respect for newsletter authors who churn out quality writing like clockwork. I have a lot on my mind that I want to get down on “paper” so expect more writings from me soon . . . as soon as I can find the time. 😵
Happy Reading!
A Project Manager is oscillating between three modes:
Planning
Activation
Monitoring
During monitoring, we keep a vigilant eye on things to ensure projects don’t go off the rails. Do enough projects of various size and scale for long enough, you will build a list of common errors, issues, symptoms, and warning signs to monitor during project development that can cause them to go off the rails.
Below is a list of 40 common project issues, warnings, and risk I have collected over my decade long career in Technical Program Management, many that I myself have committed or catch myself in still.
Many of these issues can be fixed or mitigated against with better communication, more upfront planning work, better documentation, better engineering to product/program alignment etc. Ultimately, the solutions will vary based on organizational culture, team structures, and just who you are as a leader. The goal of this list is to make you aware of the signs so you can figure out how to react appropriately before it becomes too late (burnout or perpetual program delays, etc).
We didn’t discuss a critical dependency until midway through the project.
No written decision logs resulting in rehashing the same decisions again.
No clarity on who is a decision maker(s) despite building 5 different RACIs.
No one baked in QA/Testing into the development schedule.
Product requirements kept changing.
Every team wrote their own weekly project status.
Every step in development resulted in new discovery of how the current system actually worked.
Leadership suddenly started asking questions which meant a ton of meetings to cover topics we had discussed weeks ago.
A general ballpark gut check date was communicated as a commitment.
Despite a detailed weekly status report, we still get questions about what is the status of the program.
In weekly engineering prioritization meetings, after awhile, it’s only the Product/Project Managers who attended, engineering stop showing up.
Committed dates over next 3 quarters worth of work based on discovery/investigation on the 1st quarter.
Leadership’s response to every project risk is “can we add more people to help accelerate the work?”
We prepared the engineering leads to pushback on the roadmap commitments with senior leaders. They capitulated at the first sign of resistance and walked away with more work.
We knew there were bad bugs/incomplete requirements in the code but we pushed the project to production anyways because the engineering leader/business team didn’t want to miss the deadline. “We will fix it in the next release, we are agile; this isn’t waterfall.”
There was no slack in our schedule especially around critical milestones and testing phases.
“I spent more time managing the leaders than focusing on the engineering teams and work.”
Every decision had to be run up the chain for approval.
Team velocity just did not budge despite a lot of measuring and KPIs.
There was never any urgency even with our high impact risks at any level.
There is never enough time in a sprint to do meaningful discovery, feature work and bug fixing.
Product Managers kept making backlog prioritization without consulting the engineering teams.
Project Managers were only interested in new ETAs instead of understanding the issue.
Project Managers/Product Managers involve engineering teams after the fact.
Engineering team spends an unusual amount of time in discovery/investigation before starting any development work. They want to cover all the edge cases before starting.
They kept adding Project Managers to the project because things kept getting delayed.
It was hard to have smaller meetings because anytime we make a decision some engineering lead didn’t agree with it because they were not in the meeting.
Our main/head was always a mess and engineers didn’t want to deal with branches.
We pushed code with limited/no testing just so we could say we hit feature complete and are now in bug fixing.
Every team had a different definition of Feature Complete or Done.
Frontend implementation didn’t align with the backend implementation at integration time.
Engineering team wanted to see all the requirements written out in detail before starting any work.
Our roadmap planning always assumed incremental headcount to support the work; nothing was ever planned to present capacity only to have leadership upset about missing deadlines despite approval for extra headcount hiring.
Business Stakeholder: “We just don’t have the high class talent like Apple or Google, that’s why everything is delayed.”
“We saw the warning signs but I am not going to be the one to rock the boat.” Blame game ensues when delays happen.
APIs were published without adequate documentation or explanation. Nothing ever worked as expected.
Engineering team deviated from the proposed architecture but never mentioned it to anyone until it was time to integrate.
Frontend teams did all their testing in production where as backend teams didn’t ship anything unless tested in dev environment. More work to align testing procedures.
Project milestone entry/exit criteria never defined or unclear.
Everyone wants less meetings, slacks, emails, and “interruptions” but complaint when progress is slow around decisions.
I am curious, what things do you look for to help you determine if the project is about to go off the rails or already is? Do share your list or add something I may have missed.
Until next time 🙏🏽👋🏽!
-Aadil
Was it useful? Relevant? Actionable?