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…

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

• Like
• Comment
• Unfollow
• Flag
• More

6 comments

Follow Kik

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• Like

Follow Dana

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• Like

Follow Bruce

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• Like

Follow Taras

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• Like

Follow Bruce

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• Like

Follow Kik

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

Group: PMO - Project Management Office Discussion: Program Risk vs Project Risk: in your opinion, what are the differences? (hint: this is a trick question with no wrong or right answers). 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

Accountability vs Responsibility for Getting Things Done!

So how do you get things done when you don't own the resources.. eg in a matrix organisation?

Some think that assigning accountability will resolve the problem.. 

From my perspective, accountability is important, but responsibility is the bottleneck... 

Example of responsibility is the developer who has 100 competing priorities vs a project team lead who has the accountability for only a few workstreams and may not be part of the permanent team.

This happens frequently when projects/priorities are viewed in isolation.  Steps to ensure that staff are fully booked (eg charged back to the business) usually result in key staff working overtime because the peaks and troughs of work are not smoothed - rather they create a tsunami and quality suffers (and rework/remediation is added to the forward work load). 

So back to getting the people responsible to complete on time with the quality which ensures the very minimum of rework.... and let's start at the beginning of the project because I think that different strategies are needed to cope with different types of people.

Mobilisation - in this phase, it's important to deal with ambiguities, dependencies and basically put together a puzzle of parts – some interlocking and others drifting in a sea of time (eg it could be done in a number of different  “time zones”…  Here it is important to a) get individual SME (subject matter expert) input; then b) develop a strawman and the c) put the SMEs together to ratify the programme.  Outputs are refined Business Case, Schedule, Resource plans, Design Decisions, PID, etc.  So the issue here is how to motivate SMEs – where stressing the value of their input to the programme*  is probably the best way to get participation. *Even better if the programme is a strategic necessity.

Design phase – in this phase the bottlenecks are usually complete Business Requirements, getting those requirements signed-off, completing Functional Requirements and then providing traceability between these two inputs and the test cases which will be used to ensure that the requirements have been delivered.  Getting complete business requirements is always problematic – particularly when stakeholders have different ideas.  The best mechanism I’ve found is to use “brown paper” exercises to highlight current pain points and then brainstorm how to remove/reduce them – and get these signed by everyone in the session.  Having their names as the people responsible for identifying the problems and the solution should be viewed as a career enhancing activity.  Then comes the getting sign off from stakeholders (some of which would not have participated)… here comes the stick – eg the delays in getting sign off WILL delay implementation as the development window will be squeezed or shut out altogether (additional costs in the form of contract staff not being utilised or needed many additional staff to complete on time will impact the Business Case). 

Development phase – here’s where coffee/doughnuts and anything to improve the working environment comes into play along with weekly morning “prayers”/pep talks rather than status meetings – If possible use pictures to depict progress and forward targets.  Knock down the bottle necks and knobble the competing priorities by agreeing those separately in a manner which does not distract the development team from being productive… Kind of like agreeing to not argue in front of the children.  And to do this, it takes artful negotiation and a bit of give and take.

Well that’s enough to get started.. no doubt more will spring to mind.

#pm #pmot

Open Book Management – Transparency or Folly?

Does your firm operate Open Book Management?  How transparent are management about the key drivers for the firm?  Are the strategic goals hiding in plain sight or kept behind the closed door of management, the inner circle or those “in the know”.

Many firms lay out their ambition in the public domain, eg “To be the premier service provider of xxxx for yyyy types of people/in the XXX Country”.  Cool, we get you, but that doesn’t tell us how you plan to get there, how you operate, what your values are, in whom do you invest, what is the culture of the organisation?

How does an organisation keep staff openly informed when part of it needs to move in secret – eg research & development initiatives, mergers, down-sizing, combining shared services, etc?

The tenet behind Open Book Management is that with intimate knowledge, staff will understand how daily choices affect the company.  And as you would expect, the initial focus is that the financials do not provide sufficient information to engage staff and build commitment.

Open Book Management takes this a stage further, by including key partners as part of the “in the know” inner circle about the portfolio and choices the firm will be making.  In part, this sounds intuitive – organisations will want their suppliers to deliver to their new model, they will want to eliminate wastage and maximise the return on investment.

Twenty years ago, this type of information was usually only available via spreadsheet printouts or gloss marketing materials which took weeks to produce, approve, finalise, publish.  Today, intranets, web-sites and secure “extranets” provide mechanisms to publish quasi-confidential knowledge instantaneously.

The implications are two-fold:

• Management of the enterprise portfolio needs to provide the links to an organisation’s values, commitments and objectives in order to sow and reap the business benefits.
• Communication is the vital role – upwards, downwards, sideways, all ways – consistent messages and behaviour reinforcement and recognition.

More on Open Book Management

Project Management is more than getting things done

Project Management is more than getting things done - This article is a bit contentious but makes an important point - that Adding Value is the primary function of every project.


The interesting discussion is how do you go about adding value.... Thoughts please..