I really really want to leave Nigeria. Job applications are going know where, everything tells me i require a right to work in the uk. But i want to try to application route first, so i want to know if my CV is okay for the UK.
I’ve been seeing a lot of posts lately from newer PMs asking things like “how do people actually survive this role?” or “does everybody feel lost all the time?” and honestly I relate to those posts way more than people probably expect.
I kind of drifted into project management accidentally. I wasn’t one of those people who dreamed about becoming a PM or studied specifically for it. In my earlier roles I just kept becoming the person organizing things when projects became messy. Somebody needed to coordinate teams, follow up on dependencies, calm people down when timelines started slipping and somehow I naturally ended up in the middle of it.
At first I thought good PMs were people who always had answers and complete control over the situation. After some years I realized most experienced PMs are just much better at operating inside uncertainty without panicking publicly.
One thing that changed a lot for me was understanding that projects rarely fail because of one giant catastrophic mistake. Usually they slowly drift off course because small uncomfortable conversations keep getting delayed. People hope issues will fix themselves. Teams avoid escalating early because they don’t want to create tension. Dependencies stay probably fine until suddenly they really aren’t.
I also learned pretty quickly that visibility matters more than perfection. Early in my career I used to disappear into problem-solving mode because I thought the best PMs quietly handled everything in the background. In reality, silence makes people nervous. Even imperfect updates are usually better than letting teams or stakeholders feel blind for too long.
Another thing nobody explained properly is how much of PM work is emotional management. Not fake positivity but absorbing pressure without spreading chaos everywhere else. Teams watch your reactions more than your words. If you look overwhelmed all the time, everybody else starts feeling unstable too.
A few other things I learned the hard way:
And honestly the biggest mindset shift for me was realizing PMs are not there to magically control everything. Most of the job is creating enough alignment and visibility so problems become manageable before they become disasters.
I still have days where I feel like I’m improvising half of this role. I think most PMs do, even the experienced ones. They just get better at recognizing patterns and staying calm while figuring things out.
Our project approvals are still handled through email chains and spreadsheets. It’s slow and easy to lose track of who approved what. Deadlines get delayed just because something is stuck waiting for sign-off.
We need a structured way to route approvals automatically.
I've been in project management for a while and the thing nobody talks about honestly is the context switching problem at scale, Managing 2-3 projects: manageable. You hold the status in your head, updates are frequent enough that you stay current. Managing 8+ concurrent projects: different category entirely. The mental overhead of knowing where every thread stands, not just what's next, but the current state of decisions, blockers, relationships. Is significant.
For experienced PMs: what does your actual context management workflow look like? Not the PM tool. The specific habit or ritual you use to stay current across everything without it becoming a second job."
I know estimates are a fairy tale, but I'm wondering
Should I ask developers to estimate Raw coding time so then I can do simple math like add focus factor + buffers
Or ask them to estimate fully done, after deployment and qa? I'm worried that this question is too loaded and that their accuracy would be more precise if they only estimated raw code.
Hey guys, I'm an engineer/lurker here who has built a new product called Stoney! I am the solo founder/engineer on this project.
I built this because requirement drift is one of those problems every dev team has but nobody has good tooling for. A requirement gets written, gets built, and then six months later something changes quietly and nobody connects it back to the original ticket. The failure mode I kept seeing: a requirement like "free tier users get 100 requests/day" starts as a Jira ticket, gets built out, and slowly drifts until different parts of your codebase enforce it differently. No alert fires. No test fails. A customer just gets a weird experience and nobody knows why.
Stoney connects the dots from ticket to code to live API. It builds a registry of the business rules your system actually enforces, watches your repos for drift, and when something breaks it shows you the PR that caused it, the ticket that authorized it, and who owns the rule.
Connect your GitHub, Jira, and Slack in a few clicks and you're running in under 10 minutes. No config files, no manifests.
Free tier is permanent, no card required. Would love honest feedback from anyone. Am I hitting the mark here or is there a gap in what you would expect to see? You can find my product at stoneydev.com
Hi everyone, I work in the AECO industry (Architecture, Engineering, Construction, Operations).
For many year I've been running projects with classic Excel, MS Project, Primavera and so on, depending on the company. You've probably been there as well, the project is running, team members, managers, external stakeholders, and endless progress reporting.
Most of us just go to Excel and PowerPoint. Excel because everyone knows it, and then jump to PowerPoint because we have to make it nice and do the full storytelling, but then we go and paste an Excel table or screenshot making the whole thing look… rough.
For the past few months, I've been developing my own set of tools. First for myself, then my wife asked for some others (she works with smaller projects in operational phase) and later I saw a post here from someone in a similar situation. That's when I decided to just share it with everyone.
I am still working on it so it is not finish, still working on documentation, but it's at a point where I'm comfortable sharing it. I built easy to understand tools for project management, operation phase and BIM or VDC.
The tools are simple ad-hoc, local-first, no account needed. You know why? Because I'm also tired of making an account for something I should be able to use once and put down.
If you're dealing with either projects or assets lifecycle management, even any industry where reporting takes your time, have a look. I'd really appreciate honest feedback.
Best of all, almost everything is Excel compatible, for you to download an continue editing.
Hi guys,
How do you study for your interviews?
I have scripts written for practice but you can tell I am reading off something like practicing.
Not even talking about “deep work” at this point. A weird amount of my day is literally just transferring context from one place to another.
Meeting happens → summarize it in Notion
Need visibility → paste parts into Slack
Decision gets made → update Jira
Client asks for recap → rewrite the same thing again in email
The information itself usually doesn’t change. Just the destination.
Feels like I spend a non-trivial amount of time acting as the integration layer between tools instead of actually thinking about the project.
Curious if this is just normal PM life now or if people here have found systems/workflows that reduce the constant copy-transfer-rewrite loop.
We sent out feedback questions to our first batch of users and this landed in our inbox.
It’s from a Project Manager who lives in back-to-back meetings all day.
His biggest pain? “Trying to remember everything I did outside of meetings.”
Meetings end. But the work doesn't. And most of it happens in the hours nobody's tracking.
Then he told us what Sherlock did for him.
"Just being able to have an 'executive summary' of my day to double check for any due outs is supremely helpful. I'm in a lot of meetings so this helps with the work outside of them."
Your notetaker knows everything about your meetings. Sherlock knows everything about the rest of your day.
Try it out yourself! getsherlock.xyz
Just need some perspective if I’m the a*hole
I am on a yearlong project as a contractor and supposed to not only PM but in effect also refereee the client and the software implementer. Both sides are to blame for how off the rails this project is: software partner massively mis-scoped it, under-resourced it, inappropriately staffed it, and made the contract a milestone-based one which I’ve never seen go well.
Client has a has a stakeholder who takes 1 month to make any decision, tries to cram as much as he can disregarding scope creep, wants to play fast and loose with what a defect v. enhancement is, and never takes my advice in terms of how long things will actually take or the risks I flag.
I KNOW the risks and LOE because I’ve been doing this type of software implementation for 6 years as a senior manager, so I’m not talking out of my a** and everything I said would happen has happened.
Client got defensive this morning when I said we need to think about only having 1 person test a batch of scripts during UAT instead of having 2-3 people check and double check each other as this is what has held up testing in the past. We are supposed to do UAT next week and sprint testing is still ongoing because he will not just let things go.
I said “Let me push back here because there’s a pattern of this happening.”
No one on the client side is holding his feet to the fire. Am I the jerk?
Basecamp still feels refreshingly simple compared to modern PM tools but we are starting to outgrow it operationally. Anyone switch from it without ending up in something overly complicated?
Change control exists. Everyone knows it. Scope still creeps.
The process isn't the problem. I've sat in rooms where the change control documentation was thorough, the intake form was clear, the approval chain was documented. And then a VP walked in on a Tuesday and described a feature that was definitively not in scope, and by Thursday the team was building it. No CR. No impact assessment. No formal approval. Just gravity. Here comes another golden calf.
This is what the literature gets wrong. The PMBOK frames scope creep as a process deficiency — inadequate requirements gathering, poor change control discipline, insufficient baseline documentation. Fix the process, fix the problem. I find that framing arresting in how completely it misses the actual mechanism.
Scope creep isn't a process failure. It's a power failure.
The change control process works fine when the person requesting the change has equal or lesser organizational authority than the people who have to absorb the cost. It stops working the moment someone with budget authority — or proximity to budget authority — decides the process is optional for them. And here's the structural problem: the people who pay the cost of that uncontrolled change (analysts, developers, QA) are almost never the people with standing to invoice it back up the chain.
The PMI's own research in the Pulse of the Professionreports consistently shows scope creep as a top driver of project failure. What that research doesn't trace explicitly is who initiates the creep. In my read of how these failure patterns actually play out, the undocumented requirement almost always has a senior sponsor attached to it. The team didn't forget to write a change request. They were never in a position to enforce one.
Jeff Sutherland and Ken Schwaber designed the Scrum framework partly as a structural answer to this — the sprint backlog is locked, the Product Owner controls the gate, scope changes wait for the next sprint. Clean in theory. But Scrum doesn't solve for the executive who calls the Product Owner's manager. The sprint boundary is only as hard as the organizational culture that enforces it.
The honest conversation teams need to have isn't "how do we improve our change control process." It's "who in this organization can actually say no to a VP, and are they on this project."
If the answer is no one, the change log is a document. It is not a defense.
Hi everyone,
I'm in the middle of a career transition from education into project management and would love to connect with practicing PMs and project coordinators for advice, feedback, and real-world perspective.
A bit about my background: I spent 10+ years in K-12 education managing complex, multi-stakeholder programs, coordinating across leadership, operations, and cross-functional teams, tracking KPIs, running data-driven reporting cycles, and leading digital transformation initiatives. I recently completed my Google Foundations of Project Management certification and have been actively applying for both PM and project coordinator roles.
Happy to connect via DM! I can also share my resume if anyone is open to a quick review.
I'm genuinely grateful for any time or insight people are willing to offer. Thank you all!
We used Trello for quite some time because it was simple and everybody understood it immediately but once projects became more complex it started falling apart. Too many boards, too many labels, too much manual stuff just to keep visibility.
Then we moved to Jira because everybody said this is what serious teams use and honestly… maybe too serious. Powerful for sure but after some months it felt like we were spending more time maintaining workflows and statuses than actually managing projects. Half the team hated opening it.
Tried ClickUp too and I wanted to like it but it just became overwhelming really fast. So many options, views, hierarchies, automations etc. Felt like everybody was building their own version of the system and after a while nobody really saw the same picture anymore.
Now I’m kind of stuck in this weird middle where simple tools become chaos when things scale, but enterprise tools start slowing everybody down. Main thing I need is: clear visibility across projects, dependencies, not too painful to update daily and enough structure without becoming process for the sake of process.
Would honestly love to hear what people here actually use long term because right now every tool demo looks amazing until real work starts happening inside it.
I'm sure you've all seen the script now...
'How do you do this' or 'How are others managing...'
A few comments get thrown in
Surprise surprise, either that same person or another account happens to have a magical solution (usually a vibe coded product) to handle this
This is annoying!
As someone that likes to see how other people are genuinely working / struggling on things - these trojan horses sadly muddy the water. You're never sure if these problems are genuine or a stepping stone into their big product reveal.
