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..

Why Scheduling Mustn't be Allowed to Become an Extinct Science

With the emphasis on Value for Money, many organisations overlook the need for robust planning and estimation. Detailed scheduling can be daunting - even for Project Management professionals. And if the professionals can be lost at sea, how do you cater for staff whose job is not to determine gantt charts, understand the critical path or become an expert of inter-programme dependencies.

This article http://www.theicpm.com/project-management/119-planning-management/3407 highlights areas to be considered.

PPM Solutions - What to look for ....

PPM Systems have matured over the past couple of years and there are now a number of robust solutions which can be rolled out across both a global as well as Business and IT centric orientations.

Full PPM solutions need to include
- Strategic planning
- Portfolio and Project Management
- Scheduling
- Resource management
- Demand management
- Reporting
- Financial Management

Make sure you align these features to the goals of the organisation.

One important aspect which often gets overlooked is the Version Control of the data - so the ability to hold multiple variations may be a key attribute.

Up front elements to be included:

- Project Charter and Statement of Work
- Business Case
- Project Initiation Document
- Work Breakdown Structure maps Packages (deliverables) and is focused on outcomes or results rather than activities.

It almost goes without saying than any solution faces the GIGO test - Garbage In = Garbage Out. To my mind that makes user functionality, ease of use and accessibility are key attributes.

One final point....

PMO Processes need to be robust, repeatable and standardised across the organisation.

To Communicate, What to Communicate - just What are the Questions We should be Answering?

Projects live and die on it and some even thrive on the quality of their Programme Communications.

And yet they are often the last things on everyone's mind to undertake in an organised, systematic structure to maximise the impact on the office grape-vine and gossip mill.

However the equation is very simple - if they aren't working for you, then they're most likely working against you!

Obviously, using the Reporting and the key messages forwarded with Management Information wisely will help keep the wheels turning.

However there is a fundamental need to compose, craft and orchestrate messages which goes far beyond the PMO's remit. It requires the focus of every project manager to employ effective communication techniques to maximise impact.

That's not to say that the PMO can't be the engine to fire up clear communications - clarifying misunderstandings and providing guidance on how to achieve the best result using the tools and techniques they deploy throughout organisations.

The objective is to sing from the same hymn sheet, in as many different styles and with as many different verses required to get everyone humming along with you - even if they might be marching more slowly or quicker than everyone else.

So my recommendation is to flood the official and unofficial grapevines with as much juicy gossip as you can muster. Use the "Chinese whispers" to your advantage and reap the rewards of the positive impact they can have on your programme.

And when you come up with your set of questions that you should be answering, feel free to share them with me!

What do You Include in Your Portfolio of Projects?

I was recently asked what I meant when I said Portfolio Management Office. What types of projects did I include? What about all the little things that crop up over the course of a month where someone just has to get on and do them.

I hear of at least two things happening right now.

First of all, big projects are being delayed or scaled back.

Secondly, things are happening "under the table" - by breaking them down so far that they fall off the radar or just on the basis of let's just get this bit of it done and that will be good enough - like putting a plaster (band-aid) over a deep cut just to keep the dirt out.

So what? Does that matter?

There will always be a creative tension between those who are trying to "get their things done" and those who have the responsibility to juggle priorities for the organisation at large.

In an ideal world, one would not overload capacity above a certain percentage - in order to cater for career development, holidays, emergencies, etc.

When constructing your Portfolio of Programmes, it would be a good thing to make a judgement to include at least of bucket for those "little" things which just need to get done so that they can be quantified in their totality. You many even want to make them part of your competitive advantage in time....

PMO Priorities in an Economic Downturn

In the midst of the cut backs and changing priorities, many firms restructure the IT department to get more value creates strain on the PMO.  

How can the PMO maintain continuity and add value?

Key processes on whcih to focus to maintain the balance include

- Objectively measuring the Business Impacts and Benefits

- Requirements collection

- Estimation

- Scope, schedule, cost

- RAIDS and interdepencies between projects

I recommend listening to the podcast from Enterprise Leadership (http://tinyurl.com/dzk8am) Accelerating IT Initiative Despite Tough Economy - Tim Shaefer, Northwestern Mutual’s CIO

Tim relates three investment initiatives which are driving them forward.  He also relates their governance model and staffing strategy.  Many fascinating insights. Well worth a listen.

PMO - Project, Programme or Portfolio Management Office

Well, what is in a name? PMO is one of those acronyms which gets used to mean different things.

On an individual project it refers to the Project Management Office.
On a programme of work, it generally refers to the Programme Management Office (also used in some firms to denote a centralised Project Management Office function).
For many firms, it denotes the Portfolio Management Office - often organised as a matrix with a small central "hub" and individuals from various functions reporting into it (both IT and Business change managers).

Recently, there has been a rise is the usage of Change Management Office. I'll park this one for the moment as I believe it could have a different remit from a PMO.

So what does the PMO do?

Generally speaking, the PMO defines and maintains the standards and process associated with project management in an organisation. These standards can include a wide variety of processes from planning techniques to documentation structures for project deliverables. Usually they include the management reporting and supporting documentation - proect plans (baseline and updates), RAIDS (Risks, Assumptions, Issues and Dependencies) information, financials, governance, status reports, change management, and project deliverables. Many also prioritise projects and manage the resource allocations to projects.

Have I missed anything burning issues the PMO needs to cover - please post your thoughts.

If you want to read more, here the wikipedia link: http://en.wikipedia.org/wiki/Project_management_office

Welcome to All Things PMO

Welcome to the All Things PMO blog - a respository for information, links, observations, tips and techniques.

My aim is to build a community with access to a respository of knowledge to help you get the best out of your PMO - whether you are just starting out or a seasoned veteran.

Please contribute for the greater good. I think we all have something to learn along the way.

Alison