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.

Kick-off is a Process, Not Just a Meeting

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Kick-off is a Process, Not Just a Meeting

All too often project managers settle for kick-offs that fail to set the stage for optimal project performance. This is because they do not address the “softer side” of the project, the interpersonal relationships and communications issues.

It is also because they see kick-off as an event rather than a process that may include several kick-off meetings with various groups of stakeholders and ongoing refinements of understandings, particularly as new people join the team.

Develop the Project Team

The PMI PMBoK® Guide does not define kick-off and has no indexed reference to it at all. Though, it is implied in the Develop Project Team process under Human Resource Management by “improving competencies, team interaction and the overall team environment to enhance project performance.” The objectives of developing a project team are to improve knowledge and skills, improve feelings of trust, and to promote mutual understanding and agreement among team members. Overall the objective of team development is to improve performance.

Project team development begins during the initiation of the project and continues across the life of the project and, in many cases, across multiple projects. Kick-off is the process of getting things started. A kick-off meeting is a critical part of it. Its objectives are to make sure that everyone’s understandings are aligned regarding objectives, procedures, and plans (including roles and responsibilities) and to begin or continue the team development process.

Kick-off Meetings

Kick-off meetings take place at the beginning of the project and at the beginning of major phases, for larger projects. As new people join the team, they must be “kicked-off” into the project. Depending on the size and structure of the project team and other stakeholders there may be more than one kick-off meeting. The core team may be involved in a one to three day or more, workshop in which they validate the project charter, begin the high-level planning and address team building and communication issues through discussions and exercises. Other groups may have kick-off meetings at which key people present project plans and objectives, seek feedback and get commitment regarding roles and responsibilities, objectives and processes and procedures. These mini kick-off meetings may also be workshops to address the kick-off of sub-projects and large complex activities.

While it is ideal to have the team co-located for the kick-off event, virtual meetings using web based conferencing or video conferencing or, as a last resort, teleconferencing can be effective if they are well planned and facilitated. Synchronous meetings are strongly recommended as they are far more likely to make an impact and enable the team to address complex and sensitive issues quickly and candidly.

Project performance is improved when we consider both the left brain, analytical aspects of the project – objectives, roles and responsibilities, designs, procedures, etc. – and the right brain, feelings oriented aspects, such as interpersonal relationships, emotional intelligence, diversity awareness, conflict management, etc. The team environment that is characterized by trust, mutual understanding, respect and harmony is likely to promote success even in the face of “less than perfect” planning and execution. Even the most accurately estimated, well planned and meticulously controlled projects, however, are prone to failure when the project environment is unhealthy. Use the kick-off process as a means for ensuring a healthy team environment.

Don’t forget to leave your comments below

What is a Successful Project?

Written by George Pitagorsky on . Posted in Articles. 3 Comments on What is a Successful Project?

I noticed that a well respected PM guru has stated that he “believes that the triple constraint, as we know it, may have to be modified to include a value component for these nontraditional projects and the traditional earned value measurement system will be replaced with a value measurement methodology.”

What he may be getting at is the recognition that there are two principal criteria for project success. One is the traditional triple constraints based criteria and the other is the value that the project result brings. There’s nothing new here.

Don’t Over Simplify!

Let’s not over simplify by merging these two together and making the PM feel as if she should be defining the product and making portfolio management decisions.

The project manager delivers “products”. While the PM may be able to influence the value derived from that product, he or she usually has little input or control. Project manager performance is primarily measured on how well project scope, cost and time objectives have been met.

Of course there are other criteria, including the degree to which the PM can collaborate at the program and portfolio level, coach and mentor, build strong relationships, etc. But these without meeting objectives are irrelevant.

What is Value?

Value is the perceived impact (positive or negative) of the project and its results on the organization and its environment. Did the product make or save money? Did it destroy or enhance the physical and emotional environment?

Based on the PMI model, value or benefits are the focus of the program. This distinction is based on the recognition that operational use is often far more complex than product delivery. In operational use there are clients, users, support people and systems, relationship managers, etc. managing ongoing activities. The ongoing nature of operations and use adds greater complexity because it implies adapting to change within the organization, in the marketplace or in the wider environment, over an extended timeframe.

The PM Role

The PM should certainly be aware of and knowledgeable about the business and organizational implications of the project. The PM is more than a simple craftsman; he or she must consider the business and architectural work related to the project. In this way, as much as it is possible, the project manager can influence project decisions in light of the long term value perspective.

There is a tough balancing act among the trades-offs between long term value and short term delivery time and cost. It requires leadership from above the PM. The program manager, sponsors, product managers, marketing, sales and operations managers, and client ombudsmen must be responsible for delivering value. In this realm, the single point of responsibility is not the PM.

Who is it in your environment?

Don’t forget to leave your comments below

Project Knowledge Management in PM – Time for Change

Written by George Pitagorsky on . Posted in Articles. 6 Comments on 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?

Written by George Pitagorsky on . Posted in Articles. 4 Comments on 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

Written by George Pitagorsky on . Posted in Articles. 1 Comment on 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.