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.

Rational Estimates: Motivate the Team by Acknowledging Reality

Written by George Pitagorsky on . Posted in Articles. 8 Comments on Rational Estimates: Motivate the Team by Acknowledging Reality

It is not Possible to do the Impossible Project

I have written before about estimates, risk and managing expectations.  Most of us know that there is such a thing as a rational estimate and we know that it is one that considers risk and uncertainty, is based on past experience, and on a realistic assessment of the work to be done, the work environment in which it is to be done, the tools and techniques to be used to do it and the quality and availability of resources.

It is common sense that just because people in powerful positions want something to be done in a certain time frame for a certain cost it doesn’t guarantee that it will get done.  Of course, pressure, strong sponsorship, lots of money, super high priorities vis-à-vis other projects and the right resources help to do what seems at times to be impossible; but in the end it is not possible to do the impossible.

Motivation Affects Performance

“Motivation is a fire from within. If someone else tries to light that fire under you, chances are it will burn very briefly.”  Stephen Covey

There is an interesting link between motivation and performance.  Motivation stimulates the desire, energy and intensity to perform.  It is what moves people to exert persistent effort to achieve goals.  “Motivation is the energizer of behavior and mother of all action. It results from the interactions among conscious and unconscious factors such as

  1. Intensity of desire or need
  2. Incentive or reward value of the goal
  3. Expectations of the individual and of his or her significant others.”[i]

Motivation can be from within and/or from external sources.  Internal motivation stems from intrinsic desires.  Maslow’s hierarchy of needs refers to six intrinsic motivators – the needs for physiological safety, security, social contact, for recognition, self-actualization and self-transcendence.  External motivators are rewards from an external source, for example recognition, money, the promise of perpetual security, a promotion, etc.

It is the interplay between internal and external motivation that has behavioral impact.

The Link Between Realistic Acknowledgement and Motivation

You might be wondering “So, what does this have to do with rational estimating?”

Imagine being on a project in which you know that no matter how hard you work you will not be able to succeed in achieving the project goals or hit your own target dates.  Imagine too that you are being driven on by managers and sponsors who insist that the target date must be met within cost constraints.  Add to that the situation that there have been many past projects in which you and others have been faced with unrealistic estimates and a management attitude that seems right out of Dilbert (that is to say completely without reason).  How do you react?  How motivated are you to push yourself, to work unpaid overtime.

On the other hand, imagine a similar situation with tight target dates and cost constraints based on an unrealistic estimate and a manager or sponsor who owns up to the reality and says something like, “I know we are unlikely to succeed in meeting the estimates, but due to political and customer relations issues that are out of my control we can’t change them now.  We need to work as hard as we can to bring the project in as soon as possible and with the lowest cost overrun.” 

How would that make you feel?  Would you be more or less motivated to push?

Don’t forget to leave your comments below

Time-to-Value and the Value of Time

Written by George Pitagorsky on . Posted in Articles. 8 Comments on Time-to-Value and the Value of Time

Time to value is a project and product management measure of the duration of projects.  It represents the time that it takes to deliver a product to its end users so they can make use of it and gain its value.  In typical PMI project management terminology, it is the time from initiation until benefits begin to be realized. 

Accelerating time-to-value for software applications is a principal motivator for approaches like Service Oriented Architecture and Agile development.  In new product development the faster the product is ready for sale, the better.  This has motivated strategies like concurrent and parallel engineering.   In construction, finishing the building enables rent collection and the joy of living in a new house.  This has motivated prefab building approaches and other time savings advancements.

As discussed in my June 2010 blog post, Rushing the Project to Disaster, on the negative side, accelerating time-to-value is a motivator for rushing projects to completion at the expense of quality and ignoring risks.

While some purists might argue that projects deliver products and programs deliver benefits, we will accept the fact that projects are performed to gain benefits.  Therefore, minimizing project duration while including all the features and functions required for productive use of the product and delivering them at a specified level of quality is an important objective. 

However, to optimally deliver value we must not only consider time to product delivery.  We must consider the total cost of ownership (TCO) of the product.  TCO is the cumulative cost of acquiring, maintaining and operating the product.  When we consider TCO we are faced with trade-offs.  For example if I deliver a product quickly but do so by eliminating some energy saving features or by not putting in some features that make maintenance easier, the overall value of the product is reduced. 

The value of time saved must be measured with TCO in mind so that decisions can be made that will have the optimal long term impact across product life.  In some instances this will mean increasing time-to-value and in other instances reducing it at the expense of the longer term benefits.  In the end it is a business decision.   The decision-makers (the sponsor and client) must be given the information they need to weigh short term gains against long term benefits.  They will decide on the feature set (scope) that will deliver the desired benefits.

It is the project manager’s job to then deliver a quality product within time and cost constraints.  To deliver in the shortest time possible means making strategic decisions at the project level.  Those decisions include whether to acquire an off-the-shelf solution, to take an agile approach, or to deliver in phases so that some value can be achieved as early phases are delivered.  Here is where the knowledge of the possible approaches is required.  If the PM doesn’t have that knowledge then he or she must bring in subject matter experts who do.  

When there are many projects seeking to deliver products quickly, it is the job of architects and process engineers to create the project environments that will allow for optimal performance at the project level.

To achieve optimal time-to-value it is necessary to consider trade-offs between the short term gains of early delivery and the long term benefits associated with features and functions that may make the delivery time longer.  It is also necessary for the project manager and the team to determine the most effective approach.

Don’t forget to leave your comments below

Getting Strategic Projects off the Back Burner

Written by George Pitagorsky on . Posted in Articles. 6 Comments on Getting Strategic Projects off the Back Burner

Do you find that important projects that promise long term benefits continuously get postponed and often never get done?  We call this the perpetual back burner projects syndrome.

Some years ago I worked with a technical services group that found itself constantly postponing work on long term projects because they were constantly jumping on the short term, ad hoc projects that kept coming up day after day.  The short term projects were responses to service requests.  The long term projects were infrastructure changes, of which many would reduce the occurrence of or eliminate many of the causes of the service requests that kept the group from working on the long term projects.

In one situation the attempt to implement a project governance process kept getting postponed because the very people who would benefit most by it were too busy to spend any time working on the project. 

In another situation the work of analyzing the cause of ad hoc problems and requests and addressing those causes was postponed indefinitely because there were too many ad hoc problems and requests for services.

What is One to Do?

What is one to do when the current work load, made up of tactical, “must-get-done-now” projects continuously overburdens available resources and leaves none for the long term strategic projects?

Here are some choices, many of which can be used in combination to overcome the perpetual back-burner project syndrome:

  1. Do nothing and live with never getting the long term projects done until they become critical and then rush to do them under pressure and often at great expense.  Interestingly, this is what most groups choose (perhaps tacitly, but a choice nevertheless).  This is a predominant choice because there is not enough time to assess and act upon the problem.  In some cases the long term project never gets critical, so it never gets done.
  2. Build a strong business case that will sell the idea of sacrificing the immediate gratification that comes from addressing short term ad hoc projects to obtain the benefits from the longer term strategic projects.  Sell the idea to the level of management that has the power to do something to change the situation; for example, like getting more resources or delaying ad hoc project responses.
  3. Reorganize so that resources are dedicated to the longer term projects and they are buffered from short term priorities.  This reduces the band-width of the ad hoc group and may extend delivery times on the short term projects.  Note that current delivery time expectations may be completely unreasonable and unnecessary. 
  4. Establish or refine the project intake and prioritization process to get tighter control over the scheduling.
  5. Use a critical chain scheduling approach to eliminate unproductive multi-tasking and increase throughput while dedicating some resources (full or part time) to the longer term projects.
  6. Get more resources, and dedicate some to the long term projects.  Avoid getting more resources and letting them get sucked into the ad hoc response mode that you are trying to remedy.

What are you doing?

The perpetual back burner project syndrome costs organizations huge amounts of money and tends to frustrate and burn out many valuable resources.  Doing something about it requires courage and intelligence.   What are you doing?

Don’t forget to leave your comments below

Rushing the Project to Disaster – Greed and Fear

Written by George Pitagorsky on . Posted in Articles. 5 Comments on Rushing the Project to Disaster – Greed and Fear

With the Gulf of Mexico oil spill as a case in point we have another example of the interplay between greed and fear, and how they drive projects to disaster.

A former contractor on the BP Atlantis platform reported that many engineer-approved documents that were needed to assure safe operations were missing.  How often, albeit in far less critical projects, do we find documentation and due diligence go out the window in the face of pressures from the sponsor and client to get the product operational.

This post is not meant as an analysis of the spill and its causes.  Many others are engaged in that and chances are that the answers about what happened and why will be lost in the millions of words of reports, news conferences and the like.

However, we can use this catastrophe as a reminder of what happens when we cut corners to rush to completion, so sponsors and clients can reap the benefits of the project, and managers can reap the benefits of the perception of being on time and within budget.  In the end, the rushing increases the risk of losing far more than is gained by a few days, weeks or months of early completion.  We have seen the results of cutting corners and avoiding project delaying risks many times before.. Remember the Challenger and its ‘O’ ring, for example. 

What we seem to have is a collective learning disability.

Greed blinds the sponsors and clients and their representatives.  They want what they want and won’t take no for an answer.  Fear drives the project managers, quality assurance people and others who fail to push back.  In the event that pushing back doesn’t succeed, they need to take a courageous personal stance and blow the whistle before the disaster occurs.

All the procedures and policies in the world will not overcome greed and fear.  The only thing that will is the courage to be rational and to have the kindness and compassion to help even the people pushing hard for doing the wrong thing to avoid self destructive behavior.

As project managers, while doing our best to be as agile as possible, we must methodically follow safety and quality procedures and hold those who don’t accountable.  We must raise red flags in a way that gets the attention of the people who are unconsciously or consciously leading themselves and others into an abyss.  When that fails, we must be ready to put our integrity on the line and escalate issues to levels at which there is sufficient authority to act, and some rational thinking going on.  We must also accept the fact that in any given situation there may be no such place.

 As Pete Seeger asks in his song Where have All the Flowers Gone:

“When will we ever learn? When will we ever learn?

Don’t forget to leave your comments below

The Challenge of PM in Engagement Management

Written by George Pitagorsky on . Posted in Articles. 6 Comments on The Challenge of PM in Engagement Management

If you don’t consider the big picture it is likely that you will work sub-optimally.

All too often, project managers lose track of the context of their projects and all too often managers, clients and client contact people lose track of where PM fits in their process.  Taking a step back and looking at the project context allows us to apply project management methods in a way that is tailored to the needs of the situation at hand.

Engagement management (EM) is a context for project management. Engagement Management is a process that brings together client relations (sales and support), project management, delivery and quality management to satisfy clients.  EM operates across multiple projects and ongoing relationships.  The EM view helps project managers to work more effectively with client contact people (e.g., sales, business analysts, application managers, etc.) to avoid “over-sold” projects and irrational expectations. 

Engagement Management is a process that extends from sales through the closing of an engagement.   An engagement may be a single project or a series of projects and ongoing support activities.  An engagement is embedded in a client relationship and a relationship may involve multiple engagements.

Where does Project Management Fit In? 

Projects are at the heart of an engagement.  Projects deliver the products or services that will satisfy client expectations.  In the engagement management process, we often find that sales people or, in engagements that are within an organization, client relationship managers or functional managers set expectations with clients.  Those expectations evolve into a contract and the contract establishes project constraints – time, cost and scope/quality. 

Thinking that project management begins with the kick-off of the project work under contract or from the moment there is a formally initiated project is a problem.  This kind of thinking leads to projects that have irrational deadlines and budgets.  That leads, in turn, to unmet expectations, dissatisfied clients and sponsors, burned out performers and disharmony in relationships among sales, delivery (technical), PM, support and client relations groups.

Project management work must begin as soon as anyone begins to set time, cost and quality constraints.  Estimating is a precursor to setting deadlines and budgets.  Project planning is required.  Who does the estimating and planning when there is no involvement of PM practitioners and delivery experts in the sales process?  In a healthy engagement management process, there is a project management presence representing the delivery team in proposal creation and contract review by an interdisciplinary management team to decide whether the contract is one that should be signed.  This creates the necessary checks and balances to make sure that sales people or relationship managers do not unilaterally set costs and deadlines just to get the business.  It protects the performance organization and the client.

Don’t forget to leave your comments below