I’m just thinking about my last company where the sales guys would sell a project, kick it over the fence to the PMO, the practice leaders may or may not assign devs and other resources, depending on availability and priority (and then take them away mid project if the priority changes), then management would beat up the PMs when the projects inevitably spiraled out of control.
That’s probably why they can’t keep PMs for more than a couple years.
Also, they don’t typically have to pay the outsourcing firm for the budget overages (on a fixed price project at least).
That’s another thing that bugs me about devs. The “no definite schedule thing”. Unless you’re being asked to invent a flying car, you should be able to break your tasks down into ROM estimates. An hour? A day? A week? (and really if it’s a week, break it down into smaller tasks).
Well yes and no. It’s been a long time since I wrote code. But I get how some tasks you don’t know how long they will take until you get under the hood and tinker with it so to speak.
But from a project management view “as long as it takes” is not acceptable. You need to put estimates for the tasks that you do know the duration and call out the ones that you don’t. That why, when I go back and report to some pinhead executive, I can say “Task 123 which was already heavily buffered because it had a lot of unknowns is going to take longer than expected due to unanticipated complexity”.
I’m not in a position to second guess the developer or architect about his estimates. And indeed if I or the project sponsors were to press him on them, I would expect that he would back them up as valid, given the information he has at the time.
What I don’t expect (well I expect it, I just don’t tolerate it) is to have the devs act like prima donnas who think they can just work in a vacuum.
And making no attempt to even understand what’s behind the project being managed, or how the deliverables fit together.
I’m down on PMs right now since the last one I worked with at my company was solely a “check the box” PM who would never, ever deviate from the “agreed” plan, even after we learned that the assumptions made at the beginning of the project were not correct. I had to bring in my VP and the Chief Medical Officer to get the changes made to the project (thank gods, the CMO did get it.)
He makes me really miss the PMs I’ve known who either did code at some point, or who made a point of understanding what is happening beyond the spreadsheet.
(I’ve also been in the biz for a couple of decades. That’s how I became a Gumpy bunny.)
I’m willing to take estimates as a PM. I’m willing to take ranges. I’m willing to - after I’ve worked for you a bit - understand if you are a congential under estimator and compensate for you.
What I can’t do is take the “I don’t know” for an answer. Give me SOMETHING. Is this a four hour thing or a four week thing. Is it bigger than a breadbox? A small car? The Great Pyramid at Giza? The last one we’ll try and chunk out to get a better idea of size, and throw LOTS of disclaimers around it. That’s FINE. But its my rather sucky job (somedays) to go back to YOUR BOSS and say “the whole project is going to take three months.” And its my job to say “I’ll need the QA team around the second week in January, we will firm up when better around Christmas.” Because the QA team doesn’t need to sit on their thumbs for two weeks because some prima donna developer didn’t estimate and me, the ill informed PM, made a goddamned guess and then get “you have to get this code tested right now” thrown at them - that isn’t fair to THEM.
Anyway, “I don’t know” isn’t a proper answer. In the early stages you have to be clear about whether you want to know how long X will take, or how close to X you can get in Y time. And estimates really should be expressed as a range with an explanation of what makes the difference.
There has to be communication. Sadly, engineers are from Omicron Persei 7 and project managers are from Omicron Persei 9. They use the same words but those words don’t mean the same things.