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.

Educating the Stakeholders: Whose Job is it Anyway?

I closed last month’s post with “As a project manager (PM) it is your responsibility to educate your team, your client, sponsor, manager and those responsible for setting client expectations so that they all understand the realities of estimating.”

Taking it a step further, it is the PM’s responsibility to educate all the other stakeholders regarding the principles, techniques, costs and benefits of project management. Of course, some may be thinking that there is enough on their plate without having to educate the world about PM. If not you, who?

Without a conscious effort to educate the stakeholders about project management, there is the risk that they will not adhere to PM best practices or, if they do, they may do it without the real buy-in that makes for effective performance.

Sharing Practical Knowledge

What do we mean by educating? It is sharing knowledge in a way that better enables stakeholders to play their roles effectively and to clearly understand the trade-offs and benefits of applied project management. Don’t bore people to death by telling them everything you know about the PMBOK. Instead bring out the right knowledge in the right way at the right time. It is just-in-time learning. It is not theory; it is practical and completely relevant to the situation at hand.

A Good Example

For example, the lesson on realistic estimating is best given in the context of estimate negotiation when you share the need to consider deliverables, past performance, resource capacity and availability, uncertainty, environmental conditions and other factors when estimating.

In the midst of the estimate negotiation you have peoples’ attention. Take a few minutes to bring out the fact that, in the past, unrealistic estimates have caused serious problems. See if you can get the other parties to acknowledge the truth of that statement. Then ask “Do we want to repeat that behavior knowing what we know from our experience?” Maybe that will bring up questions about what you (collectively) have learned from past experience. If it does, you are at a ‘learning moment’.

Organic Learning

Estimating is only one topic for educating stakeholders. As the project proceeds there are lessons on project risk management, monitoring and controlling and anything else that is relevant, given the nature of the project, the people and the situation at hand. As you share your PM knowledge in this way, you create and take part in organic learning. Learning and reinforcing learning and best practices becomes a natural part of the process.

As a project manager, it is part of your responsibility to make sure you are sharing your PM knowledge and experience with the greater team so that everyone can perform effectively, eliminating waste, staying in control and delivering quality results.

If not you, who?

Don’t forget to leave your comments below

The Demand for Accurate Estimates and Rational Expectations

Optimal performance involves finding the right way for the current situation. The goal is to meet the often conflicting multiple demands that face us. One of those demands is the demand for accurate estimates and rational expectations. Estimating is far from a solved game in most project environments. Making it more difficult are irrational demands for certainty and a lack of effective estimating processes.

In estimating, accurate does not mean 100% assured. After all we are estimating, not divining the future. We expect different degrees of accuracy depending on knowledge of requirements, experience with the tasks at hand, the available resources, among other factors. It is widely accepted in project management circles that early in the life of a project an acceptable estimate might have 50% or more possible variance, while later, after requirements have been well understood and transformed into a design the estimate accuracy may increase to within 10% of the final outcome (assuming that the estimators know what they are doing and the environment is stable). Nevertheless, we find that executives, sales people, clients and project sponsors pressure project managers (PMs) into making definitive estimates well before there is enough information to accurately do so. Project managers often pass the pressure along to team leads and project performers who view the whole estimating effort as a stupid game in which no one wins.

In an ideal world, we might use parametric estimating where the estimate is based on a rate that is calculated over time based on past performance. If the size of units is roughly uniform and the method being used and resources are consistent then the estimate can be highly accurate. Unfortunately, in most project environments, parametric estimating is not a realistic approach. In some environments projects are inconsistent. Computing the rate requires accurate time tracking and record keeping across multiple projects. The data has to be available, up-to-date and accessible. In addition, the estimator must know (or at least estimate) the number of units in a project to apply the rate to. This implies that there has been sufficient requirements analysis and design.

Instead of parametric estimating we find that relatively small and simple tasks or deliverables (artifacts) are estimated by performers to provide definitive estimates. For these to be accurate the estimators must know how to estimate, folding in risk and uncertainty and a solid understanding of the deliverable. These definitive estimates, as well as parametric ones, can only be made after a significant amount of time and effort has been expended on requirements definition and design.

Since most organizations require estimates early in the project life cycle, these must be based on high level assumptions about the product and other factors (resources, etc.) These are analogous estimates based on the overall nature of the project and its similarity to past projects.

Knowing these basic realities of estimating, the project manager is responsible to push back with due diligence to make sure that those who demand early definitive estimates understand the risks. It is quite possible for a senior manager to get a seasoned PM to make an early estimate or for a sales person to set expectations with a client that are unrealistic. However, the result is almost always disappointing. The impact on staff morale, the reputation of the project delivery group, the quality of the product, client relationships and the bottom line are predictable and unpleasant. Why repeat painful, unpleasant behavior? Instead, accept the reality of estimating uncertainty – the more you know, the better your estimates will be. Getting to know more means doing the work of requirements definition and design, collecting and making available useful historical data and being realistic about uncertainties such and resource availability, changes, etc. As a PM it is your responsibility to educate your team, your client, sponsor, manager and those responsible for setting client expectations so that they all understand the realities of estimating.

Why Debate? Let Formality and Agility Coexist

From PMI Network to blogs all over the web there is a continuing debate over Agile project management. I find it interesting, if not distressing, that the debate still rages. While there are distinct attributes of Agile methods, overall the basic tenets of formal PM are certainly there. Planning exists, there is a clear point of responsibility and accountability, there is monitoring and control (often a lot tighter and more useful than in more traditionally managed projects) as well as a closing. The predominant differences are in the way these are accomplished and the “weight” of the PM activities. The Agile Manifesto values some things over others, for example “individuals and interactions over processes and tools”. This does not mean it seeks to eliminate processes and tools. Valuing the ability of “responding to change over following a plan” does not mean never following a plan. The Manifesto’s writers were not fundamentalists, “black and white” thinkers.

In general, the most effective approach for anyone in any project is to apply sound PM principles in a way that makes the most sense given the situation. It is just as important for individual performers to understand and accept the needs of their managers and clients as it is for them to simplistically expect their management to just tell them what they want and stand back.

Clearly, there are some situations that call for an Agile approach like Scrum while others (large, complex, critical and regulated projects) call for a relatively “heavy” approach. Many projects can be managed with a hybrid approach. For example, an Agile software development project can be embedded into a waterfall-like product development, or process change project or program. No project in a business setting can really justify a ‘seat of the pants’ approach that leaves out planning and control and puts the project reins in the hands of performers who may not have the big picture in mind, or may be too immature to warrant the trust required for a truly Agile approach.

“Black and white thinking” is a terrible waste of time and talent. It leads to solutions that are sub-optimal and that invariably dissatisfy a significant number of people, often including many of the adherents of the “winning” side. On the global scale it is the thing that has caused most of history’s horrific events. Let’s eliminate black and white thinking and engage in dialogue that seeks to educate and inform practitioners regarding the best way to manage. Then leave it to them and their management to choose the right approach for the projects at hand.


George Pitagorsky, PMP, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. George authored The Zen Approach to Project Management and PM BasicsTM. He teaches meditation and is on the Board of Directors of the NY Insight Meditation Center.

The ‘Right’ PM Effort in the Face of Tight Budgets

A big issue in and around project management circles these days is how to manage effectively in the face of tight budgets and fewer human resources.  Do you cut back on PM activity to save resource time and money?  Do you have project managers wearing performer hats while managing?  Is this an opportunity to make the PM process Lean?

The goal is to find the right balance between thoroughness and efficiency.  Think of a musical instrument.  If the strings are too loose then the music is distorted; if the strings are too tight they will break.  Too much effort is wasteful.  Too little PM effort increases the risk of failure and decreases optimal performance.

What is the right level of PM effort?    As consultants have learned to say, “It depends.”   It depends on the size, complexity, significance and regulatory requirements of the project, as well as on the degree of PM automation and other factors.  Rough estimates range from 10% – 20% of overall project effort.   

Who applies the effort?  Project management is a shared competency.  Project managers, team leaders, individual performers, suppliers, functional managers and their resources all do it.  PM automation and PM process (methodology, standards, procedures, templates, archived examples, etc.) significantly affect the level of effort.  When the PM work is effectively distributed among the team members less effort is required of professional project managers and there is more likely to be better information and control, leading to better performance.

Let’s test the 10 – 20% estimate.  Across the team, that equates to from 4 – 8 hours per 40 hour week per person.  That’s between half a day and a full day per five day work week, spread across the week and integrated with performance work.   Not a small amount of effort.  Do we need that much? 

Individual performers estimate and schedule work, post hours and completions to track time and accomplishments (perhaps 10 – 15 minutes per day), write up change requests and issues and provide progress and projections.  There may be team meetings (in some projects a 10 – 15 minute daily meeting and maybe a longer (30 minutes -1 hour weekly meeting) and reviews.  Roughly, meetings alone can amount to about 2 ½ – 3 hours a week.   The project manager effort can be full time for an individual or team, depending on project size and criticality.   Project administrators, coaches, auditors and others may play a PM related role, expending more PM effort.

Are you including the right level of PM effort in your projects?  Are you maximizing the leverage of automation, centralized PM coaching services, clear and scalable standards and procedures, and PM knowledge management?

What are your standards for estimating the PM effort on your projects? 

How can you reduce the cost of PM without increasing the risk of project performance shortfalls?

Optimizing Project Performance

 

This is my first blog for Project Times. I am looking forward to sharing my thoughts and experience each month and engaging in a dialogue on project and program management and process optimization. The goal is to help in the ongoing work of optimizing our performance and the performance of our organizations. My orientation is influenced by systems thinking as a means for remaining objective and realistic. I promote open-minded mindfulness applied at the individual, team and organization level as means to optimize performance.


I apply a Zen-like approach, as evidenced in my book The Zen Approach to Project Management.‘Optimal’ means most desirable under the circumstances; the best given current conditions. Attaining and sustaining optimal performance is a dynamic process that takes place continuously over time as conditions change and learning from performance is transformed into process improvements. In project management, optimal performance is being able to consistently meet expectations by delivering useful, quality results within time and cost constraints while maximizing the efficiency and effectiveness of resources across multiple projects. When we take a broader view, we include the consistent realization of the benefits that motivated project performance and the ability to sustain and improve optimal performance.

Who doesn’t want to operate optimally? The real question is what time, effort and resources will you commit to do it?

Project management and performance optimization are intimately related. Project management is a process that is both a means to the ends of process optimization and a target of it. Project management (PM) operates within other processes such as product development, finance, engagement management and construction. At the same time project and program management are critical success factors in optimizing the performance of any process. Optimization implies managed intentional change and continuous improvement. These are brought about by way of projects and operational processes performed within programs.

Over the next months we will explore optimal project and program management performance. Among the factors that are critical to optimal performance are process (quality) improvement, methodology, project management, organizational change management, communication, expectations management, conflict management, decision making and problem solving, knowledge management, collaboration and leadership. These are combined with specific knowledge and experience in organization, technology, policies and procedures. The result is a complex system in which engineering must be balanced with an openness to let things evolve.

How do we address the blending of agile, lean and traditional project management? How do we manage defined processes, compliance and flexibility? How do we implement and sustain practical best practices in the project management process in a way that maximizes benefits? How do we satisfy all the stakeholders – clients, sponsors, champions, sales people, performers, regulators, etc.? These are among the questions we will address over the coming months.

Please comment to let me know what you think of the definitions and direction reflected above. For further exploration of these topics and for other resources visit www.pitagorskyconsulting.com.