Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
daslog
Dec 10, 2008

#essereFerrari

Dik Hz posted:

Anyone got free PDU recommendations?

Projectmanagement.com has free webinars

Adbot
ADBOT LOVES YOU

daslog
Dec 10, 2008

#essereFerrari

Love Stole the Day posted:

Hello project manager thread, technical IC here. Have noticed a pattern in $LARGE_ORGANIZATION and would like an outside perspective on how to come up with a realistic timeline for a project:

What is the best way to deal with dependency teams (platform/infrastructure) that cause delays by ignoring requests, and only seem to move if escalated to the team's skip-skip level? When asked what happened, the most common answer is that they don't know what happened and, one time when we pushed further, that breaking SLA was inevitable because our team wasn't in their prioritization at the start of the year. We didn't even know they existed (frequent re-orgs). On the other hand, the executives are saying that the company should take a "bottom-up approach" to streamline processes, so they're clearly aware.

Because it's a $LARGE_ORGANIZATION and re-orgs happen all the time, HLDs would take a lot longer to write if we must identify all of the exact people dependencies for a given project (and even if we did, another re-org could happen during the project if surprise delays go on for too long). Since different teams have different MOs when it comes to responsiveness and their SLAs, that makes it even harder to come up with realistic Sprint estimations.

It seems the only effective strategy is to just escalate immediately after making every request and not to have any patience with anyone: to make even more noise than their other requests... but that doesn't seem healthy for anyone.

Add it to the Risk log (you do have a risk log right?) and highlight it at your next executive steering committee meeting. You won't be successful trying to fix a dysfunctional process. Make sure everyone knows about it and then escalate each of the requests after your make them.

daslog
Dec 10, 2008

#essereFerrari
IF the MTOW exceeds 20,000 lbs, THEN the program gets canceled. Base prob: 4 (Very Likely) Base Severity: 4 (Very Likely) <----- I would interpret this to mean there is an 80% chance that we can't hit the weight requirement. That seems a bit high on the probability. I'd also make the Sev a 5.




IF the radar system exceeds 1000 lbs, THEN it increases the probability the program gets canceled. Base prob: 5 (100% will happen without mitigation) Base severity: (??) <--- I'd set this up as a 'sub-risk' in my deck and the severity would be a 3 if there are other ways to mitigate the first risk.

IF the radar system exceeds 1000 lbs, THEN the program will lose $5K per pound over. Base prob: 5, base severity: 1 (Low Impact) This is fine.

daslog
Dec 10, 2008

#essereFerrari

Dik Hz posted:

A risk dependent on another risk gets the worst score of both risks.

Radar overweight 5/1.
Plane overweight 5/5.

I’m not a fan of strict %chance of happening divided by 20 = risk frequency score.

I prefer to think of it as “on a scale of 1-5, do we need to mitigate this risk?”

Dithering between a 4 or 5 because of uncertainty misses the point that without addressing that particular risk, the project won’t be successful.

I can't agree on the 4 vs 5. If I present a risk to management as a 5 for the probability that means "it's happening." 1 to 4 are "it might happen."

daslog
Dec 10, 2008

#essereFerrari

Dik Hz posted:

OK, so is your risk management strategy for a risk as described by OP any different because you scored the risk 4-5 instead of 5-5?

Initial assessments are there to flag issues and I can’t imagine not implementing risk management for a 4-5 risk. And if you’re doing risk management, all that really matters is the mitigated risk assessment.

You also get to go back and revise the risk matrix as you get more information. To try to summarize, we have a risk that has a 50% chance of happening by itself and an upstream risk that has a 100% chance of making the first risk more likely to occur. Whether that is summarized as an initial 4 or 5 is pretty inconsequential. In general, though, you always round up if you’re unsure.

If you’re in CYA mode, “I flagged it as a 5 because one component of the risk is certain to occur” is a perfectly valid position to hold.

My #1 rule of being a PM: The PM always gets blamed if something goes wrong, so always CYA :)

My strategy would be the same for either, but I'd be more concerned with the optics. If I was assigned a project with a 5-5 like this one with the consequence being that we lose the contract I would be escalating right to the C-suite with a "WTF are the idiots in scoping and contracts doing sending me a project that we can't possibly do?" because it's my rear end if I don't start making noise immediately.

daslog
Dec 10, 2008

#essereFerrari
If I'm doing my initial risk identification at the start of the project and I come up with a 5 5 risk score like distance something is very wrong. It's politics I know but what part of being a project manager is knowing how to save your career over the long term.

daslog
Dec 10, 2008

#essereFerrari

Jasper Tin Neck posted:

Preferably company-wide, but I will settle for adoption in our 800 strong division in exchange for not resigning and letting my business area finally implode on itself.

Obviously software won't magically fix things around here on its own, so what kind of training program would you recommend to get the basics of project management drilled into hapless engineers promoted into project management in an engineering consulting business?


Your doomed. Engineers that can do Project Management are also known as Unicorns or CTOs.

daslog
Dec 10, 2008

#essereFerrari
When I took the exam what I did was take the practice test every morning at 7:30 and then study the stuff that I failed. Over a month or so everything came together and I passed.

Adbot
ADBOT LOVES YOU

daslog
Dec 10, 2008

#essereFerrari
I just did my third renewal so my stuff is way out of date. I'll ask around in my team and let you know what I find.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply