Friday 7 December 2012

A Passive/Aggressive Project Manager – How to deal with the Nightmare – Part 1


A Passive/Aggressive Project Manager – How to deal with the Nightmare – Part 1

You may not have been there yet (operative word “yet”), however soon or later you will be forced to work with a Passive/Aggressive Project Manager.

First you need to be able to spot passive/aggressive behaviour.  Here are some signs which should start flagging up when you are the intended “victim”.

1.     1.  Vagueness about being able to deliver and ambiguity as to their role.  This includes the inability to commit to a plan, or even a deadline to produce a plan to deliver the project plan.
a.      “I can’t deliver my plan because Person X has not produced their plan.”
b.      “I can’t put any milestones in my plan until the requirements have been signed off.”
2.      2. Endless delays – you know the feeling, one week gets delayed until two, then it’s a month and before you know it, even producing the plan is three months behind.
3.      3. Constantly changing demands or withholding information.  Been there, done that!  A passive aggressive manager will constantly change what he wants for meetings – often letting you know 5 minutes before a meeting what is needed.  Aligned with this is the instruction to print “XX” copies for a meeting starting in 3 minutes.
4.      4. Taking over meetings and subverting the purpose.  Passive/aggressive project managers will rail road a discussion into a series of complicated problems with no solution or continually trying to move the focus onto someone who has not delivered.
5.      5. “Pow wows” which become nothing more than complaint sessions.  This is particularly important when you haven’t been invited to the party as there is no way to influence the focus of the meeting.
6.      6. Non-communication – refusing to meet to review progress, continually putting off meetings to make decisions required to move forward…
Posted by at 1 comment:

Sunday 2 December 2012

programme vs project risk


Program Risk vs Project Risk: in your opinion, what are the differences? (hint: this is a trick question with no wrong or right answers).

The question is tricky because it makes some assumptions: your PMO or Program Office has reached a level of maturity such that examination of higher level risk is considered and Project Risk is standardized and effective.

I'm interested in those who have experience (even in the slightest) of considering higher level Program Risk, corresponding processes, and the ultimate ... formalization.

I want to hear your experiences and whether or not the question itself even makes any sense in your organization.
4 days ago

    Kik Piney
    Kik Piney • I am interested to know if you used the term "risk" rather than "risks" deliberately: are you talking about the global risk that is the result of the combination and interaction of the individual risks? In either case, could you please post your definition of Program Risk to avoid misinderstandings.
    3 days ago

      Dana Goulston
      Dana Goulston • Hi Kik. I use the terms "risk" and "risks" synonymously. I want to hear how PMO's handle the overall risk AND/OR risks of a given program vs how we as PM's handle a given risk AND/OR risks in a specific project or projects (which I expect is something we all know). I want to hear how some of us interpret a difference (if any of us do at all.)

      I'm not talking about the specific global risks that you mention (however your question does answer mine in a way), nor do I have anything specific in mind. I want to toss it out and see experiences and interpretations.

      However, the lack of response tells me most if not all of us haven't considered Program risk as its own entity ... for any number of reasons.

      Personally I was asked to develop separate Program level Risk definitions and processes in an immature healthcare PMO. The PMO was disbanded before any processes could be put into place.
      3 days ago

        Bruce Bozza
        Bruce Bozza • Suspect that there are several reasons for categorising a risk as program rather than project risk. For example, any risk which cannot be effectively managed within the ambit of a project must be escalated to the program level (and potentially above). Others reasons may include risks which are client facing or so significant in nature that the program elects to manage (or perhaps oversight) at that level notwithstanding that they are being managed at the project level. As a PMO we review risks/issues on a weekly basis with individual projects managers and also conduct regular programme/account level reviews. The later are also important in formally reviewing budgets.
        1 day ago

          Taras Pich, CD, PMP
          Taras Pich, CD, PMP • Project risks would roll up into Program risks. I think this fits into Bruce's comment.

          I'm trying to think of a scenario where there could be a Program risk that wouldn't impact (roll down to) at least one project. I was thinking of politics at level removed from a Project that would impact a Program, but it any of these risks, impacted a Program then they would also be Project risks.

          I don't know that there are Program only risks.
          23 hours ago

            Bruce Bozza
            Bruce Bozza • Hi Taras. All benefits realisation risks are de factor program (ie business) risks. Similarly, I would manage "opportunity" risk at the program level and only delegate down to the project level as situation warranted.
            18 hours ago

              Kik Piney
              Kik Piney • Tara, to put Bruce's reply a different way. Start from the definition of risk as an uncertain condition or event that would, if it occurred, affect the success of the endeavour. Success for a project is providing the deliverables in accordance with the triple constraint. Success for programs is creating the outcomes that have been correlated with benefits. You can therefore succeed in projects and fail in programs (great deliverables, shame about the outcomes); also opportunities (positive risks) in programs can come from how you manage the mix of projects.

              LinkedIn Groups

              1. Risk is defined as the possible opportunity or threat that can be foreseen, its impact quantified and therefor effectively mitigated.
              2. Knightian uncertainty is defined as the possible opportunity or threat that can be foreseen, but cannot be quantified. (Example: Should the EU bail out the Greeks or not? We can predict what may happen either way, but cannot quantify the effects, so we're indecisive.)
              3. Clausewitzian friction is defined as the accumulated unpredictable events that actually occur when executing plans. It can be predicted nor quantified.

              When any of these types of uncertainties threaten a single business case AND can be mitigated by a decision of the project's sponsor/board it's a project uncertainty. If the threat is to multiple business cases OR the mitigation requires more decision power, the uncertainty should be dealt with at program or portfolio level.
              Posted by Dennis van der Spoel
              Posted by at No comments:
              Subscribe to: Posts (Atom)