Adaptive Management

Conventional project management methodologies, such as the critical-path method and the traditional "waterfall" method, are suitable for projects with limited uncertainties, variables, and timeframes. The focus on predictive planning, and corrective actions as a project progressed, was a generally well-understood and intuitive approach: use proven processes and tools, define all requirements early-on, develop a step-by-step plan, and follow the plan while measuring progress with previously selected metrics. Simple, right?

Unfortunately, this approach may be too simple for modern project-based organizations. No longer will document and artifact-intensive planning, which can become overloaded with unnecessary features and requirements, dictate the course and final deliverable of a project. To be successful, contemporary project managers must transition from a focus on planning to a focus on execution. This includes the ability to adapt to changing circumstances and changing requirements, and requires constant collaboration with clients and stakeholders.

The Agile Manifesto provides an excellent starting point for contemporary project managers: "Individuals and interactions over processes and tools," "Customer collaboration over contract negotiation," and "Responding to change over following a plan" are three broad tenets aimed at delivering higher-quality results to the mutual satisfaction of clients and the provider. The iterative approach taken by Agile management, and other methodologies such as SCRUM, lead to earlier value realization, reduced conflict, and provide the ability for project managers to quickly adapt the project plan when new developments call for change.

Let's face it - requirements churn is a fact of life in most projects, and it's not necessarily a negative. Our goal, and the customers ultimate requirement, is the best possible solution to their need - this is probably not going to be the solution that most closely conforms to the initial needs analysis or project scope document. Our approach, based on SCRUM's empirical approach, is to accept a problem cannot always be fully understood or defined. So we must maximize the team's ability to respond to changing requirements. This entails a short-term work cycle based on an overarching project strategy and high-level project plan.

 

The plan is divided into multiple phases or iterations, with a more detailed plan created for the next phase (similar to the daily SCRUM meeting that answers these questions: What did you do yesterday? What will you do today? What obstacles are in your way?). Future phases can be changed based on the outcomes of the completed phases, or to meet any new or changing requirements. This allows us to refine plans and estimates as-needed, and to deal with schedule/requirements issues as soon as they are identified.

This adaptive approach provides much more strategic flexibility to the project team and the client. Decisions can be made at the end of each iteration based on the outcomes of previous decisions; when this is combined with a much more collaborative process, the result is a better deliverable that is much more likely to meet actual customer requirements (as opposed to the comprehensive, up-front list of requirements typically found in conventional project artifacts).

Contingency Planning

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.

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.