Skip to main content

Author: George Pitagorsky

George Pitagorsky, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. He is a coach, teacher and consultant. George authored The Zen Approach to Project Management, Managing Conflict and Managing Expectations and IIL’s PM Fundamentals™. He taught meditation at NY Insight Meditation Center for twenty-plus years and created the Conscious Living/Conscious Working and Wisdom in Relationships courses. Until recently, he worked as a CIO at the NYC Department of Education.

Status Reporting, Clarity and Accountability

Written by George Pitagorsky on . Posted in Articles. 4 Comments on Status Reporting, Clarity and Accountability

FEATUREAug29thThis article explores the formal reporting that is a foundation for managing by accountability, particularly in large complex projects and programs. 

There is a naming issue.  Some people use the terms progress, performance and status reporting interchangeably.  Technically, a status report describes a point-in-time.  A progress report looks at trends and estimates to completion.  Performance reporting combines the two and brings attention to performance. The names are important academically but in the end they don’t matter.
More important, is the issue of taking the time and effort to prepare, publish and make use of performance reports.  Where candid and meaningful reporting is relatively new or has been ineffectual, there may be significant resistance.  Senior management must value performance reporting enough to motivate performers and managers to track and document their performance and regularly produce reports.

Looking Forward

The key point is to combine status, progress analysis and projections for use in tracking progress and making sure that stakeholders have clarity about how to manage the project going forward. 

The principle focus in any project is on answering questions about what to do next and why.  Project managers want to be able to plan next steps while considering prior expectations, the current state, resources and scope.  Project reports become an audit trail that can be used for learning from past experience.  Project reporting requires that performers step back from the action to reflect.

Managers also want performance reports to give information and insight into how performance can be improved and where improvement is needed most.  Effective reports motivate performance by keeping the focus on what needs to be done and by creating transparency and accountability.

The Recipients

Who are the recipients and, hopefully, readers of the reports?  This important question must be answered to fulfill the readers’ needs and preferences.

In any substantial project there are multiple levels of interested parties.  Reports to managers, executives and other stakeholders must show the big picture – the entire initiative, program or project – and its current state in a page or two, including meaningful graphs and tables.  Some stakeholders want only a one liner; a short paragraph or just a name and a traffic light. 

Performers create detailed status reports or provide information at a task level to enable higher level reporting.  Project performers, who know very well what is going on directly around them, get to see the big picture and where they fit in it. Performers can look at documented details to better understand the impact of what they do, how they are performing and how they can improve. 

Levels of Detail

Ideally, higher level reports with broader perspectives are structured and coordinated with lower level reports so that readers can easily get a more detailed picture of a specific part of the project, if they choose to. 

Each stakeholder should have a clear understanding of his/her role and how it relates to the responsibility to provide performance data and create and use performance reports and at what level of detail.

The content of a status report should be presented in levels of detail, mapped to the projects work breakdown structure, deliverables or activity list.  The report addresses scope, time and cost.  These three represent the traditional Performance Measurement Baseline.  Scope, time and cost are objective and quantifiable.  Their current state can be compared with a baseline.  The project plan is the baseline.  Regardless of the level of detail, report content must reflect the plan. 

In general, a status report should contain the following (with activities or tasks from the project plan at an appropriate level of detail for the report audience):

  • Accomplishments – activities completed in the report period
  • Activities planned to be completed but not accomplished with reasons and expected completion dates
  • Exceptions (highlight critical issues, problems and items requiring attention by readers)
  • Relevant Metrics
    • Schedule tracking (planned schedule vs. current state with projected completion date)
    • Budget and cost tracking (actuals vs. plan with projected cost at completion)
    • Number of deliverables (e.g., number of installations, number of completed modules
  • Status of issues, action items and risks (numbers of items by category with reference to the list)
  • Health status – Overall assessment of the health of the initiative or individual project being reported on
  • Activities planned to be completed in the next period.

Recap

Performance reporting enables a proactive forward looking view of a project, program or initiative.

The intent of is to inform stakeholders of the project’s progress and keep them actively involved in the project. The information provided will contain enough detail to allow stakeholders, given their role and level of management, to make informed decisions and maintain oversight of the project.

Higher level status reports should be in the form of a dashboard summarizing key metrics and highlighting critical issues.  Access to details should be available.

The project plan is the baseline or reference point for all status reporting.  Status information should be directly related to the project plan. 

If performance reports are valued by management at all levels, particularly at the executive level, there will be sufficient motivation to the work required to produce them.

Don’t forget to leave your comments below.

Managing by Accountability

Written by George Pitagorsky on . Posted in Articles. 4 Comments on Managing by Accountability

It is widely accepted that many, if not most, project managers have little or no formal authority, particularly when it comes to people who are assigned to the project from functional groups and user or client organizations.  We have yet as a field implemented projectized or even strong matrix scenarios in which project managers have hire/fire power or even the ability to create on-the-record performance reviews.

This would not be a problem if all performers had work ethics that drove them to actually do what they said they would do and if performers were not over scheduled, working multiple projects and day to day operational tasks simultaneously.  But, alas, that is not the real world.
In the real world people are often assigned to projects with little regard to their actual availability, some don’t view your project as a priority, many don’t know how to estimate their tasks and many have poor work habits that lead to the inefficiencies related to multitasking.  Informal PM in which the manager must manage without authority in a matrixed environment is the norm rather than the exception.  Often, in complex projects and programs there are conflicts between project and functional managers over priorities, authority, management style and more.

To manage in an environment where this complex of conditions exists is a challenge.  As a PM, you are responsible and accountable to the client and sponsor for the successful outcome of your projects.  That means getting them done on time, within budget and to the satisfaction of the stakeholders.

What can one do?

That is where management by accountability comes in.  If there is a plan founded on a clear  and practical approach, where the plan includes a set of activities with deliverables, dependencies, target dates and responsibility assignments, and there is a  communications plan with regular progress reporting, then the PM has at least a chance at success.  These are the requisites for management by accountability.

When people know that their task performance against commitments will be clearly reported, it is more likely that they will make commitments that they can meet and then meet them or clearly state why they haven’t.   Transparency promotes effective performance.

If reporting is regular and based on the activities in the project plan, that implies that tasks that are not completed by their due date will be identified and published as part of the project record.  If tasks are associated with individual performers, then there is personal accountability.

In many organization cultures, this kind of reporting is resisted.  Blaming Is confused with holding people accountable.  Nobody wants to be the one who identifies the cause of project schedule slippage.  Some see the reporting as too much overhead.  Others passively resist by not doing the work of updating the status of their tasks.

We need to find a way to overcome cultural resistance and recognize the value of effective reporting.  Reporting has to be simple and as automatic as possible.  Project management tools make this possible.  If the plan is well created and makes use of dynamic scheduling, reporting against the project baseline relatively simple.  But there is still overhead.  Someone has to enter actual completions for tasks, people have to explain their status, issues, risks and changes must be managed.

Getting effective reporting to be adopted in an organization is part of a culture change that comes when disciplined PM is implemented.  The PM who is working in an immature environment and has little formal authority must convince the stakeholders at all levels that management by accountability is in the best interest of the organization and the individuals on the project who are committed to project success.

Don’t forget to leave your comments below.

Estimating: The Courage to Confront Uncertainty

Written by George Pitagorsky on . Posted in Articles. 4 Comments on Estimating: The Courage to Confront Uncertainty

FEATUREJune27thBy definition estimates are uncertain. At best they are well supported and highly likely to be accurate reflections of the expected outcome. At worst they are mere guesses, wishful thinking or forced assertions to satisfy demands from above.

Accurate estimates require information. The estimator needs to know what is to be accomplished, how it is to be accomplished, and who will do the work under what conditions.
Estimates are often needed well in advance of the availability of the information required for accuracy.   That causes problems, particularly, when there is fear of making an estimating error or being held to an estimate even when it is proven to be wrong.  Often this fear is quite rational and justified by past experience.   Executives, often far from the action, act as if they believe estimates to be 100% accurate.  They create pressure and often make decisions that are contingent upon the delivery of a product on time and budget without considering risk.

As a result, project managers are inhibited. They either refuse to estimate or wildly inflate their estimates to make sure they are not blamed for overruns or late deliveries. 

Of course there is hope.  As any well trained PM knows estimates require assumptions and assumptions imply risk.  Multiple assumptions to create alternative scenarios enable ranges of estimates. Estimates, when one is far in time from the actual work, require more assumptions and a greater number of scenarios than close-in estimates.  Uncertainty is greater when the work to be done is farther into the future.  Ranges can and should be wide.

But, that is being rational and expecting others to be rational and knowledgeable about project estimating. The reality is that rationality is far from guaranteed when it comes to projects. Often, people in power want what they want when they want it and people who are not in power do not speak up and confront those who are in power.

A project manager has the responsibility to be courageous and to educate others regarding the realities of project estimates. 

The only certainty is that there is no certainty about most future events, and the ones we can be certain of are not particularly pleasant. It is a project manger’s job to make things happen. To do so, requires that we paint a reasonably realistic picture of the way things are likely to unfold and then use that vision as a guide.  We must be ready to adjust the vision and manage expectations even if that means admitting that our estimates were wrong.

When we are faced with irrational clients and managers, all we can do is try our best to get them to base decisions on facts and reasonable probabilities. If that doesn’t work then we either pass on the project or do our best to get things done as effectively as possible, expecting the blame if they don’t.

Don’t forget to leave your comments below.

Stop! Who Needs the Power to Stop a Project?

Written by George Pitagorsky on . Posted in Articles. 1 Comment on Stop! Who Needs the Power to Stop a Project?

In some mind training methodologies there is a Stop exercise in which The aim is to immediately stop whatever you’re doing and freeze in that position, mentally, emotionally and physically, so that you can observe your current inner state. 

Project Momentum

There are projects that once they begin continue on like a snowball rolling down a snow covered hill.  The project builds momentum, increasing in terms of the time, effort and money that are continuously absorbed by it.  The greater the spend; the harder it is for the project to stop or change direction.

This may be fine if the project is of value and if the work is being done effectively so as to achieve the desired value.  Momentum carries the project to completion.

If, however, 1) the project is not adding value, perhaps because conditions have changed or the initial value proposition was incorrect, 2) if the project is headed in a wrong direction, or 3) it is not in compliance with policies rules, regulations and best practices then the project should be stopped.

In healthy organizations there are two types of people or groups that can stop a project.  The first is the sponsor, client or steering group and the second is a expert group or individual who is charged with making sure the project is going in the right direction and is complying with policies, regulations and best practices. 

When the sponsor, client or steering group stops the project it is usually stopped for good – “killed” or postponed until higher priority work is completed.  When an expert, architecture group or other gatekeeper stops a project it is often not a kill or postponement.  It is a pause during which the conditions that caused the stoppage are understood and cleared and the project set on course again. 

Of course stopping a project is risky, particularly if you are not an executive or client.  In some environments there is a process definition that allows for projects to be stopped by technical experts and project managers.  In many of these there is an unwritten rule – never do it, even if it should be done.  It’s just too political; someone will hate you for it.  In other environments, there is no provision in the process for anyone to stop a project.  In either case, projects become like undying vampires sucking the blood form the organization.

Stop the Line

In quality manufacturing cultures workers can stop the assembly line when they see something wrong. In the Toyota Production System Jidoka is one of two main pillars.  It means that people or machines can stop production lines in the event of problems such as equipment malfunction, quality issues, or late work. Jidoka helps prevent the passing of defects, helps identify and correct problem areas using localization and isolation, and makes it possible to “build” quality at the production process.

We need to apply this principle to project work.

Stopping a project for technical or quality reasons as opposed to business reasons a project does not mean killing it is a radical move since it means having project personnel stop work and thereby delay progress on the project. If they are full time the budget is affected; the meter is running.

Why would anyone want to do that?  The answer is simple; to draw attention to something serious and make sure it is addressed quickly.

For example, in a technology based project a group responsible for making sure that security and other operational standards are met needs the power to get the project manager or others to deliver information and sit for technical reviews early in project life.  Short of the ability to stop the project the review group often lacks the ability to get a resistant PM to cooperate or to take negative findings seriously.

How do we overcome the cultural and personal barriers to doing this?  We make sure that everyone understands their responsibility to say something if they see something.  We include appropriate gates in the project.  We make sure that people are not afraid of repercussions if they take their responsibility to heart and actually pull the emergency stop chord.

Don’t forget to leave your comments below.

Avoid Failure – Support Weakness with Strength

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Avoid Failure – Support Weakness with Strength

Many projects fail because the strong do not come to the aid of the weak.  Often we find people assigned to critical tasks on projects without having the strength (knowledge, talent, experience, flexibility and intelligence) to perform them successfully. 

Ideally, there would be no weak performers.  Selection, training and coaching would bring everyone to a solid level of strength for all the tasks to which they are assigned.   But, let’s be realistic.  There are often instances in which tasks are assigned to people who cannot do them successfully

When this happens the project is put in jeopardy and the project team as a whole suffers, unless project planners adapt to the situation, planning and acting accordingly.

For many, the knee jerk reaction to a weak performer is to complain and blame.  Expectations are set too high and are not fulfilled. The thinking goes that “Charlie is a senior person and he should have the ability to do the work well.”  The key word here is “should”.  As project managers we are not so interested in what should be and very interested in what is and what will be.

Complaining and blaming may be cathartic, making the complainer feel a little better, but it does not address the problem of getting the work done well, on time and on budget. Complaining and blaming takes place after the damage is done.  Project managers want to make sure, to the best of their ability that the damage does not get done.

Avoiding the Risk

This is a risk management issue.  What is the probability that the person assigned to the task can do it well?  What is the impact if he or she cannot?

When we identify the risk that an assigned team member does not have the strength to do the job well, the most skillful approach is for other team members to take on extra work to compensate for the weakness.  

For example, if someone is assigned to write a document, can do all the research but organizes and writes poorly, it is wise for a team member who is a good writer to take on the writing task or to be ready for considerable editing/rewrite. 

This, of course, assumes that the person picking up the extra work has the time to do it without jeopardizing other task completions. To avoid that risk, the project should be planned, based on candid assessment of team member skills, to include rework, editing, extra testing or more effective assignments (for examp0le breaking the task in the example into two tasks, one for the research the other for the writing).  Make the supporting work an “official” part of the plan and ensure that it gets done well without jeopardizing the schedule or relying on the good will and good judgment of the good writer, who would have to informally pick up extra work to make the deliverable right. 

In other words, know the weaknesses of team members and make assignments that support weaknesses with strengths even though that may take longer or cost more. In the end, it is usually the quality of the outcome that matters most.

That means getting people to acknowledge their weaknesses and strengths when the project is being planned and getting team members to accept the fact that there is an obligation to support one another, even without there being an official assignment to do so.

Don’t forget to leave your comments below.