The Project Notebook

Project Management and Joint Accountability

© 2013 Ray W. Frohnhoefer, MBA, PMP, CCP


The Oz Principle was originally released around 1994, but the authors (Craig Hickman, Tom Smith and Roger Connors) felt an update was required in 2004 and also have a few sequel works that are much newer (Journey to the Emerald City, How Did That Happen?).  These books build on their original key principle – accountability.  In leadership roles such as Project Management, accountability is about assuming responsibility for actions and to be able to explain and be answerable for the resulting consequences.

This should sound familiar to project managers required to deliver project results.  Results can be achieved by looking within for cause, rather than in the actions of others. The authors suggest this is a great way to build leadership. The books are filled with great examples of how accepting accountability can pull us out of the “victim” thinking (e.g. it’s not my fault, I don’t know why this is happening to me, something or someone other than me and my actions made this happen) and achieve positive results. Some famous examples of leaders showing accountability include Jack Welch, Janet Reno, and Bill Clinton — embracing accountability helped them weather adversity and continue to get results.  Their past mistakes were left behind.

I had a recent example of this myself.  A “disruptive technology” solution was proposed by a client employee that could have diminished or even ended a long-time client relationship.  It would have been easy to “throw up my hands” and recommend going with what appeared to be an easy solution.  Instead, I looked at the problem from all angles, considered the client governance policies in place, and realized there were hidden costs in the proposed solution that would not have been discovered until the project was well down the wrong trail. I was able to put some talking points together for the client Project Director to successfully steer clear of the disruption.

To further show joint accountability, the client employee was invited to play a key role in a different approach.  There was no “blame”.  Everyone looked within and considered the best actions to create superior outcomes.

There is so much of importance in the Oz Principle for improving ourselves and our projects.  Accountability and project management complement each other. One immediate area that jumps off the page of the book is the notion of joint accountability. It’s the idea that in any team setting, when someone drops the ball, another team member is there to help put it in the goal. Many of the best practices we follow in project planning help contribute to creating an environment of joint accountability.

Pre-implementation Announcements and Messaging

Once the project charter is completed, it’s typical to get senior management to “stand up”, state some of the goals, and start the process of building the shared understanding of the work. Getting early and often messages out to the team members and other stake holders, almost like a public relations campaign, builds understanding. Where there is solid shared understanding, joint accountability can take place.

Implementation/Planning Meeting

This is the first time the identified project team is brought together as a whole to hear the objectives again and begin forming the initial project phases and requirements. Once again, clear and consistent communication about the goals and objectives brings everyone together.

Work Breakdown Structure

This is an area that many software, IT, or technology projects “skimp” with the belief it is too time consuming. This is an activity which builds capacity. Everyone works together to identify the work and understand how the work is building to meet the goals and objectives of the charter. More time spent in thinking through the work will assure all the tasks are identified and the team will know what needs to be done.

Other Planning Activities

Whether it is to develop a communications plan or a human resources plan, this is more team and capacity building activity. As common understanding of the project work emerges, the team is positioned for joint accountability.

Project Execution

Like the building crescendo of a symphony, project managers that spend time on the previous steps will have a bold and capable team. Everyone knows what needs to be done and is occupied by doing it.

The phrase “herding cats” refers to the impossibility of controlling a situation dominated by chaos. Rather than herding cats, the project manager is mentoring the team and helping with problem solving. Problem solving is not the same as moving from emergency-to-emergency (more chaos). With joint accountability, team members know what needs to be done, are doing it, and helping out others who are not helping the ball to the net. Sure there are sometimes “bumps” in the road, but the team works around them.

Creating an environment of joint accountability builds focus too — other peripheral tasks are now clearly second to meeting the promised deliverable. Now I’m sure many will scoff at the time these activities take. My assertion is that in the long run, these steps are very worthwhile. Taking some time on each will provide superior results in the long run.

It might be overly bold to say I never managed a project with lots of good planning that didn’t come in on time and on budget, but my record seems to speak for itself. So next time you are about to start a project, make sure you avoid herding cats and create an environment of joint accountability.

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

A Plan for Success OR A Recipe for Failure?

By:  Susan Peterson, M.B.A., PMP
Copyright 2013, Susan Peterson, All Rights Reserved

 This article focuses on factors that need to be addressed early in the project life cycle in order to avoid later problems.  Many times, these critical considerations are either overlooked or deferred.  If an issue seems particularly loaded with political maneuvering and ramifications, someone is bound to say, “We can worry about that later”.  Typically, the project manager will be the one who then has to deal with the deferred issues, which always get worse over time.  Let’s look at a few of those considerations that need to be addressed “now” rather than “later”.

Executive Support

Generally, a least a few senior people in an organization can be persuaded to appear at a “kickoff” event, say a few words, and then depart.  The “troops”, who have been through this scenario many times, are then left wondering if they will ever see these people again during the project.  Executive support comes in many forms, so an astute project manager defines what types of support and timing are necessary to provide the true demonstration of belief in the project.  Appearance at kickoff sessions is valuable, but both the team and all people who will ultimately be impacted by the project implementation need to see executives at important points in the project’s progress.  Examples of executive support include visible recognition of completion of interim project deliverables, occasional appearances at team meetings, and reinforcement of project goals with middle management personnel.  When a project manager guides executives through the types of support that are needed, he/she also ensures that the executives will not engage in activities that could actually harm a project.

“We Don’t Need Goals — We Need Solutions”

Goal setting is viewed by some as a real waste of time, particularly if a project has an aggressive timetable.  “We’ve all agreed on the solution, so we must agree on the goals” is a common statement made to cover the fact that there is actually much hidden discord.  Early in a project the “solution” is often framed in vague terms that lead to multiple interpretations.  For example, an organization may undertake a project to build a new corporate headquarters.  While the “solution” is a building, there are many types of structures that could conceivably fulfill that definition.  The goal that the organization really has to determine at the beginning of the initiation phase is “What do we want to accomplish with a corporate headquarters?”  Depending on the goals that are defined, the actual solution could range from not building anything to building a multi-million dollar “state-of-the-art” facility.  A common statement is “the devil is in the details”.  That statement really highlights that people have not agreed on the goals, so they will never be able to agree on the means (“the details”) to achieve disparate, undefined goals.

“Somehow Everything Will Get Done”

Project managers often are coerced to accept unrealistic project schedules, inadequate personnel, and/or insufficient budget.  They grimly dive into these types of projects knowing that the outcomes will not meet expectations.  Yet they feel that somehow miracles will happen.  If a project manager perceives that one or more of the three constraints (time, budget, and quality) is not being adequately addressed at project initiation, he/she needs to determine how the constraints can be modified upfront.  Once a project is underway, there is a perception that the constraints are not issues.  A project manager is in a far better position to address the constraints in the initiation phase with solutions than to march bravely into defeat knowing that the obstacles are insurmountable.  Upfront negotiation beats last minute wailing every time.

The bottom line to these examples is that project problems identified early in the life cycle don’t “go away”.  They need to be addressed proactively, or they will explode at some unforeseen point later in the project.

Susan Peterson, M.B.A., PMP, is a consultant who manages diverse programs and projects in both the private and public sectors for individual organizations and consortia.  She also conducts enterprise assessments of project portfolio management practices.  Prior to establishing her consulting practice Susan led major efforts for Fortune 100 organizations throughout the United States.  She teaches the Project Management Simulation capstone course in the University of California, San   Diego, Project Management certificate program and is a member of the curriculum advisory committee.  She can be contacted at

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

The Clash of the Priorities

By: Susan Peterson, M.B.A., PMP

Copyright 2012, Susan Peterson, All Rights Reserved

No part of this article may be used or reproduced in any manner whatsoever without written permission.

Project managers juggle a multitude of priorities. Often, the number and magnitude of priorities may seem overwhelming and even in conflict with one another. How project managers deal with numerous priorities can make or break a project and can directly influence the perception of the success of a project. It can be difficult to objectively apply one standard to a wide variety of priorities, but that is what project managers must do. It is especially challenging when several projects have to be managed simultaneously. The following decision criteria can aid in sorting through a mountain of priorities whether on one project or on multiple projects.

Life or Death

This criterion may sound overly drastic, but it crisply focuses one’s perspective. Unless the activity/event will doom or lead to the demise of the project (or the project manager), it is probably not a top priority item. People who have faced death and survived have been known to say after such experiences that everything else is “child’s play”.

Source of the Priority

Is the priority being driven by personal or political whim? Is the priority “driver” someone who specializes in creating crises? In these types of situations the project manager should assess the strength and importance of the priority driver as well as the impact on the overall project. Treating the cause of the priority rather than the symptomatic pressure is more effective in reducing the number and severity of high priority items. Jumping from one “top priority” item to another only encourages the drivers of the priorities and may actually prolong the agony by increasing the volume of priority items.

Conflicting Priorities

It is often only the project manager who realizes that priorities are in conflict. For example, one department involved in a project may be incentivized to complete its activities rapidly ahead of schedule without regard for quality. Another department involved in the project may actually experience delays in completing its assigned tasks due to inferior handoffs from the other department. In this type of situation it is the project manager who must educate project participants in the realities of not sacrificing the project for the benefit of a single component.

Rapidly Shifting Priorities

Sometimes priorities are changed so quickly and so often that a project manager can feel that he/she is “twisting in the wind”. When priorities shift constantly, a project manager must exercise judgment to determine if the current shift is just part of the ongoing decision instability or is actually a necessary change. This situation calls for the project manager to be the “calm in the storm” in objectively assessing the need for the shift in priorities. Otherwise, stakeholders quickly learn to bombard the project manager with urgent priority requests.

In conclusion it’s a fact of project management that effective priority management is crucial to “staying the course” through the turbulence that accompanies projects.

Susan Peterson, M.B.A., PMP, is a consultant who manages diverse programs and projects in both the private and public sectors for individual organizations and consortia. She also conducts enterprise assessments of project portfolio management practices. Prior to establishing her consulting practice Susan led major efforts for Fortune 100 organizations throughout the United States. She teaches the Project Management Simulation capstone course in the University of California, San Diego, Project Management certificate program and is a member of the curriculum committee. She can be contacted at

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Handling Project Re-work

A reader at asked:  How do I account for project re-work in the project plan? 

In anticipation of us all doing the right thing, there really isn’t any formal guideline for handling re-work in a schedule which is universal.  Every organization sets their own norms.  In fact, I’m not sure I would want to call it out as a separately tracked item unless there was an ongoing issue with re-work from a project team, which does happen.  The expectation for any properly managed project is that some tasks will come in early and some will be late for a variety of reasons, including re-work.  The end result is that you hit the mark at the end of the project, or at least come close (within 10-20%).  Perhaps the better question is: How do I keep all my projects on track?

I have used a few different methods myself in the past:

  1. After the project schedule is complete, add a portion of your contingency time to all tasks resulting in deliverables.  If re-work isn’t significant or required to be tracked separately, this is ideal and you just track the schedule and actual time spent in the plan without doing anything special.  In general, as time on the project progresses, some tasks will come in early and some will be late (for many different reasons including re-work).  In some environments (e.g. software/technology) there will be other documents such as bug tickets from which you can derive the project time on re-work if necessary. Track in a separate spreadsheet if necessary.
  2. Possibly in conjunction with #1, and if re-work tracking isn’t important, just track the rework as actual time against the original task or the QA task for the deliverable being re-worked.  Without the contingency, your performance against baseline will not be good, but you will have accurately captured the project timeline status.
  3. If re-work tracking is important to the project and your organization, add new tasks and deliverables to the project without re-baselining.  These too will be deviations from the baseline.  If the deviations become too significant, then you may want to consider re-baselining the project which will mean re-estimating all tasks going forward.

The bottom line is that estimates are exactly that — estimates.  We don’t need to tell people “no rework allowed”.  At the same time, we need to maintain the expectation that everyone is doing the right thing and trying their best to minimize re-work.  Well managed projects tend to “hit their mark” because some tasks are early and some are late.  If you are not experiencing this, there may be some issues with your estimating process or scheduling process, and you need to reflect on how to best manage that.  If this is allowed to go on for too long, you will tend to build dysfunction into the project team and the organization.  The PMBOK® Guide tells us that the result of poor quality and a lot of re-work is a demoralized and low performing team.

Another possibility for frequently missed projects is that expectation setting may need adjustment.  I’ve always set the expectation, especially on software and knowledge projects, that if you are going to be late (for any reason) that you will “go the extra mile” and put in a little overtime to bring the project back on track.  I don’t put this out up front — if someone is repeatedly missing the mark I will ask they meet this expecation in the future.  Over time, this usually helps improve the estimates and inputs into plans — after all, who wants to work nights and weekends all the time?  This is a gentle and fair way of encouraging the team to perform.

What do you think of this post?
  • Awesome 
  • Interesting 
  • Useful 
  • Boring 
  • Sucks 

Past Articles

Links and Buttons

Add to Technorati Favorites

Blogging Fusion Blog Directory

San Diego Blog News

Submit Express Inc.Submit Express - SEO Services


All opinions on this blog are those of the site owner and do not reflect the opinion of any other entity. Information on this site may contain errors or inaccuracies; The Project Notebook does not make warranty as to the correctness or reliability of the site's content. If you believe something on this site is inappropriate and should be removed, please contact the site owner at sdcapmp at aol dot com.


"PMP" is a registered mark of the Project Management Institute.


© 2010-2012 Ray W. Frohnhoefer, MBA, PMP, CCP