Nothing ever goes completely according to plan, so no matter the size or scope of your project, having some type of informal or formal contingency fund/plan in place is going to be a necessity (and will help protect your relationship with the client). At one company I worked for, we had some advantages when it came to contingency planning: namely, the majority of our projects were similar in nature, typically revolving around infratstructure improvements or application deployments. The key variation among these projects was usually restricted to the starting point, that is, their existing technical situation.
Our projects were usually phased, so phase I would be the work to standardize and stabilize what they had; to implement best-practices and remove disparities. Once we had them at a level we were comfortable with, subsequent phases had very little cost variance, because we were building on a solid foundation that we put in place. This allowed us to show senior managers and key stakeholders that a contingency was necessary for the first phase, as we were transitioning from how they currently operated to how we were going to work together, but which could be drastically reduced once the situation was under our control. This was intuitive for them, as everyone expected some bumps in the beginning, so we experienced very little resistance.
We also benefited from our estimating process. We firmly believed in expectations management as a key to customer satisfaction. From the very beginning of a project, when we were in the evaluation and selection phases, our estimates consisted of value ranges based on best-, expected- and worst-case scenarios. This approach accounted for the inherent uncertainty in a project, but still gave the client detailed enough information to make a decision. Using ranges also gave the client options as the project progressed, allowing for some items to be added, changed, or removed without affecting the overall budget range. While this approach didn’t utilize a contingency fund per se', the concept still recognized the uncertainty of the future and allowed for changes to project cost without forcing the project to go over-budget. Because this approach forced the customer to see that we expect some variation, and gave them control over minor changes to scope with regards to cost, they were usually willing to allow for the range, which acted as an informal contingency fund.
Sometimes, however, something more formal was required. As mentioned above, many of our projects were similar in nature. However, sometimes we would come up against larger or more complex projects that fell outside of our detailed experience, and required a greater allowance for uncertainty. Again, we would present estimate ranges, but we would also plan on a formal contingency. To overcome resistance, we conducted a thorough analysis of what they were asking for, and would detail our primary concerns, as related to uncertainty, to the client to make them understand why we were putting $X.00 aside as a contingency. We also made it understood that as the project progressed, if these contingencies came to fruition, we would discuss how to proceed with them before applying the funds. This way they maintained some element of control, and were more comfortable with the process.
When everything was said and done, the mix of formal and informal contingency planning we utilized, based on strong communication and expectations management, helped us maintain client satisfaction and our own profitability.
Monday, August 23, 2010
Monday, April 19, 2010
Single Point Adjustments - Appropriate or not?
The project baseline represents both the schedule and budget for all project tasks. As such, it is the benchmark against which all actual schedules and costs are measured, and it shows the relationship between the three primary project constraints – cost, performance and schedule. Schedule variance or cost variance can be determined by comparing earned value (EV) to planned value (PV) and actual cost (AC), respectively.
The term SPA refers to an event when schedule variance (SV) and cost variance (CV) are both zeroed in a single reporting period, and the remaining portion of the work is rebudgeted to establish a new Performance Management Baseline (PMB). This new PMB completes all remaining work using only the remaining budget from the original PMB.
But are Single Point Adjustments (SPA’s) appropriate for use in most projects? I think not. SPA’s seem only to distort earned value (EV) trend information while limiting the Estimate at Completion (EAC) range. After reading a few case studies, I believe an SPA has become primarily a tool used to suppress unfavorable EAC’s, and to address contract-reporting issues, rather than addressing program management or cost overrun concerns.
Using an SPA usually works only as a temporary administrative fix to create the illusion of a project being on-track. A well-maintained PMB shows the true variance of a project and lends itself to the creation of accurate estimates at completion (EAC), whereas the SPA falsely produces EAC estimates that conform to initial expectations.
Additionally, I’ve come to believe that SPA’s, if absolutely required, should only be used in conjunction with more traditional rebaselining techniques. These classic techniques essentially redefine the project baseline, rather than simply zeroing existing variance and attempting to finish the project with the previously allocated budget and in the time allotted.
A critical look at the use of an SPA presents a compelling case not to use the concept, and to be wary of any contractor who may recommend doing so. After reviewing the problems associated with SPAs, I think we can all understand the requirement for disciplined maintenance of the PMB. In order to have accurate estimates and true variances, which provide an opportunity to make adjustments to cost, time or scope, we have to know our PV and use that as a benchmark for our AC and EV.
The term SPA refers to an event when schedule variance (SV) and cost variance (CV) are both zeroed in a single reporting period, and the remaining portion of the work is rebudgeted to establish a new Performance Management Baseline (PMB). This new PMB completes all remaining work using only the remaining budget from the original PMB.
But are Single Point Adjustments (SPA’s) appropriate for use in most projects? I think not. SPA’s seem only to distort earned value (EV) trend information while limiting the Estimate at Completion (EAC) range. After reading a few case studies, I believe an SPA has become primarily a tool used to suppress unfavorable EAC’s, and to address contract-reporting issues, rather than addressing program management or cost overrun concerns.
Using an SPA usually works only as a temporary administrative fix to create the illusion of a project being on-track. A well-maintained PMB shows the true variance of a project and lends itself to the creation of accurate estimates at completion (EAC), whereas the SPA falsely produces EAC estimates that conform to initial expectations.
Additionally, I’ve come to believe that SPA’s, if absolutely required, should only be used in conjunction with more traditional rebaselining techniques. These classic techniques essentially redefine the project baseline, rather than simply zeroing existing variance and attempting to finish the project with the previously allocated budget and in the time allotted.
A critical look at the use of an SPA presents a compelling case not to use the concept, and to be wary of any contractor who may recommend doing so. After reviewing the problems associated with SPAs, I think we can all understand the requirement for disciplined maintenance of the PMB. In order to have accurate estimates and true variances, which provide an opportunity to make adjustments to cost, time or scope, we have to know our PV and use that as a benchmark for our AC and EV.
Thursday, March 25, 2010
Project Leadership v. Project Management
I’ve heard and read a lot about leadership and management. When it comes to projects, I can’t help but feel leadership is an overrated concept; something that is really only required by employees at low-level positions; people who need something to believe in because their jobs don’t provide fulfillment. I also think that a project team (or an organization, for that matter) that has good management, without leadership, will do better than one that has good leadership, without management.
Why? Look at how leadership is defined. Leadership is responsible for establishing direction, aligning people and motivating and inspiring. You can duplicate all of those through management – setting objectives and creating strategy and vision, coordinating resources and defining relationships and communicating expectations. Leadership however, will virtually never be able to plan and budget, organize and staff, or control and problem solve. Even if a project team or organization built on leadership is successful, it will never be as efficient (and therefore competitive or profitable) as one that is well managed.
I would like to bring up the idea that a team of professional workers, who are experts in their functional areas, don’t require leadership or motivation. These individuals need management to coordinate their efforts and provide support and resources to their activities. As a matter of fact, if this was a team of people that required "motivation, direction and guidance" (a common definition of leadership), I’m not sure that want them on my team (who wants to have to constantly “lead” people?).
From one of my textbooks: “Leaders use inspiration, charisma and inherent excitement…to motivate others.” That sounds like nothing more than a sales pitch to me. Can’t we have a team of rational people who are able to deliver results and adapt because they recognize it’s necessary, and because they have the will to succeed; not because they have a cheerleader touting the “inherent excitement” of the change or the project?
This is not to say leadership is never necessary; it has its place. In the military, or on sports teams, when bullets are flying by and mortars are falling, true leadership can bond people together and help them focus on meeting that one single objective. But when it comes to executing in a professional environment, I know who I want on my team: intelligent, consummate professionals who are driven by achievement and need management support to accomplish their tasks, not a leader.
Why? Look at how leadership is defined. Leadership is responsible for establishing direction, aligning people and motivating and inspiring. You can duplicate all of those through management – setting objectives and creating strategy and vision, coordinating resources and defining relationships and communicating expectations. Leadership however, will virtually never be able to plan and budget, organize and staff, or control and problem solve. Even if a project team or organization built on leadership is successful, it will never be as efficient (and therefore competitive or profitable) as one that is well managed.
I would like to bring up the idea that a team of professional workers, who are experts in their functional areas, don’t require leadership or motivation. These individuals need management to coordinate their efforts and provide support and resources to their activities. As a matter of fact, if this was a team of people that required "motivation, direction and guidance" (a common definition of leadership), I’m not sure that want them on my team (who wants to have to constantly “lead” people?).
From one of my textbooks: “Leaders use inspiration, charisma and inherent excitement…to motivate others.” That sounds like nothing more than a sales pitch to me. Can’t we have a team of rational people who are able to deliver results and adapt because they recognize it’s necessary, and because they have the will to succeed; not because they have a cheerleader touting the “inherent excitement” of the change or the project?
This is not to say leadership is never necessary; it has its place. In the military, or on sports teams, when bullets are flying by and mortars are falling, true leadership can bond people together and help them focus on meeting that one single objective. But when it comes to executing in a professional environment, I know who I want on my team: intelligent, consummate professionals who are driven by achievement and need management support to accomplish their tasks, not a leader.
Saturday, February 6, 2010
What drives cost overruns?
I’ve recently heard some very compelling points with regards to the systemic nature of projects. Perhaps the most poignant concept is the realization that the sum of project overruns is often greater than its parts. I know that, in hindsight, it is difficult to explain how any one change, or the uncertainty in a single arena, could have led to the final outcome. Rather, it’s the impact of the cause of the overrun, multiplied through feedback mechanisms, and by the resulting negative effect on areas of the project that may not be directly linked to the initial difficulty.
The key villains that drive cost escalation are the project organization and the clients themselves. Of course, external forces such as the changes in the regulatory environment or advances in technology can have an impact. However, even though the consequences, in terms of increased costs, may be more severe from external changes, the likelihood of occurrence is usually low (although the longer the duration of the project, the more critical this area becomes), so I wouldn’t consider it a “key” villain.
Systemicity is really an embedded reality for projects. In and of itself, the systemic structure of a project doesn’t drive cost escalation – it simply magnifies it and helps to create “vicious” or “virtuous” circles. So although it’s worth discussion and is a cause of the sum being greater than the parts, it’s not really a key villain when discussing cost overruns. Neither is schedule acceleration, because it is a reaction to project trouble, not a direct cause.
The factors that cause cost overruns, and contribute to large-scale cost escalations, typically include the planning (or control) estimate, customer interference, and customer or contractor created changes to the project plan. These cause the initial difficulties, and act as a root cause for cost escalation. These stages are usually foreseeable, and are controllable, by the two key villains I mentioned above – the project organization and the customer organization.
The real causes of cost escalation during these stages are usually the customer’s failure to provide thorough information during the planning stages, or their inability to “help” the contractor execute the project. Or it may be the contractor’s failure to follow proper configuration management techniques, or ensure a “meeting of the minds” on key project specifications. Failure by both organizations to manage these types of problems throughout the project will lead to cost escalation for each arena, and give rise to the systemic and acceleration stages that will make the team look back and wonder what happened.
The key villains that drive cost escalation are the project organization and the clients themselves. Of course, external forces such as the changes in the regulatory environment or advances in technology can have an impact. However, even though the consequences, in terms of increased costs, may be more severe from external changes, the likelihood of occurrence is usually low (although the longer the duration of the project, the more critical this area becomes), so I wouldn’t consider it a “key” villain.
Systemicity is really an embedded reality for projects. In and of itself, the systemic structure of a project doesn’t drive cost escalation – it simply magnifies it and helps to create “vicious” or “virtuous” circles. So although it’s worth discussion and is a cause of the sum being greater than the parts, it’s not really a key villain when discussing cost overruns. Neither is schedule acceleration, because it is a reaction to project trouble, not a direct cause.
The factors that cause cost overruns, and contribute to large-scale cost escalations, typically include the planning (or control) estimate, customer interference, and customer or contractor created changes to the project plan. These cause the initial difficulties, and act as a root cause for cost escalation. These stages are usually foreseeable, and are controllable, by the two key villains I mentioned above – the project organization and the customer organization.
The real causes of cost escalation during these stages are usually the customer’s failure to provide thorough information during the planning stages, or their inability to “help” the contractor execute the project. Or it may be the contractor’s failure to follow proper configuration management techniques, or ensure a “meeting of the minds” on key project specifications. Failure by both organizations to manage these types of problems throughout the project will lead to cost escalation for each arena, and give rise to the systemic and acceleration stages that will make the team look back and wonder what happened.
Subscribe to:
Posts (Atom)