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.

Project Managers are Change Managers

Written by George Pitagorsky on . Posted in Articles. 3 Comments on Project Managers are Change Managers

PTimes_Feature_Jan26Project managers, to be effective, must be competent change managers.  Often, projects to introduce new or changed products or processes or to put on an event are planned without appropriately considering the change that the project result will cause in its environment.  Let’s discuss change management (as opposed to the control of changes that occur in scope and other aspects of the project) and see where it fits in the context of project management.

Two Kinds of Change

There are two principle types of change – intentional and unintentional. 

Intentional change is change we make happen.  It is planned and actively managed.  Intentional change is brought about by projects.

Unintentional change is change that seemingly just happens. 

But, nothing just happens.  Everything has a cause under a set of conditions.  The causes may be initiated by others or occur randomly, as in a storm.

One person’s intentional change may, and often does, result in unintentional change for those who are subject to the change’s impact and in the form of unexpected ripple effects.  As an initiator of intentional change you must do your best to predict and be ready to manage the unintentional change that occurs when you change something in a complex organization or environment.  Accept the reality that you cannot completely control and predict the outcome because of the complex interplay among people, processes, organizations, cultures and other factors.  You could say that a big part of risk management is identifying and handling risks of disruption caused by the performance of projects and the delivery of their results.

Change Management

“Change management is a systematic approach to dealing with change, both from the perspective of an organization and on the individual level. A somewhat ambiguous term, change management has at least three different aspects, including: adapting to change, controlling change, and effecting change. A proactive approach to dealing with change is at the core of all three aspects. For an organization, change management means defining and implementing procedures and/or technologies to deal with changes in the business environment and to profit from changing opportunities.”[1]   

Managing change is a project in itself.  Sometimes it is treated as separate project, for example a project to change the attitudes of customers by instituting new customer service procedures or to implement a new process to improve performance.  When projects are seen in this light, it is most likely (though not guaranteed) that the human aspects of change management (avoiding and managing resistance, providing time for the acceptance and integration of the new into the existing environment, etc.) will be integrated into the project. 

However, we see many technology and product development projects and even process change projects that do not fully address change management issues.  For example, consider a project, initiated by a business or government agency organization to implement a technology innovation (a new and improved computer based system).  The project is viewed as an IT project and as such put under the management of an IT project manager with the charter to deliver the new system.  To her the new system is basically the software and maybe some user documentation.

In a healthy situation, this project would be a sub project within the broader project or program to improve the organization’s performance.  Ideally there would be a competent PM at the higher level to whom the IT PM reports or at least must coordinate with.  The higher level project or program plan would include the IT sub-project plan and would address the change management issues.  It would ensure that there was coordination between the IT project and the related business projects (developing business processes, communicating, training, etc.) and that there was a risk analysis regarding the change impact of the implementation on the environment and its people.

In an unhealthy situation, and I have seen and heard of many, there may be nothing more than lip service regarding the implementation and the change it implies.  Sometimes business leadership and IT leadership as well, act as if they believe that there is some magical process that will cause the new system to appear and be immediately integrated into the existing environment. 

As PM’s you have the responsibility to look at your project realistically in the broader context of the organization and to advise business leadership of the need to ensure that change is managed appropriately to ensure the delivery of the benefits that justified the project’s initiation.  If you do not, you run the risk of delivering a lovely product that is never used or never reaches its potential.  That means your project will be considered a failure.

Become a competent change manager.

Don’t forget to leave your comments below.

How to Motivate the Team? Honesty and Respect

Written by George Pitagorsky on . Posted in Articles. 3 Comments on How to Motivate the Team? Honesty and Respect

There have been some interesting and useful conversations on last month’s post. 

I found one quite provocative.  The person said that there were “no troubled projects – only highly challenged ones”; and that using the term “troubled” with the team was a no–no because it would not be good for morale.

What Motivates the Use of Euphemisms?

This tendency to refer to troubled projects with euphemisms like “challenged” is quite common and often stems from a sense that the team members will be demoralized if they hear a word like “troubled”.  Perhaps it also stems from the project manager’s own inability to accept the fact that there is trouble.  Or perhaps it stems from the belief that while managers can handle anything the staff cannot.

Quite often team members working in a “troubled” project are already quite well aware that the project is in trouble.  They are often the first to know and to admit it, usually among themselves.  The more a project manager tries to make everything seem sweet and happy and treats the team members as if they were children who are incapable of dealing with the reality of the situation, the greater the chance that there will be demotivation.  Using terms like “challenged” instead of “troubled” is a silly game of denial.  The word usage does not change the reality. 

Candidly Share the Reality

After stepping back to assess the current situation objectively, it is necessary to candidly share the assessment’s results with the part of the team that has to work to resolve “problems” (or are they “challenges”).  Once there is a clear assessment and either a way forward or realization that there is no effective way forward, say so.  Then it becomes possible to get things on track.

Being candid about the situation shows respect for the team members’ capability to deal with reality.  If there is a sense that they are not ready for that, then help them get ready. 

Clarity and truthfulness go a long way in building morale and trust.  It helps to motivate the kind of effort needed to turn things around.  That is, if they can be turned around.

Is Success inevitable?

While in many, perhaps most cases, troubled projects can be turned around and be successfully completed, there are cases in which the project is so far gone that nothing will save it.  We can exhort the team to press on and put out the extra effort but if they are doomed to failure and are aware that they are being led on a forced march for no other reason than management ignorance or delusion how will they feel?  Will they be motivated to excel on the next project?  Will they trust their leadership?

I think not.

It reminds me of an old folk song by Pete Seeger called “Waist Deep in the Big Muddy”.  It is about an officer who leads his men, weighted down with equipment, to cross a big muddy river.  He is so sure of himself that he fails to listen to the advice of his sergeant and continues on as the water goes from being knee deep to waist deep to neck deep and the “big fool” keeps saying “push on” until he drowns.  Luckily, in the song, the sergeant takes over and turns the platoon back to shore before they all drown.

Team Members are Adults

Let’s be clear.  Team members on commercial projects are adults.  If they cannot deal with the reality of their situation, and project managers pander to that, then we perpetuate dysfunction.  But, more often, team members can deal with reality.  Project managers, who treat them as if they cannot, disrespect them and lose their trust.  No one wins.

History judges us by the way we respond to hardship.  By looking at the big picture, beyond the current project, we can make the best of any situation.  In the big picture, it is our job as leaders to enable those we lead to acknowledge and accept the reality of any situation.  

Don’t forget to leave your comments below

How to Motivate the Team on a Troubled Project

Written by George Pitagorsky on . Posted in Articles. 4 Comments on How to Motivate the Team on a Troubled Project

Pitagorsky_blog_nov17_croppedWhen a project begins there is the hope, even assumption, that it will be completed successfully.  The project team is often motivated and optimistic.  But what happens when the project gets mired in technical problems or caught up in politics, loses resources and slows to a snail’s pace.  What happens when the project becomes troubled in all the many ways that happens?

One thing that happens is that the team loses the motivation to press on.  Morale falls and performance degrades.  This is exacerbated by the tendency many managers have to crack the whip and put on more pressure, often without addressing the real causes of the trouble. 

How do we motivate the team and ourselves when we are working on a troubled, failing project?  How do we get the team inspired to get through the situation and succeed?

Avoid Reactive Behavior

A number of methods come to mind.  There is the tried and true technique of finding a scapegoat to blame and gang up on.  There is the advice of the project manager in the famous three envelopes story who leaves his successor on a troubled project three envelopes to be opened when the going gets rough.  The first advises the new PM to blame his predecessor.  The second advises project reorganization and the third advises that the PM, now in an even deeper hole than the one he started with, make three envelopes.

Clearly these are jokes.  Yet, how often do we find these very techniques applied in the face of a project that is behind schedule, over budget and riddled with unproductive conflict?

Take a Step Back

Well then, what do we do? 

Avoid reactive behavior and exhortation. 

Take a step back – get perspective on the project and its environment.  Review the current state and how it came into being.  It’s obvious, but counter intuitive to many.  The wrong thinking goes like this “We are way behind schedule; we don’t have time to sit around and review things.  We’ve got to get things done fast.” Remember that everything, including troubled projects have causes and that knowing the causes helps to eliminate their effects.  If you are to turn things around take a strong stance and review.  Do it carefully to avoid blaming but to also home in on the real causes.

Your review will probably find the need for some re-planning, or perhaps the problem is that there was no planning in the first place.  Either way, plan from where you are and get a realistic sense of what the possibilities are.  Can you meet the original expectations?  Is it time to pull the plug on the project and cut your losses?  What is the path forward, the risks and the requirements for success?

Not only will this enable you to determine the right next steps, it will enliven the team.  The team members begin to get the sense that positive change is beginning.  They know that continuing in the same way they have been working; only doing it faster is likely to lead to a horrible ending with more suffering on the way.

Change the Challenge

Change the challenge from getting the project done within the original time and budget to turning the project into a success and learning from the experience. Remember that sometimes a canceled project is better than one that continues on with no hope of success.

Use transparency in a non-blaming way to dig out the real causes of the current situation and honestly appraise the likelihood of being successful under a new set of expectations.  Then act on an informed decision.  Team morale rises as realistic objectives are set and unrealistic ones acknowledged.

 Dont Forget to Leave Your Comments Below

Reviews, Process Analysis and Organizational Learning

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Reviews, Process Analysis and Organizational Learning

Is Your Organization Learning Disabled?

Organizational learning is a critical success factor.  Learning disabilities get in the way of improving performance and contribute to repeating the dysfunctional behavior that leads to project and performance failures.

Stages in Learning

David Kolb authored one of the many adult learning cycles back in 1984. The model posits that there are four stages in learning each flowing from the other in a cycle: Concrete Experience is followed by Reflection on that experience.  This may then be followed by the derivation of general rules describing the experience, or the application of known theories to it (Abstract Conceptualization), and then to the construction of ways of modifying the next occurrence of the experience (Active Experimentation), leading in turn to the next Concrete Experience.

While Kolb’s theory was applied to individual adult learners, I think it makes a great deal of sense in the context of projects and organizational learning. 

Process Improvement – Learning from Experience

Process improvement is all about learning from experience.  Sometimes it is one’s own experience and sometimes the experience of others, derived from bench-marking or from the application of theories which generally come out of experiences studied by theorists.

Organizational learning begins with performance.  Process or project performance represents the concrete experience that starts the learning cycle.  Every organization has concrete experience.  Learning organizations utilize their experiences while learning disabled organizations simply go from one experience to the next with little or no reflection, analysis (abstract conceptualization in Kolb’s model) or experimentation.

Reviews – The Venue for Learning

Reviews are the means for reflection.  They enable groups to reflect on their experience and the experience of others.  Reviews (whether they be post project, in-process or operational reviews) of course take time and effort, rare and valuable commodities.  They also require getting past blaming and fear of accountability and transparency. The learning organization makes sure the time and effort for reflection are available.  The learning disabled organization does not prioritize reflection and organizational learning and therefore does not allocate the time and effort, breaking the learning cycle.

But, don’t start congratulating yourself because you hold reviews.  The next step, analysis or abstract conceptualization, is crucial if learning is to take place.  In this step the causes of the experienced behavior are identified.  Every outcome is caused by something.  That something is a process (a set of steps in a particular setting executed by one or more actors).  This step requires that more time and effort, in this case by experts who have the capacity to abstract the rules of the process and the applied theories that express them.  The learning organization recognizes that everything is caused by something and that unless they analyze the causes underlying their experience they will not be able to intentionally change the way they operate.

But, again, don’t congratulate yourself just yet, because, unless you take the fourth step you are wasting your valuable time and effort.  Active experimentation implies changing behavior.  Using the results of your analysis, you change the way you approach the next occurrence of your experience.  The learning organization recognizes that standards, procedures, tools and methodologies are all subject to change as experience and the processing of it lead us to make modifications based on the analysis of the causes of both effective and ineffective behavior.

Cure Learning Disabilities

Organizational learning disabilities are curable.  The cure requires an understanding of the value of continuous learning and the improvement it implies and then taking action to open to the new.

Don’t forget to leave your comments below

The Business Analyst Role – Who Plays It? Where Does It Fit?

Written by George Pitagorsky on . Posted in Articles. 9 Comments on The Business Analyst Role – Who Plays It? Where Does It Fit?

From a project management perspective the Business Analyst role is relatively simple.  On just about every project there is a need to communicate customer/user requirements so that they are clear and useful to the people who will design and deliver a solution or product.  There is a need to provide advice regarding alternative solutions and their implications on the future.  The product may be a new business process, computer system, facility, event, etc. 

The BA role, whether we call it that or not, is relatively clear.  The BA is a communicator, liaison and information source.  There is less clarity about who plays the role and where that person reports in the organization.  The questions that must be answered are:  how will the communication take place; who will facilitate it; who is responsible for the result; where that person reports in the organization and in the project management hierarchy; how much architecting, advising and designing is involved; and how much knowledge of the business context and the technology is required? 

To answer some of these questions we must answer two related questions “Who has the capability and the time to do the BA work?”  and “What kind of communication is needed?”

The BA role as defined requires the ability to communicate requirements in a manner that makes them objectively clear to the people who will deliver the product.  This implies that the communication must be structured in a way that articulates a big picture view of the product’s context, its relationship with its environment, purpose and benefits, and then articulates requirements in layers of detail. 

Whether this is done based on relational, object oriented, process oriented or physical component perspectives depends on the situation.  Usually multiple perspectives are required.  As requirements become increasingly detailed they require more time and effort to define.  As the product is more complex there is need for more skill and discipline and a higher level of proficiency

An ideal candidate for the BA role is a subject matter expert who is operationally tied to the product.  In IT application systems development projects, it might be a middle manager who lives and breathes the process that is to be automated and can write the structured requirements, perhaps using templates and questionnaires. 

There are two problems in finding such a person.  One is that the operationally tied subject matter expert is probably very busy doing his operational job and budget restrictions will not allow pulling him out for a few weeks to write requirements. The second is that there are many highly competent operations managers and business subject matter experts who would require significant training to be able to write effective requirements.  While the BA skill set is learnable there is a certain thinking style that makes the learning easier and quicker.

So, if we can’t have the ideal, then we look for a practical alternative, a professional BA or perhaps systems developers or technical managers with communication and requirements writing skills and an appreciation for the business and for the technology and its place in the business.  Perhaps it is a team of them and a process engineer and the business person, where the BA is facilitating and taking the burden of doing the writing and drawing from the others. 

Where does the BA sit in the organization?  I have been in the IT and process management field for decades.  Even before they were called Business Analysts there has been controversy over whether BAs should report to an IT organization under the CIO or to the business under the COO or division and department managers or to a process engineering/BA group reporting to the CEO. 

There has been movement from one model to another and back again.  There is no one right answer. Each organization and each project team must decide on the best mix for their circumstances based on the capabilities and availability of the players to clearly articulate useful statements of requirements.

Don’t forget to leave your comments below