pm-lotus by Howard Vaughan

Archive for the ‘Principles’ Category

PMOs need enduring architecture too

The function and practices of a Project Management Office (PMO) lie on a continuum spanning a wide variety of designs. For example, a PMO can exist solely as a passive ‘library’ of some set of project information that it occasionally presents to management; a PMO might also be a highly active enforcer of project management methodology, play a lead role in facilitating planning of all significant projects and make recommendations to management on the optimization of resources across the project portfolio.

The success of any PMO is ultimately governed by how well it is designed and how well it fulfils its mission. The importance of the design part is often underestimated. There are plenty of failing PMOs around, staffed by well-intentioned people, but offering processes and resources poorly matched to the needs of the organization.

Four Major Constraints

Whatever the intent, the form of the PMO needs to be designed with careful consideration of four major constraints:

1—The Perceived Need

Minor issues or big problems? No PMO can succeed without the buy-in and support of the project community it serves. If that community believes project issues are mostly small, isolated occurrences and/or solvable without the overhead of a PMO, then a full analysis of the facts – hard data – will be required before the PMO mission and vision can be defined. If resistance persists, then the PMO will likely have to be designed to start small and earn its credibility progressively, in a step-by-step evolution.

2—The Project Environment

Small projects or large, complex projects? A few projects or hundreds? All local resources or often global? A cultivation or control culture? These are fundamental variables that should determine the shape the PMO. It’s surprising how often this is misunderstood. Deep knowledge of the environmental characteristics and behaviors is a vital design pre-requisite.

3—The Level of Maturity

Does the organization currently exhibit high or low levels of project management capability? Some form of maturity assessment can determine this – but choose the model carefully (see Project Management Maturity Models). An effective assessment helps define the type and form of PMO resources, products and services, and provides a key indicator of the PMO’s performance over time.

4—The Level of Executive Support

Strong, unified commitment or general disinterest? Funding and resources available or hard to get? The broader the PMO’s scope, the bigger the backing it will need. The better the design is aligned to the constraints above, the greater the chance of securing the top-down support it will need. The design itself must also appropriately address the interests of the senior stakeholders, such as the level and type of project portfolio information, and consistency of project planning and reporting.

Important Questions

PMO design needs to answer important questions, such as:

• What are the responsibilities and reporting lines of the PMO?
• What is the scope of PMO operations and authority?
• How many PMO resources and with what skillsets are needed?

Getting the PMO design right should ensure that the answers are properly aligned to the project community’s needs, thereby building a sustainable and valued component of the organization.

Stages of Maturity... depending on how you measure it

Looking for a means of assessing your organization’s project management capability? Maturity models can provide a useful frame of reference and there are plenty of models out there – home-grown in-house models, proprietary models devised by consultancies and training firms, and models developed by project management standards and certification bodies.

Look before you Leap

Unsurprisingly perhaps, not all models are created equal – some are far more useful than others – so here are a few important questions to help ensure real value is delivered:

1 – Does the model provide direct input to a capability development roadmap?

There’s no point doing a maturity assessment if it does not result in an actionable plan for improvement; a well-defined, specific, accurate development roadmap should be derived directly from the assessment model and constitute the final deliverable from an effective maturity evaluation.

2 – Are elements of project, program and portfolio management appropriately represented in the model?

For most organizations, project management capability is dependent on practices in all three of these disciplines, not just the first. Few models give adequate coverage to portfolio and program management; most lack proper process frameworks in these domains and some consider portfolio applies only at higher levels of maturity – both of which result in incomplete and misleading assessments.

3 – Are people skills and toolsets properly evaluated as well as processes?

An assessment of maturity is only valid if it includes a fair evaluation of project management awareness and knowledge (such as through interviews and surveys), its application through tools and templates, and the artifacts that result. The breadth, depth, suitability and quality of know-how, supporting tools and project documentation should all be rated across each of the project, program and portfolio disciplines.

4 – Does the model provide for appropriate discounting of non-relevant areas?

Not all organizations have the same needs; for example, deeper aspects of project planning and control may be of little importance in some research or non-complex service environments; conversely, many components of portfolio management will be unnecessary to an organization that only performs 1 or 2 major construction projects per year.

5 – Does the model assess a reasonable number of maturity attributes and capability indicators?

Too few indicators are likely to omit key areas; too many will result in data overload and an implausible development roadmap; OPM3 from the PMI is a case in point with a ridiculously impractical base model of 488 best practices.  Accurate results and effective improvement plans have more to do with striking a balance between model detail and experienced application rather than analysis-paralysis.

Shaping the Future

Maturity models, combined with their associated assessment techniques and action-oriented outcomes, can offer the best basis for shaping project environments – but only if properly designed and entrusted to experienced hands.

Much more than a Memory Jogger

Among all the tools at our disposal for managing projects, programs and portfolios, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavor, and in particular where repeatability and systematic action drive performance. Yet they are still much under-used in the planning and managing of projects.

As a good friend of mine, Nick Gogerty, recently posted in Checklists, hedge funds and human behaviour, checklists provide for better outcomes – both individual and team. And the more collective experience that goes into the creation of a checklist, the more value it will have. Well thought-out checklists are indispensable wherever there is a need for control, risk reduction, rapid response or safety – as doctors, flight crew, investors and others the world over can testify, the checklist provides efficient guidance, increased confidence and focus under stress (see The Checklist Manifesto – How to Get things Right - a great-sounding read that Nick highly recommends).

Twelve Checks for Planning

Likewise for project managers – checklists can be used for all manner of things. Where training builds knowledge, checklists facilitate application.  Here is a high level twelve-point checklist for use during project planning:

1. Have the needs and concerns of all key stakeholders been considered and resolved?
2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?
3. Has the relative flexibility among scope, schedule, resources and budget been determined?
4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?
5. Are roles and responsibilities defined and agreed upon for all project team members?
6. Has an appropriately detailed work breakdown structure been created with input from key team members?
7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimized within the project constraints?
8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?
9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?
10. Have response plans been developed for the most significant threats to project success?
11. Has a change management process been defined and agreed to by all key stakeholders?
12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?

One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist). The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instill consistency. For the converted, I’ll have more checklists in future posts.

Project management is a blend of processes and procedures, the skills and knowledge of the project community, and tools for assisting with the application of process and knowledge. Good project management is when these three are properly tailored to the needs of the organization, its projects and their teams.

How It Goes Wrong

Corporate initiatives to improve project management sometimes fall short of their goals when these three elements are (a) incomplete, (b) not customized, and (c) treated in the wrong order. For example:

(a)    Training is conducted in process but no tools are provided for follow-up application
- a sure way to minimize training ROI

(b)   Training is conducted in processes that are too generic, too lightweight or too onerous
- very common, leaves PMs to figure it out for themselves

(c)   Project managers are given project management tools without prior training in process
- the “seduction of software”, usually results in poor quality information and plans that are plain wrong

It’s a repetitive scenario and goes some way to explaining the plethora of statistics on failed projects and generally poor project performance.

Right Focus, Right Sequence

The swiftest and most effective way to raise the bar of project management capability and performance is to ensure process, people and tools are treated in an integrated way with appropriate focus on each at the right time. Here’s how:

1. Define a process that fits the organization’s projects and culture
   (proper tailoring is critical to ensure buy-in and long term success)
2. Provide training in this process
   (we’re talking lifecycle here, not PMBOK knowledge areas)
3. Follow-up immediately (even simultaneously) with hands-on tools training
   (custom templates and project management software)
4. Then finally, ensure that support structures are in place
   e.g. a PMO and coaching, to embed the disciplines and practices for the long term.

Done right, it’s a recipe for sustained success.

Projects exist in dynamic environments, where change and risk are the only constants and where the delivered outputs are dependent on a team of imperfect individuals. Which is why – whatever the customer may have been told – projects do not carry guarantees. This reality is what I call the Fifth Law of project management.

Success and stakeholder satisfaction depend on a trio of crucial enablers – competence, commitment, and communication. Respecting all the preceding laws will count for nothing if this threesome is lacking in some way, both at the project manager level and at the team level.

Competence

First among our three equals, competence is what gets the work done right. It is founded on knowledge of concepts and methodology, embedded through hands-on experience, and evidenced by the quality of a project manager’s actions (how they lead and manage), artifacts (such as plans) and, to a far lesser extent, accreditations (think PMP, PRINCE2).

Commitment

Excellence in any field has to be worked at and earned. Natural talent helps of course but to be really good at something, to be recognized and respected, plenty of dedication and passion are essential. Commitment is not hard to detect – it does mean putting in those extra hours but its as much about right focus and attitude.

Communication

Great project managers are outstanding communicators. I think of outstanding to mean mastery of multiple modes of expression – spoken, written or visual – in combination with exactly the right mix of human skills and behaviors for interacting with both stakeholders and team. Done well, its reflected in a team that exudes its own buzz – look for healthy relationships, confidence and humour.

The Core of Success

The right combination of competence, commitment and communication is an energizing force for the project, its customers and its contributors. It is at the core of project success and drives stakeholder satisfaction.

Want to do a quick pulse-check of your project? Start with an honest appraisal of the 3Cs – competence, commitment and communication – and do it for both the PM and the team.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

Plans are not crystal balls. They are at best a logical and reasonable perspective of the future but no more. Every project involves uncertainty and uncertainty implies risk. And there is no such thing as a risk-free project. I call this the Fourth Law of project management.

All of which has a serious implication for project managers – the need to properly account for risk. The fact that plans are incomplete views of the future means they are always at least slightly wrong. Even if we correctly identify all the tasks and activities to be performed, errors will always exist in assumptions, duration and work estimates, task dependencies and so on.

Most project managers appear to ignore most risks (witness the lack of risk readiness as evidence) . Yet threats can and do suddenly materialize. But sudden does not necessarily mean unpredictable. Experience and a little structured thinking can expose potential threats that we can get ourselves prepared for:

5 Essential Steps to Managing Risk

1 – Get Prepared

• Determine how complex your project is and how much unmanaged uncertainty you (and the project sponsor) can tolerate, i.e. how important is risk management for your project? Then decide on the process you will use and brief your core team accordingly (risk management is not a solo effort).

2 – Identify Risks

• Review project documentation – business case, SOW, charter, plans (WBS especially) and assumptions to seek out sources of uncertainty, potential error and change. Wear the hat of Murphy – “If it can go wrong, it will go wrong.” Remember, this involves core team members, not just the PM.

3 – Assess Risks

• Evaluate each risk for (a) the likelihood of the risk occurring and (b) the potential impact to the project if the risk does occur. Rate the severity of each risk on these two dimensions. High likelihood and high impact means for those risks at least, response plans will be a necessity.

4 – Develop Risk Response Plans

• Evaluate alternative response strategies. Ask these questions: How could you avoid the risk? How could you reduce likelihood? How could you reduce impact? How could you transfer the risk to another party? Could you accept the risk with a just-in-case contingency or backup plan? If so, how would it work?

5 – Monitor Risks

• As the project progresses, risk monitoring should be a regular item on the agenda, week after week. Have any risks occurred? Are the response plans working? What has changed that might cause new risks?

These are the essentials. Large complex programs will take these steps to a very deep and sophisticated level. But even the simplest of projects will benefit from the same basic steps. Scalability, as ever in project management, is the key.

Here’s a good way to think about all this-

Ignoring project risks is the first and biggest risk to the project.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

The interdependence of truth and trust is a powerful force in projects. When both are prominent, we have a strong basis for effective team dynamics – a key ingredient of project success. Overlooking, ignoring or concealing certain realities inhibits team cohesion and severs trust – as sure as the sun rises. I call this force the Third Law of project management.

Creating an environment of truth helps build trust. This means straight talk, smart leadership and attention to good process. It also means reinforcing positives and not holding back on bad news. (Pop quiz: What’s worse than giving your sponsor bad news? Answer: Giving bad news late).

15 Truth Checks

Here are a few checks to test whether important project realities are being detected, acknowledged and acted on:

• Has a trustworthy process been used to plan and manage the project?
• Is project progress being tracked and reported accurately?
• Are team member status updates consistently submitted in a timely fashion?
• Are issues being aggressively managed?
• Are risks being reviewed at each progress review meeting?
• Are new risks being proactively identified and managed?
• Is outstanding performance being acknowledged, directly and publically?
• Is under-performance being dealt with effectively?
• Are people rewarded for behaviors that promote effective teamwork?
• Have gaps in expertise or credibility been identified and resolved?
• Is the team aligned with a common sense of purpose?
• Are morale and commitment being nurtured proactively?
• Have conflicts been acknowledged and addressed effectively?
• Are team members executing, communicating and reporting as required?
• Is a flexible leadership style in evidence, building trust across individuals and cultural differences?

Promoting open communication and instilling a sense of shared purpose are the starting points for any effective collaborative effort. But they need to be backed up by solid process and savvy leadership. Managing the project includes monitoring both the project and the project environment. It involves responsiveness to the unexpected in both project and human performance. Acknowledge the truth or face the consequences.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

This might have been alternatively titled “Questions we are Occasionally Afraid to Ask”. Here’s the situation:

You’ve been appointed to project manage a new initiative. You know that effective project sponsorship is a critical success factor and so you set up a meeting with the project sponsor.  You want to be sure you’re starting out with the right kind of backing. The sponsor wants to discuss the budget (or maybe golf) but first, you have some big questions you need answers to…

1 – Do you understand your role?
Its a fact – many project managers I meet complain that their sponsor has little idea about their role and responsibilities. You may need to help them out here.

2 – Do you know what you want?
There’s not much more frustrating than a sponsor who isn’t sure about what should or should not be included in the project. A fuzzy sponsor means you could be in for a long road trip of about-turns – do, undo, redo, …

3 – Can I count on your support?
Or more specifically – will you truly champion our project? This means advocating the project at higher levels, helping maintain visibility and interest in the project with key stakeholders, providing adequate funding and obtaining resources.

4 – Will you be available?
No doubt about it, sponsors are typically busy executives. This means their time is limited and they may be hierarchically or geographically remote. You DO need those face-to-face meetings. Lock them into their calendar.

5 – Can you give me clear priorities?
What are the primary project objectives? Which is least flexible – schedule, scope or resources? (Hint to sponsor- you can choose only one). Which is most flexible? Why?

6 – Do you understand that project management is a discipline?
In pushing to ‘just get it done’, countless projects ignore the importance of proper planning and systematic tracking… and pay a high price. A sponsor who doesn’t appreciate this means we’re already in trouble.

7 – Do you know what a solid project plan looks like?
The sponsor has to approve the plan that lays out what will actually be done- so it might make sense to ensure they actually have an understanding of what a good plan looks like. If necessary, give them a Plan Review checklist and an ‘Executive Briefing on Tactical Planning’ (so they know a WBS from a critical path).

8 – Will you inspect what you expect?
Not much point in a sponsor’s list of expectations if the relevant questions are never going to be asked. Generating information, reports and updates that don’t get reviewed is a fast track to morale hits and trust breakdown.

If the sponsor answered these questions correctly, you’re likely to be in good shape. (Hint for sponsors- the correct answer is “Yes” to all questions). If not, then you just identified some additional risks to the project…

Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

The consequence of a lack of detail is a project suicide spiral:

Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
Present bad news to customer.

Breakdown Checks

Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

• Ensure tasks are small enough so that-
  • Estimates of effort and duration are as accurate and credible as possible
  • Task durations are typically no greater than the time between progress updates
• Define explicitly what ‘done’ means-
  • Especially for any task that is unfamiliar, complex or difficult to break down
• Assign a single owner to each task-
  • Have them verify that the expected workflow minimizes likelihood of any missing tasks
• Use a checklist of often forgotten tasks-
  • e.g. meetings, defect resolutions, reviews and approval cycles.

They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

Not so clear

Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

Clarity Checks

The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

• Are deliverables defined with clear boundaries?
  • Are there detailed and explicit descriptions of inclusions and exclusions?
• Are completion and acceptance criteria clearly stated for each deliverable?
  • Do we know what “done” looks like for each deliverable?
• Are tasks defined at an appropriate level of detail?
  • Are most tasks in the range of 4-40 hours of duration? (a useful guide for most projects)
• Are task outputs tangible?
  • Have the outputs been agreed upon by their owners and dependents?
• Is progress tracked at task level?
  • Is evidence of progress validated before being reported upward?

Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)