How To Create and Execute Value – Overcoming Defensive Reasoning With Portfolio Management
Tuesday, February 1st 2011 @ 12:38 PM
Most businesses utilize Microsoft Project as their primary schedule tool in program and project management. Many of these same companies abuse the Microsoft Project software in misapplying its intent for scheduling instead they use it to “report” status. Often when the “report” usage is the norm, the project schedule is not statistically valid.
Critical path is not evident. Resources are not allocated correctly. Estimates have too much tolerance. Have you ever seen a project where the schedule status was “Green” but the “Budget” status was red? I suppose this can occur in some special situations. Typically though, green schedules and red budgets for the same project indicate something is terribly wrong.
Statistically valid project schedules reflect reasonability. They have historical evidence from work already completed as denoted by the project schedule that the estimates for project work completed to date was reliable or reasonable. Acceptable statistical validity is a standard for the environment. This metric is measured by what is currently acceptable in the project delivery environment at that time. If you are beginning to make all of your project schedules listed in the project portfolio, statistical validity may be 30% tolerance for error. Translated this means that the project end date has a 30% +/- tolerance of delivering on time, on budget, and on scope from what the stated project completion date as specified is in the project schedule.
In portfolio management discipline, having statistically valid project schedules is very important. Can you imagine any or all of your portfolio project schedules not this way? How can you possible be predictive about portfolio opportunities and/or potential threats if your project portfolio is inaccurate in the project scheduling science in your environment? Let’s understand that when we say a project schedule is 70% statistically valid, we are stating that we are 70% confident of the project scheduled work in the schedule will meet the project completion date. This is a strong statement particularly for complex projects. When a portfolio of statistical valid projects are at 70% overall, then this collection of projects improves the confidence of the predecessor and successor interdependencies of that portfolio and the resources allocations and assigned work intervals identified within the project portfolio. The main question to answer though is whether a 70% confidence factor is sufficient for managing a portfolio? If the portfolio version previous had less confidence then yes. If life and death is dependent on the accuracy of project schedules, my guidance would be to improve portfolio confidence to the best levels you could. If it was my life that was dependent on a portfolio of project schedules, I would want supreme confidence wouldn’t you? Often though getting close is good enough, the basic question is always what is enough? I recommend 80% statistical validity (80 / 20 rule) since most implemented systems are never defect free (too expensive). Bottom-line, being able to state that a $200 million project portfolio is 80% statistically confident should be translated by management to expect a minimum of $160M to be spent as expected or better in the pursuit of achievement of corporate objectives. Many businesses would be very happy with this today!
So then why is having a statistically valid project schedule so important? The issue is the predictability of the total project portfolio. If the embedded project schedules in the portfolio are not reliable so will be the portfolio. This becomes even more important when governance boards are attempting to make tactical navigation decisions based on portfolio data. Statistical validity reduces the potential for the occurrence of special cause variance from managing project portfolio capacity flow. Special cause are those defects that occur that are not typical. Capacity flow is a key portfolio management best practice because many elements of the portfolio are considered when portfolio governance boards are managing portfolios for best throughput optimization.
Leveraging Capacity Management Flow of Projects
Current practice in many businesses utilizing portfolio management is to manage portfolios by project end date and/or perceived business benefit. Consider the regular “Portfolio Governance Board” Meeting and how the objectives for that meeting could be pursued. Portfolio Governance Boards are responsible for maximizing portfolio throughput of all portfolio project work. Many things can cause a portfolio to swing out of whack (tipping) such as resource unavailability, business scope change etc. Board members should always be seeking how to advance the project work listed in the portfolio. They perform this process by understanding the interdependencies internal to the portfolio among all of the portfolio projects. Board members have fiduciary accountability and should have sufficient portfolio data available to them to understand the current state of project progress among all program and project investments in the portfolio. The health of these investments might be color coded such as Red, Yellow or Green. Red status is often perceived as over-extended. However, a “Red” status could also be an under-performed status such as spent budget. When conditions like these occur, the Governance Board might choose to move budget money around to meet more throughput opportunities and/or threats. Enabling business to navigate in this manner is one of the greatest portfolio management best practices. Managing portfolios in this manner focuses value on enabling project delivery speed based on portfolio information derived from the aggregate portfolio of projects listed in the portfolio. Certainly business benefit will occur with this practice but much more portfolio value can be achieved with more advanced capacity flow techniques applied to similar portfolios.
Leveraging Capacity Management Flow of Resources
This approach considers the availability of resources when resource capacity is limited. In addition, the traditional approach of working projects in highest value possible takes a back seat in this technique. In other words if 100 projects are to be worked in the portfolio, the traditional method is to work as many as possible as fast as possible. This leads to poor allocation and utilization of resources often creating “Bad” multi-tasking of resources that are strategically critical to the work they are assigned to. In this method, projects are worked in sequence of groups. Using the example of 100 projects expected to be worked and completed over a calendar year, in this method, the first 10 projects would be worked by the resources deemed most critical and vital to completing work before moving on to the next group of 10 projects and so on. Compared to the traditional approach for managing capacity flow of portfolios, this approach actually provides better results by reducing overall delivery time through the fiscal year and by reducing pressure overall on all resources to the point that the business may choose to use less resources the following portfolio cycle as mastery of this method is gained over portfolio capacity flow. Gaining capability to perform this technique is dependent on the business deploying portfolio tools also known as Enterprise Project Management Systems (EPMS) or Project Management Information Systems (PMIS) tools. More about tools later on.
Cause and Effect of Change Management on Portfolios
While value can be gained through project portfolio management techniques and processes, even more project delivery value can be achieved for the business by combining the resource portfolio with the project portfolio when making decisions to accept project change requests.
In a recent engagement with a large healthcare company in Michigan, I was asked to help an Information Department (IT) Technology group of more then 1200 people regain control over project delivery success. In recent years their percentage of delivering projects on time, on budget and on scope had been declining and they were mystified as to why. In their environment though the Program Management Office (PMO) was outside of the IT organization control all project managers and the project delivery dates. Over time, the PMO would change out project managers causing the project end date to extend and the assigned resources to extend with the date. This action impacted pending projects awaiting those resources thus causing the portfolio backlog to backup. IT owned the resources that were allocated and assigned to support those projects. IT had no direct control over project end dates but controlled resource allocation and assignment. The solution was to implement a “Resource Management Office” within the IT organization that would be the oracle for all project change request approval or rejection from the IT organization to all business units in the enterprise. It was in this manner that IT could pre-check against further delaying the portfolio backlog through the data provided by the IT Portfolio of work and assigned resources that provided insight into when resources were expected to be released. This particular engagement was a great example of how important it is to protect the portfolio backlog from backing up as a result of unplanned events such as project change requests. Remember, the objective in portfolio management is to maximize how much work can be performed over a measured time period. Now that these processes are deployed, this IT group is now regaining control over the work they are expected to deliver. Still, without an appropriate PPM tool like IBM’s Rational Portfolio Manager, managing project change request against the project portfolio and resource portfolio would have been much more difficult for IT to have performed. The true benefit gained by IT was an overextended line-of-sight on how to navigate resource management to meeting changing project needs.
How To Get Started
In business environments where PPM Tools do not exist, usually Microsoft Project software is utilized at the program and project level. Environments such as these typically become single-project like because portfolio management of all projects is not performed. Tremendous management information value is lost when this occurs since information is more pertinent to the program or project and not related to other external programs and/or projects. No matter what this circumstance may appear to be, the business can always gain immediate value implicitly if the environment requires statistically valid project schedules. In an environment where PPM tools don’t exist, the next best thing is to organize all statistically valid project schedules as sub-projects into suitable software. You still receive the benefit of interdependency management if these sub-projects are ranked in a meaningful manner and this is an improvement over the non-existence of portfolio management. Going forward, this basic portfolio should be maintained weekly or bi-weekly and when the portfolio is deemed statistically valid, use the portfolio at the periodic project manager meeting in the organization to illustrate cause and effect of various projects on each other. This particular use of the portfolio is essential to modifying project manager behavior towards improving the portfolio throughput each week the updated portfolio information is shared in this manner. In the period project manager meeting, the portfolio data (with mapped project interdependencies) presents enhanced understanding to all the project managers present in the meeting as to who is performing best and who is performing the worse. Those not performing well, will be self-motivated to improve their performance by the next portfolio review meeting. If not, possibly the PMO can assist?
Gaining Initial Value From The Resource Portfolio
In organizations that do not manage project delivery resources for best optimization through a Resource Portfolio, the business understanding of how to find available resources is limited. As a result, many businesses find themselves having to purchase contractor talent for the period that the business is overloaded. Much of this problem can be averted if all resource data, regular and contracted workers, is consolidated into a single physical and logically related resource portfolio. This same data could be organized into disparate resource pools as well as long as those resources only perform work assigned to them for projects using that resource pool. This rule of use is necessary because it is important to understand what resources are most critical and most strategic to the projects they serve in the project portfolio. If these key resources are over-allocated, the delivery speed of these projects will proceed at the speed of work of the critical resource(s). If these same key resources are under-allocated, their impact on project delivery speed will be influenced by other resources not necessarily critical to the project, wasting the opportunity to deliver work sooner.
Bottom-line, what we should know from this text so far is that it is critically important that project managers project manage. Project Managers should have control over all work tasks for all related project work and not just certain aspects of it. Project resources that don’t understand current project sense-of-urgency will work a work pace that expands to meet the estimate for the work they were asked to perform when there may have been a great chance to complete work early that would have allowed other projects to accelerate as well. In statistically valid portfolios, critical path is apparent for most all projects. Typically only those projects just starting may be unclear. The critical path in a project is a clear road map on how resources are expected to deliver work. Also clear should be w*****ver the current project impediments might be. All project resources should know always what these are so that they might help even if the impediments are completely unrelated to their work. You never know when you might walk by a bucket full of gold! How project managers communicate project impediments to their team is critical. What type of project managers do you have in your organization? Do they have control over all project tasks, all project resources? Are they steering the project through the critical path or are they driving it? If your project managers are steering the project, is this what management really wants? Usually, project managers behaving in this manner have minimal influence and are managing for the relationship effect and not necessarily for delivery impact as a first order of business. Project Managers that are driving their projects are actively involved in tracking progress and/or removing obstacles for their project resources so that those resources can move forward. In complex project schedules that do not have a defined critical path that is statistically valid, driving projects becomes an art form subject to personal risk of the project manager. Aren’t we tired of friendly fire?
Defeating Defensive Reasoning in Project Teams
Defensive reasoning has blossomed in recent years within the corporate entity as a result of corporate layoffs that has created an environment of job protectionism. We have all seen the result from defensive reasoning….conflict. Worker conflict is universal and often occurs when expectations are different than the result(s) produced or asked to be produced. As a project manager being challenged to bring project into delivery expectations, conflict is a way of life. How a project manager deals with conflict and defensive reasoning usually determines how successful they will be in there assignment.
Defensive reasoning is defined as when individuals or organizations act as they choose and yet choose to act in ways that support their own interests first and everything else second….as long as it does not impair their interests first.
PPM Tools such as IBM’s Rational Focal Point creates transparency for all projects and resources involved in portfolio management. Transparency impairs people from making bad choices because these choices are visible to other people such as other project team resources such that the person making the choice will not risk making a choice that is visibly feathering their own nest before helping the project team advance first. Key to this transparency is the integrity of the project and resource data and thus the requirement for portfolio’s to contain statistically valid project schedules. Projects managed in this manner creates an extended line-of-sight within the project team for the team resources to develop a new competency that enables them to continuously seek acceleration opportunities and/or delivery threat avoidance in all current and future project work. This way of life, consistently seeks out current and future project impediments to reduce and/or eliminate as a means to advance the assigned project delivery process. By sustaining a statistically valid project schedule, transparency is sustained throughout the project management life-cycle. Visibility to project work next in step within the project schedule could be easily diluted if project transparency weakens. In large organizations that are organized vertically across the project management life cycle, this is a significant problem as the bottom level departments often see project progress from a heavily diluted perspective if project schedules are not controlled in a statistically valid manner. Therefore, to defeat defensive reasoning in and outside of project teams, transparency must be enabled. The more transparency you have in the Portfolio, the better people who are impacted will be able to manage their portion of the work as people will not want to be perceived as the reason why work is not progressing (their defensive reasoning).
