Author: George Pitagorsky

George Pitagorsky, PMP, 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.

Project Knowledge Management in PM – Time for Change

Last month’s blog discussed the project manager’s role in sharing PM knowledge with stakeholders as a means for creating an organic learning process. This month I will opine about the broader issue of knowledge management in the realm of project management.

PM Learning Historical Perspective

Before the 1990s most project managers were trained on the job through a combination of coaching and self discovery. The very largest projects, particularly in aerospace, engineering and construction used “professional” PM methods. Out of this experience has grown a cadre of professional PMs and practitioners who have evolved Agile and other approaches to managing projects to improve the probability of project success.

Knowledge management is an integral part of project management (KM). The knowledge consists of information about current performance (e.g., status reports, risk registers, etc.), information about the process (e.g., methodologies, best practices, tutorials, etc.) and information on past performance (e.g., estimating data bases, project archives, etc.)

Process Learning

The process information is at the heart of performance improvement. In the past, the principle approach here has been formal training and relatively rigid methodologies. This is changing and hopefully changing quickly. Would-be project managers can learn the basics with self paced courses but can only learn the realities in practical, well facilitated workshops and through ongoing dialogues with their peers and experts in the field.

Advanced PM

Advanced PM training has been pretty much a joke, with training providers offering up academic courses in the various areas of knowledge. How many PMs actually need an advanced risk course? Advanced learning in PM is about application, not academics. We need workshops and coaching blended with self-paced options for academic information and just-in-time sharing for best practices and specific how-to’s.

Knowledge management is the discipline that seeks to find the best way to share knowledge in the organization. Learning and development is a significant part of KM but certainly not the whole. KM is the realm of taxonomies to organize knowledge, technologies to collect and distribute knowledge and support social computing, and governance, editing and filtering to make sure the knowledge being shared is accurate and relevant and being used.

Consciously engineered KM reduces the burden on the PM to educate everyone on PM benefits, principles and responsibilities. The PM is still responsible for creating and maintaining a learning environment in his/her project but this is far easier when there is an organization-wide structure in place, supported by effective content.

What are you doing to integrate KM into your PM process?

Don’t forget to leave your comments

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?