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.

Time-to-Value and the Value of Time

Written by George Pitagorsky on . Posted in Articles. 12 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. 7 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. 9 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. 11 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

Risk and Uncertainty – Managing Expectations

Written by George Pitagorsky on . Posted in Articles. 11 Comments on Risk and Uncertainty – Managing Expectations

As stated in last month’s entry “A key assumption supporting healthy expectations is that there is uncertainty and that the more complex and hostile the working environment is, the greater the uncertainty.”

Attitudes regarding risk and uncertainty are central to establishing healthy expectations.  While it seems quite obvious from personal experience and history that uncertainty is the only certainty.  Anything can happen.  That is why project management 101 teaches that risk management must be an integral part of project planning and control for the project to be performed effectively.

The central activities of risk management are identification, assessment and response planning.  These must be integral parts of the estimating process.  When they are done well, stakeholders will have realistic expectations because estimates and the assumptions underlying them will be communicated so as to leave no room for delusional thinking.  Further, risk management enables the plan to be optimized.

What is delusional thinking?  It is thinking that in a complex project a single point estimate is guaranteed to be realized.  Delusional thinking is thinking that there will not be any changes, that everything will be thought out with 100% accuracy and that everything will go as planned.  Risk management dispels delusional thinking because it explicitly states the nature of the risks that might befall the project in terms of their probability of occurrence and their potential impact on the project’s performance and outcome.

Response planning takes it a step further.  It attempts to squeeze out risk and uncertainty by identifying avoidance and transfer options, to minimize the residual risk and to establish reserves or buffers that enable development of a range of possible outcomes. 

Engaging the Stakeholders

Every project manager with any sense understands the need for and principles of risk management.  The challenge is to engage project performers, clients and sponsors so that they understand, take part in and even insist upon an effective risk management process. 

For performers who provide estimates of their work, the PM should make it clear that a multipoint estimate with assumptions for most likely, optimistic and pessimistic scenarios is necessary.  For performers who are given estimates, there must be an opportunity to assess assumptions and risks and accept their assignment, rather than being forced to work under irrational assumptions.

For clients, they must be drawn into the risk management process so they can help to identify risks from their perspective and understand the degree of uncertainty that exists in the project.

Sponsors must be exposed to clear statements of risk and uncertainty, in the form of range estimates and statements of assumptions, even when they are trying to force project managers to commit to unrealistic estimates and schedules.

Don’t forget to leave your comments below