Project Management Blogs

How Much Project Management is Enough?

FEATURENOV23rdRecent resistance to implementing PM practices in an organization raises the questions, "How much pm is enough?"  "Do we need any of it at all?"

Does every project need a plan?  Yes!    

Does every project need to be controlled?  Again, yes. 

"How?" is another question. The nature of the plan, control reporting period, type of reports, etc. depend on a number of factors. 

Clearly, small projects performed by dedicated resources from the same organization unit who regularly work on projects together need a far less formal planning and control than larger projects being worked on by virtual teams from multiple organizations.

In addition, the prior success experience of the organization on projects should be considered to determine if past failures or successes are linked to project management.

When there is resistance to PM where it generally stems from fear of accountability and loss of autonomy and fear that there will be an administrative burden that will take time away from work on the project’s content. Scaling PM is a means for addressing this resistance.

Accountability

Project management is all about accountability.  Fear of accountability is tough to address. Few will readily admit to being afraid of accountability. Fear of accountability is often based on the experience or belief that they will be held to schedules and budgets that are not within their power to control.

For example if my task is to complete on Thursday and I rely on an input that is provided by someone else, then I might have a late delivery I could not control effect my performance evaluation.

Of course well educated project managers might say that schedule performance metrics must be qualified by the reasons for shortfalls.

True. But, how many clients and managers have the skill, data and desire to take a look at causes when they have hard facts in front of them.  It is more often the case that they say "You were late and I don't want any more excuses" as opposed to "I understand that you were late because your input was delivered to you late and the deadline we gave you was overly aggressive."

So we need to educate and remind everyone that a rational approach is needed. But, we should not eliminate planning and control because people do not want to be held accountable for their commitments.

Administrative Burden – How much is enough?

As for administrative burden, it is undeniable.  Project planning and control take time and effort. The amounts of time and effort vary depending on the level of formality, the tools and techniques being used and the skill of the PM.

How much is enough? A project charter with a description of the project, clearly stated measurable objectives and identification of the stakeholders and their roles and responsibilities is a must.  It could be a page or two and even be in the form of an email.  What you call it and its media and format are secondary.

An agreement regarding how the stakeholders will communicate and control the project should be in place.  In an informal setting it can be tacit and unwritten.  However, if there are disagreements about how the project is being controlled, then a more formal plan or process definition is needed.

There should be a comprehensive structured list of activities and their deliverables (a work breakdown structure) with a level of granularity that makes sense for the situation.  One week to two week task durations are a guideline for short term (one – two months out) but an initial plan with monthly milestones may be enough.  Some attention to risk is necessary.  Maybe it is not in the form of a formal risk register, but there should be some written statement of risks and their potential impact and responses. 

Target dates for at least the major activities (say about a month long) are needed.  A budget may or may not be necessary.

Regular status meetings and a report of progress against the expected target dates with a projection to the end of the project is a bare minimum for control.

Finally, some post project review with a report of its findings and recommendations is needed, whether for a single project, phase of an large project or a group of small projects.

There is no definitive answer to “How much PM is enough?”  To decide on what is needed in your situation, evaluate whether the benefits are worth the cost and risk.  When PM is applied skillfully, in a situationally appropriate way, it generally improves the probability of project success and pays for itself. When we let fear and adherence to inappropriate rigid standards drive decision making, everyone loses.

Don't forget to leave your comments below.

To Escalate or Not to Escalate? That is the Question!

A review of troubled projects reveals that the inability of the project manager or team to appropriately escalate decisions or issues is a common contributor to failure.

In some instances, the challenge is insufficient escalation.  This either results from the "superhero complex" that some project managers or teams develop (e.g. I can fix the world's problems by myself) or a lack of appropriate judgment (e.g. I can see the light approaching at the end of the tunnel, but I'm sure it's just the exit and NOT the train).

In other cases, excessive escalation can cause stakeholders and sponsors to get numb - this is the classic "Cry Wolf" effect.  When a concern emerges that truly requires attention, no one pays attention.

Like many of the soft skills necessary to be a successful project manager, there's no silver bullet that will guarantee effective escalation but here are some tips that might help:

1. As part of your stakeholder analysis, find out what their escalation requirements are.  Similar to risk bias, stakeholders are likely to have differing views on what kinds of decisions or issues need to be escalated to them for resolution and while you may not be able to tailor your approach to exactly meet these expectations for individual stakeholders this up front requirements gathering can reduce the likelihood of your being far off the mark.

2. Document escalation criteria and processes within your project's communication management plan.  Such criteria should be objective or at least be supported by examples of the types of events that merit escalation.

3. Leverage an external observer who can provide you with unbiased feedback on a situation.  Obviously you should not abuse this resource with each and every decision or issue that emerges on your projects unless a formal mentor-mentee agreement exists, but having the support of an external advisor can reduce the likelihood that your own intuition is invalid.

4. Make sure you've done some analysis.  For example, when faced with a decision or issue you can ask your team to perform a quick expected impact calculation (combining maximum impact and probability of occurrence) based on the question "What's the worst that could happen if we choose to deal with this without escalating?".

5. "Once is happenstance, twice is coincidence, three times is enemy action".  If repeated attempts to resolve an issue or make a decision within the team have failed, escalation can at least reduce the likelihood of further project impacts.

Communication is the most important project management knowledge area, and the ability to effectively escalate is a critical competency for any project manager.

Don't forget to leave your comments below!

Should PMP Recertification be Modified?

Let me begin by saying that personally I would not want to have to take the PMP exam again – but as an instructor of certification courses, the changes that have been made to the PMBOK between version 3 and version 4 are extensive.  I wonder how many, if any, of the PMPs who were certified 6 or more years ago are aware of these changes.  If we were referring to professionals in the real estate, legal or accounting professions, would we want them to continue to provide their service to us if they only had to attend meetings to maintain their “certification?”

Read more...

Project Management Advice from Popular Music

I was sitting in a project team meeting yesterday where a group of us were trying to figure out the right strategy for dealing with a difficult project sponsor.  The issue was that the scope of the project was constantly changing and we were being rebuffed by the sponsor when we tried to point out that our requirements gathering and analysis budget was already spent, yet new requirements were popping up daily.  The sponsor was saying that they need all of their requirements documented and the impacts on the solution design analyzed – which is correct; however, the sponsor is not willing to reallocate funds from the solution build budget to the requirements budget, nor is he willing to discuss adding funds to the project overall budget.        

Read more...

Lessons from the King’s Speech - How to Influence Without Authority

March9_LarsonI recently saw the “The King’s Speech,” a movie about the relationship between the stammering King George VI of England and his speech therapist, Lionel Logue. The movie begins when the future king is still the Duke of York, Albert. At first the relationship is a rocky one. Although he eventually becomes the king’s trusted advisor, Mr. Logue doesn’t begin the relationship as such. He has little to recommend him, since neither his credentials nor his social status grant him instant credibility. The disparity in their births, culture (Logue was Australian), and breeding is daunting. So how is this commoner able to help the monarch and become his life-long friend? He is a master at influencing with absolutely no authority.

Read more...

Surviving The Project Age - An Agile Framework Part 1

Part 1: The Project Age and the case for Agility

Perfection of means and confusion of goals seem -- in my opinion -- to characterize our age.

Albert Einstein

As announced in my last blog entry, this is Part 1 of a 5-part series laying out the elements of an Agile project management framework. It will discuss the context of realising projects in today’s turbulent environment, as well as why Agility has become a must for most projects. By doing so, readers not familiar with Agile will have a better understanding of what the word "Agile" really means and what it implies for organizations and people managing projects in 2011.

Read more...

Page 2 of 11