Keep Away from Runaround SOO — The Pitfalls in Contracting Objectives

Been very busy the last couple of weeks visiting clients and discussing policy, so blogging is a bit backed up.  Most recently ran into an agency where the rule of thumb in contracts is only to use Statements of Objectives, also known as SOO.  This is a different animal than the usual Statement of Work (SOW) and Performance Work Statement (PWS).

The SOO, according to DAU’s Acquipedia “is used in solicitations when the Government intends to provide the maximum flexibility to each offeror to propose an innovative approach. That portion of a contract that establishes a broad description of the government’s required performance objectives.”

This flexibility is in response to many of the criticisms of government procurement that oftentimes a new technology or innovation wasn’t considered since the SOW and/or PWS seemed to bake in the solution.  The old bugaboo “prescriptiveness” is often applied now to any alternative method than the SOO, which tends to lead the procurement process down some odd roads.

For those of you who are not familiar with the process of writing a SOO, it involves several steps.  These are, once again, thanks to Acquipedia:

a.  Conduct market research to determine whether commercial items or non-developmental items are available to meet program requirements.
b.  Review the requirements documents which authorize the program, various DoD, services, joint services requirements documents for program management and acquisition management impacts to the program.
c.  Prepare a bibliography citing the specific portions of all applicable governing instructions, directives, specifications and standards with which the program must comply.  Keep these requirements to the absolute minimum.
d.  Develop the program objectives by completing a risk assessment that highlights the high and moderate risks in the areas of business, programmatic, and technical identified on the program based on the requirements and user’s high level objectives.

I have no general objection to this method of developing a contract specification, but it is not a panacea or a should be applied across the board.  As a matter of fact, the weaknesses inherent in the steps are well known in the contracting community.  Some of these include:

1.  The scope of the market research becomes skewed to limit the competition and drive the procurement to one or two preferred sources, including organic or custom solutions;

2.  Essential governing instructions are limited to the detriment of the public interest, particularly the application of earned value management;

3.  Running a risk assessment in the absence of sufficient data for the items being procured, or narrowing the risk to favor large businesses.

For example, I have participated in such solicitations, particularly with software, where the first step is achieved by the issuance of an RFI where a multi-page list of features that the COTS or NDI product is expected to meet.  Absent such “market research” are such considerations as the elegance of the underlying code, stability, sustainability, scalability, and efficacy of the solution.  So rather than successfully finding innovative new technologies to incorporate, in the first step the initiator of the purchase request is able to skew the research in favor of the familiar.  With step 4, the risk assessment, this tends to undermine initiatives to support small business and skew contracts in favor of large accounting, software, and consulting firms.  Needless to say, this is a self-reinforcing spiral, in which bigness is rewarded with more money to result in more bigness.

When economists like Thomas Piketty discuss the concentration of wealth over the last thirty years they must first look to government policy in general and contracting policy in particular, especially since the socio-economic measures meant to even the playing field in contracting were disassembled.  Policy and method have favored concentration and monopoly for quite some time and the public is paying a price for it.  In virtually all systems the ones that display the greatest degree of diversity are the most healthy.  Given the amount of concentration in key U.S. verticals, a change of policy to provide greater, and not less, guidance to encourage and reward diversity and small business–and more than a little money for the training of contracting specialists–is in order.

The stated purpose of the SOO is flexibility for a worthy end, but like all ideas implemented without knowledge, it not only fails to achieve its intended purpose but oftentimes provides an opening for opposite results.


I Can See Clearly Now (The Risk Is Gone) — Managing and Denying Risk in PM

Just returned from attending the National Defense Industrial Association’s Integrated Program Management Division (NDIA IPMD) quarterly meeting.  This is an opportunity for both industry and government to share common concerns and issues regarding program management, as well as share expertise and lessons learned.

This is one among a number of such forums that distinguishes the culture in aerospace and defense in comparison to other industry verticals.  For example, in the oil and gas industry the rule of thumb is to not share such expertise across the industry, except in very general terms through venues such as the Project Management Institute, since the information is considered proprietary and competition sensitive.  I think, as a result, that the PM discipline suffers for this lack of cross pollination of ideas, resulting in an environment where, in IT infrastructure, the approach is toward customization and stovepipes, resulting in a situation where solutions tend to be expensive, marked by technological dead ends and single point failures, a high rate of IT project failure, and increased expense.

Among a very distinguished venue of project management specialists, one of the presentations that really impressed me by its refreshingly candid approach was given by Dave Burgess of the U. S. Navy Naval Air Systems Command (NAVAIR) entitled “Integrated Project Management: ‘A View from the Front Line’.”  The charts from his presentation will be posted on the site (link in the text on the first line).  Among the main points that I took from his presentation are:

a.  The time from development to production of an aircraft has increased significantly from the 1990s.  The reason for this condition is implicit in the way that PM is executed.  More on this below in items d and e.

b.  FY 2015 promises an extremely tight budget outlook for DoD.  From my view given his chart it is almost as if 2015 is the budgetary year that Congress forgot.  Supplemental budgets somewhat make up for the shortfalls prior to and after FY 2015, but the next FY is the year that the austerity deficit-hawk pigeons come home to roost.  From a PM perspective this represents a challenge to program continuity and sustainability.  It forces choices within program that may leave the program manager with a choice of the lesser of two evils.

c.  Beyond the standard metrics provided by earned value management that it is necessary for program and project managers to identify risks, which requires leading indicators to inform future progress.

This is especially important given the external factors of items a and b above.  Among his specific examples, Mr. Burgess demonstrated the need for integration of schedule and cost in the development of leading indicators.  Note that I put schedule ahead of cost in interpreting his data, and in looking at his specific examples there was an undeniable emphasis on the way in which schedule drives performance, given that it is a measure of the work that needs to be accomplished with (hopefully) an assessment of the resources necessary to accomplish the tasks in that work.  For example, Mr. Burgess demonstrated the use of bow waves to illustrate that the cumulative scope of the effort as the program ramps over time up will overcome the plan if execution is poor.  This is a much a law of physics as any mathematical proof.  No sky-hooks exist in real life.

From my perspective in PM, cost is a function of schedule.  All too often I have seen cases where the project management baseline (PMB) is developed apart from and poorly informed by the integrated master schedule (IMS).  This is not only foolhardy it is wrong.  The illogic of doing so should be self-evident but the practice persists.  It mostly exists because of the technological constraints imposed by the PM IT systems being stovepiped, which then drive both practice and the perception of what industry views is possible.

Thus, this is not an argument in favor of the status quo, it is, instead, an argument to dump the IT tool vendor refusing to update their products whose only interest is to protect market share and keep their proprietary solution sticky.  The concepts of sunk costs vs. prospective costs are useful in this discussion.  Given the reality of the tight fiscal environment in place and greater constraints to come, the program and project manager is facing the choice of paying recurring expenses for outdated technologies to support their management systems, or selecting and deploying new ones that will reduce their overheads and provide better and quicker information.  This allows them to keep people who, despite the economic legend that robots are taking our jobs, still need to make decisions in effectively managing the program and project.  It takes a long time and a lot of money to develop an individual with the skills necessary to manage a complex project of the size discussed by Mr. Burgess, while software technology generations average two years.  I’d go with keeping the people and seeking new, innovative technologies on a regular basis, since the former will always be hard and expensive (if done right) and the latter for the foreseeable future will continue on a downward cost slope.  I’ll expand on this in a later post.

d.  There is a self-reinforcing dysfunctional systemic problem that contributes to the condition described in item “a,” which is the disconnect between most likely estimates of the cost of a system and the penchant for the acquisition system to award based on a technically acceptable approach that is the lowest bid.  This encourages unrealistic expectations in forming the plan once the contract is awarded, which eventually is modified, through various change rationales, that tend to bring the total scope back to the original internal most-likely estimate.  Thus, Procuring Contracting Officers (PCOs) are allowing contractors to buy-in, a condition contrary to contracting guidance, and it is adversely affecting both budget and program planning.

e.  That all too often program managers spend time denying risk in lieu of managing risk.  By denying risk, program and project managers focus on a few elements of performance that they believe give them an indication of how their efforts are performing.  This perception is reinforced by the limited scope of the information looked at by senior personnel in the organization in their reports.  It is then no surprise that there are “surprises” when reality catches up with the manager.

It is useful to note the difference between program and project management in the context of the A&D vertical.  Quite simply, in this context, a program manager is responsible for all of the elements of the system being deployed.  For the U.S. Navy this includes the entire life-cycle of the system, including the logistics and sustainment after deployment.  Project management in this case includes one element of the system; for example, development and production of a radar, though there are other elements of the program in addition to the radar.  My earlier posts on the ACA program–as opposed to the site–is another apt example of these concepts in practice.

Thus, program managers, in particular, need information on all of the risks before them.  This would include not only cost and schedule risk, which I would view as project management level indicators, but also financial and technical risk at the program level.  Given the discussions this past week, it is apparent that our more familiar indicators, while useful, require a more holistic set of views that both expand and extend our horizon, while keeping that information “actionable.”  This means that our IT systems used to manage our business systems require more flexibility and interoperability in supporting the needs of the community.



Don’t Be Cruel — Contract Withholds and the Failure of Digital Systems

Recent news over at Breaking Defense headlined a $25.7M withhold to Pratt & Whitney for the F135 engine.  This is the engine for the F35 Lightning II aircraft, also known as the Joint Strike Fighter (JSF).  The reason for the withhold in this particular case was for an insufficient cost and schedule business system that the company has in place to support project management.

The enforcement of withholds for deficiencies in business systems was instituted in August 2011.  These business systems include six areas:

  • Accounting
  • Estimating
  • Purchasing
  • EVMS (Earned Value Management System)
  • MMAS (Material Management and Accounting System), and
  • Government Property

As of November 30, 2013, $19 million had been held back from BAE Systems Plc, $5.2 million from Boeing Co., and $1.4 million Northrop Corporation.  These were on the heels of a massive $221 million held back from Lockheed Martin’s aeronautics unit for its deficient earned value management system.  In total, fourteen companies were impacted by withholds last year.

For those unfamiliar with the issue, these withholds may seem to be a reasonable enforcement mechanism that sufficient business systems are in place in order to ensure that there is traceability in the expenditure of government funds by contractors.  After all, given the disastrous state of affairs where there was massive loss of accountability by contractors in Iraq and Afghanistan, many senior personnel in DoD felt that there needed to be teeth given to contracting officer, and what better way to do this than through financial withholds?  The rationale is that if the systems are not adequate then the information originated from these systems is not credible.

This is probably a good approach for the acquisition of wartime goods and services, but doesn’t seem to fit the reality of the project management environment in which government contracting operates.  The strongest objections to the rule, I think, came from the legal community, most notably from the Bar Association’s Section of Public Contract Law.  Among these was that the amount of the withhold is based on an arbitrary percentage within the DFARS rule.  Another point made is that the defects in the systems in most cases are disconnected from actual performance and so redirect attention and resources away from the contractual obligation at hand.

These objections were made prior to the rule’s acceptance.  But now that the rule is being enforced the more important question is the effect of the withholds on project management.  My own anecdotal experience from having been a business manager in a program management staff is that the key to project success is oftentimes determined by cash flow.  While internal factors to the project, such as the effective construction of the integrated master schedule (IMS), performance management baseline (PMB), risk identification and handling, and performance tracking against these plans are the primary focus of project integrity, all too often the underlying financial constraints in which the project must operate is treated as a contingent factor.  If our capabilities due to financial constraints are severe, then the best plan in the world will not achieve the desired results because it fails to be realistic.

The principles that apply to any entrepreneurial enterprise also apply to complex projects.  It is true that large companies do have significant cash reserves and that these reserves have grown significantly since the 2007-2010 depression.  But a major program requires a large infusion of resources that constitutes a significant barrier to entry, and so such reserves contribute to the financial stability necessary to undertake such efforts.  Profit is not realized on every project.  This may sound surprising to those unfamiliar with public administration, but this is the case because it sometimes is worth breaking even or taking a slight loss so as not to lose essential organizational knowledge.  It takes years to develop an engineer who understands the interrelationships of the key factors in a jet fighter: the tradeoffs between speed, maneuverability, weight, and stress from the operational environment, like taking off from and landing on a large metal aircraft carrier that travels on salt water.  This cannot be taught in college nor can it be replaced if the knowledge is lost due to budget cuts, pay freezes, and sequestration.  Oftentimes, because of their size and complexity, project start-up costs much be financed using short term loans, adding risk when payments are delayed and work interrupted.  The withhold rule adds an additional, if not unnecessary, dimension of risk to project success.

Given that most of the artifacts that are deemed necessary to handle and reduce risk are done in a collaborative environment by the contractor-government project team through the Integrated Baseline Review (IBR) process and system validation–as well as pre-award certifications–it seems that there is no clear line of demarcation to place the onus of inadequate business systems on the contractor.  The reality of the situation, given cost-plus contracts for development contracts, is that industry is, in fact, a private extension of the defense infrastructure.

It is true that a line must be drawn in the contractual relationship to provide those necessary checks and balances to guard against fraud, waste, or a race to the lowest common denominator that undermines accountability and execution of the contractual obligation.  But this does not mean that the work of oversight requires another post-hoc layer of surveillance.  If we are not getting quality results from pre-award and post-award processes, then we must identify which ones are failing us and reform them.  Interrupting cash flow for inadequately assessed business systems may simply be counter-productive.

As Deming would argue, quality must be built into the process.  What defines quality must also be consistent.  That our systems are failing in that regard is indicative, I believe, in a failure of imagination on the part of our digital systems, on which most business systems rely.  It was fine in the first wave of microcomputer digitization in the 1980s and 1990s to simply design systems that mimicked the structure of pre-digital information specialization.  Cost performance systems were built to serve the needs of cost analysts, scheduling systems were designed for schedulers, risk systems for a sub-culture of risk specialists, and so on.

To break these stovepipes the response of the IT industry twofold, which constitutes the second wave of digitization of project management business processes.

One was in many ways a step back.  The mainframe culture in IT had been on the defensive since the introduction of the PC and “distributed” processing.  Here was an opening to reclaim the high ground and so expensive, hard-coded ERP, PPM, and BI systems were introduced.  The lack of security in deploying systems quickly in the first wave also provided the community with a convenient stalking horse, though even the “new” systems, as we have seen, lack adequate security in the digital arms race.  The ERP and BI systems are expensive and require specialized knowledge and expertise.  Solutions are hard-coded, require detailed modeling, and take a significant amount of time to deploy, supporting a new generation of coders.  The significant financial and personnel resources required to acquire and implement these systems–and the management reputation on the line for making the decision to acquire the systems in the first place–have become a rationale for their continued use, even when they fail at the same high rate of all IT development projects.  Thus, tradeoff analysis between sunk costs and prospective costs is rarely made in determining their sustainability.

Another response was to knit together the first wave, specialized systems in “best-of-breed” configurations.  In this case data is imported and reconciled between specialized systems to achieve integration needed to service the cross-functional nature of project management.  Oftentimes the estimating, IMS, PMB, and qualitative and quantitative risk artifacts are constructed by separate specialists with little or no coordination or fidelity.  These environments are characterized by workarounds, special resource-heavy reconciliation teams dedicated to verifying data between systems, the expenditure of resources in fixing errors after the fact, and in the development of Access and MS Excel-heavy one-off solutions designed to address deficiencies in the underlying systems.

That the deficiencies that are found in the solutions described above are mimicked in the findings of the deficiencies in business systems marks the culprits largely being the underlying information systems.  The solution, I think, is going to come from those portions of the digital community where the barriers to entry are low.  The current crop of software in place is reaching the end of its productive life from the first and second waves.  Hoping to protect market share and stave off the inevitable, new delivery and business models are being deployed by entrenched software companies, who have little incentive to drive the industry to the next phase.  Instead, they have been marketing SaaS and cloud computing as the panacea, though the nature of the work tends to militate against acceptance of external hosting.  In the end, I believe the answer is to leverage new technologies that eliminate the specialized and hard-coded nature of the first example, but achieve integration, while leveraging the existing historical data that exists in great abundance from the second example.

Note: The title and some portions of this post were modified from the original for clarity.




Gimme All Your (Money) — Agile and the Intrinsic Evil of #NoEstimates

Over the years I’ve served as a project, acquisition, and contracts specialist in both public service and private industry.  Most of those assignments involved the introduction of digital technology, from the earliest days of the introduction of what were called mini-computers, through the introduction of the PC, to the various digital devices, robotics, and artificial intelligence that we use today.

A joke I often encountered over the years was that if you asked a software programmer what his solution could do the response all too often was: “what would you like it to do?”  The point of the joke, which has more than a grain of truth in it, is that programmers do not live in (or would prefer not live in) the world of finite resources and often fall into the trap of excessive optimism.  That this is backed by empirical evidence has been discussed previously in this blog, where over 90% of software projects in both private industry and public organizations either fail outright or fail to meet expectations.  This pattern of failure is pervasive regardless of the method of development used: waterfall, spiral, or–the latest rage–Agile.

Agile is a break from the principles of scientific management upon which previous methodologies were based.  As such, it learns no lessons from the past, much as a narcissist rejects the contributions of others.  It is not that all of the ideas that were espoused in the original Agile manifesto in 2001–or those since–are necessarily invalid or may not be good ideas in modifying and improving previous practices, it is that they are based on a declaration without attribution to evidence.  As such, Agile has all of the markings of a cult: an ideology of management that brooks no deviation and which is resistant to evidence.  Faced with contrary evidence the reaction is to double down and push the envelope further.

The latest example of this penchant is by Neil Killick in his post “Beyond #NoEstimates — Why the traditional software contract must die.”  It is worth a read but, in the end, the thrust of the post is to state that contracts enforce accountability and the followers of the Agile Cult don’t want that because, well, there is all of that planning, scheduling, budgeting, and reporting that gets in the way of delivering “value.”  The flaw in the prescriptions of the Cult, particularly its latest #NoEstimates offshoot, has been adequately and thoughtfully documented by many well-respected practitioners of the art of project management such as that by Dave Gordon and others and I will not revisit them here.  Instead, I will focus on Mr. Killick’s article in question.

First, Mr. Killick argues that “value” cannot be derived from the plethora of “traditional” software contracts.  His ignorance of contracting is most clear here for he doesn’t define his terms.  What is a “traditional” software contract?  As a former contract negotiator and contracting officer, I find nothing called a “traditional” software contract in the contracting lexicon.  There are firm fixed price contracts, cost plus type contracts, time and materials/labor hour contracts, etc. but no “traditional” contracts.  For developmental efforts some variation of the cost-plus contract is usually appropriate, but the contract type and structure must be such that it provides sufficient incentives for “value” that exceeds the basic requirements of the customer, the type of effort, the risk involved, and the resource and time constraints involved in the effort.  The scope can be defined by specific line item specifications or a performance specification.  Thus, contrary to the impression left in the post, quite a bit of freedom is allowed within a contract and R&D projects under various contract types have been succeeding for quite a long time.  In addition, the use of the term “traditional” seems to have a certain dog-whistle quality about it for the Cult with its use going back to the original manifesto.  This then, at least to those recognizing the whistle, is a loaded word that leads to an argument that assumes its conclusion: that such contracts lead to poor results, which is not true (assuming a firm definition of “traditional” could be provided) and for which there is sufficient evidence.

Second, another of Mr. Killick’s assumptions is that “traditional” contracts (whatever those are) start from a position of distrust.  In his words: “Working agreements that embrace“Here’s what you must deliver or we’ll sue you”.(sic).”  Once again Mr. Killick demonstrates his ignorance.  The comments and discussion at the end of his post reinforce a narrative that it’s all the lawyers.  I do have a number of friends who are attorneys and my contempt for the frequent excesses of the legal profession is well known to them.  But there is a difference between a contract specialist and a lawyer and it is best summed up in a concept and an anecdote.

The concept is the basic description of a contract which, at its most simple definition, is a promise for a promise.  Usually this takes the form of a promise to perform in return for a promise to pay, since the promise must be sufficient and involve consideration of value in order to establish a contract.  It is not a promise to pay based on a contingent lack of a promise to perform unless, of course, the software developer is willing to allow the contingent nature of the promise to work both ways.  That is, we’ll allow you to expend effort to try to satisfy our needs and we’ll pay you if it is of value at a price that we think your product is worth.  It is not a contract in that case but, at least, both parties know their risks.  The promise for a promise–the rise of the concept of the contract–is in many ways the basis for civilization.  Its rise coincided with and reinforced civil society, and established ground rules for the conduct of human affairs that replaced the contingent nature of relationships between individuals.  Without such ground rules, trust is not possible.

The anecdote explains the aim of a contract and why it is not a lawyer’s game.  This aim was explained to me by one of my closest friends, who is an attorney.  He said: “the difference between you, a contract negotiator, and me, an attorney is that when I come out of the room I know I have done my job when all of the parties are unhappy.  You know you have done your job when all of the parties come out of the room happy.”  Thus, Mr. Killick gets contracting backwards.  The basis of this insightful perspective is based on the different roles of an attorney and a contract negotiator.  An attorney is trained and educated to vehemently defend the interests of its client.  The attorney realizes that he or she engages in a zero-sum game.  The clash of attorneys on opposing sides will usually result in an outcome where neither side feels fully satisfied.  The aim of the contract negotiator (at least the most successful and effective ones) is to determine the goals and acceptable terms for both parties and to find the common ground so that the relationship will proceed under an atmosphere of trust and cooperation.

The most common contract in which many parties engage is the marriage contract.  Such an arrangement can be viewed as an unfortunate obligation that hinders creativeness and acceptance of change, one established by lawyers to enforce the terms of the agreement or else.  But many find that it is a basis for trust and stability, where growth and change are fostered rather than hindered.  In real life, of course, this is a false dilemma.  For most people the arrangement runs the gamut between these perspectives and outside of them to divorce, the ultimate result of a poor or mismatched contract.

For project management in general and software project management in particular, the core arguments in Agile via #NoEstimates are an implicit evil because they undermine the essential relationships between the parties.  This is done through specialized jargon that is designed to obfuscate, the contingent nature of the obligation underlying its principles, and the lack of clear reasoning that forms the basis for its rebellion against planning, estimating, and accountability.  Rather than fostering an atmosphere of trust, it is an attempt for software developers to tip the balance in the project and contract management relationship in their favor, particularly in cases of external customer relationships.  This condition undermines trust and reinforces the most common software project dysfunction, such as the loss of requirements discipline, shifting scope, rubber baselines, and cost overruns.  In other words, for software projects, just more of the same.

Note: Grammatical corrections were made from the original.

I need a dollar dollar, a dollar is what I need (hey hey) — Contract “harvesting”

Are there financial payoffs in our performance management metrics where money can be recouped?

That certainly seems to be the case in the opinion of some contracting officers and program managers, particularly in a time of budgetary constraints and austerity.  What we are talking about are elements of the project, particularly in aerospace & defense work identified by control accounts within a work breakdown structure (WBS), that are using fewer resources than planned.  Is this real money that can be harvested?

Most recently this question arose from the earned value community, in which positive variances were used as the basis for “harvesting” funds to be used to either de-obligate funds or to add additional work.  The reason for this question lies in traditional methods of using earned value methods to reallocate funds within contract.

For example, the first and most common is in relation to completed accounts which have a positive variance.  That is, accounts where the work is completed and they have underspent their budgeted performance management baseline.  Can the resources left over from that work be reallocated and the variances for the completed accounts be set to 1.0?  The obvious answer to this is, yes.  This constitutes acceptable replanning as long as the contract budget base (CBB) is not increased, and there is no extension to the period of performance.  Replans are an effective means for the program team to rebaseline the time-phased performance management baseline (PMB) to internally allocate resources to address risk on those elements that are not performing well against the plan.  Keep in mind that this scenario is very limited.  It only applies to accounts that are completed where actual money will not be expended for effort within the original control accounts.  Also, these resources should be accounted for within the project by first being allocated to undistributed budget (UB), since this money was authorized for specific work.  Contracting officers and the customer program manager will then direct where these undistributed funds will be allocated, whether that be to particular control accounts or to management reserve (MR).

In addition to replanning, there are reprogamming and single point adjustment examples–all of which are adequately covered here and here.

But the issue is not one related to EVM.  The reason I believe it is not lies in the purpose of earned value management as a project management indicator: it measures the achievement (volume) of work against a financial plan in order to derive the value of the work performed at any particular stage in the life of a project.  It does this not only as an oversight and assessment mechanism, but also to provide early warning of the manifestation of risk that threatens the successful execution of the project.  Thus, though it began life in the financial management community to derive the value of work performed at a moment in the project plan, it is not a financial management tool.  The “money” identified in our earned value management systems is not real in the sense that it exists, other than as an indicator of progress against a financial plan of work accomplishment.  To treat this as actual money is to commit the fallacy of reification.  That is, to treat an abstraction as if it is the real thing.

The proper place to determine the availability of funds lies in the financial accounting system.  The method used for determining funds, particularly in government related contract work, is to first understand the terminology and concepts of funding.  Funds can be committed, obligated, or expended.  Funds are committed when they are set aside administratively to cover an anticipated liability.  Funds are obligated when there is a binding agreement in place, such as a contract or purchase order.  Funds are expended when the obligation is paid.

From a contracting perspective, commitments are generally available because they have not been obligated.  Obligated funds can be recovered under certain circumstances as determined by the rules relating to termination liability.  Thus, the portion of the effort in which funds are de-obligated is considered to be a termination for convenience.  Thus, we find our answer to the issue of “harvesting.”

Funds can be de-obligated from a contract as long as sufficient funds remain on the contract to cover the amount of the remaining obligation plus any termination liability.  If the contracting officer and program manager wish to use “excess” funds due to the fact that the project is performing better than anticipated under the negotiated contract budget base, then they have the ability to de-obligate those funds.  That money then belongs to the source of the funding, not the contracting officer or the program manager, unless one of them is the “owner” of the funds, that is, in government parlance, the budget holder.  Tradeoffs outside of the original effort, particularly those requiring new work, must be documented with a contract modification.

From an earned value management and project management perspective, then, we now know what to do.  For control accounts that are completed we maintain the history of the effort, even though the “excess” funds being de-obligated from the contract are reflected in positive variances.  For control accounts modified by the de-obligation in mid-effort, we rebaseline that work.  New work is added to the project plan separately and performance tracked in according to the guidance found in the systems description of the project.

One note of caution:  I have seen where contracting officers in Department of Defense work rely on the Contract Funds Status Reports (CFSR) to determine the availability of funds for de-obligation.  The CFSR is a projection of funding obligations and expenditures within the project and does not constitute a contractual obligation on the burn rate of funding.  Actual obligations and expenditures will vary by all of the usual circumstances that affect project and contract performance.  Thus, contracting officers who rely on this document risk both disrupting project management execution and running into an Anti-Deficiency Act violation.

In summary, apart from the external circumstances of a tight budgetary environment that has placed extra emphasis on identifying resources, good financial management housekeeping dictates that accountable personnel as a matter of course be diligent in identifying and recouping uncommitted, unobligated, and unexpended funds.  This is the “carry-over” often referred to by public administration professionals.  That earned value is used as an early indicator of these groups is a proactive practice.  But contracting officers and program managers must understand that it is only that–an indicator.

These professionals must also understand the nature of the work and the manner of planning.  I have seen cases, particularly in software development efforts, where risk did not manifest in certain accounts until the last 5% to 10% of work was scheduled to be performed.  No doubt this was due to front-loaded planning, pushing risk to the right, and some other defects in project structure, processes, and planning.  Regardless, these conditions exist and it behooves contracting and project professionals to be aware that work that appears to be performing ahead of cost and schedule plans may reflect a transient condition.

Note:  This content of this article was greatly influenced by the good work of Michael Pelkey in the Office of the Secretary of Defense, though I take full responsibility for the opinions expressed herein, which are my own.

You Can’t Always Get What You Want — Requirements and Rubber Baselines

I’ve received some nice feedback from my post “Guvmint Stuff.”  One of the e-mails I received was from my colleague, Dan Zosh, with whom I worked previously at a very successful software company that was absorbed by a much larger company.  Dan makes a good point regarding the usefulness of EVM and why it is viewed by so much of the Govcon project management community as a reporting as opposed to project management tool:  the instability of program requirements and the PMB.

Years ago when I worked on Navy staff in D.C. my immediate military boss would lecture the requirements types on the fact that we live in a world of finite resources and that they couldn’t always get what they wanted–and certainly that the wrong time to start rethinking things was when the program was nearing the end of technical development and had entered its final Preliminary Design Review (PDR).

I had applied this same principle when a PM of software projects on two separate occasions.  Had I allowed each review of the internal target customer base to adjust what “done” meant we would have never produced a solution to address a particular set of needs.  “We are pushing for the baseline functionality in version 1.0 and revisions will be made in 1.1.” was my response.  That was because I was aware of the fact that a very high percentage of software development projects in both private industry and government fail.  In fact, one group looking at the history of 50,000 commercial and government software projects has found that of 3,555 projects between 2003 and 2012, only 6.4% were successful, with 52% challenged–meaning that they either didn’t meet expectations or ran over budget and/or schedule, and 41.4% completely failed.  This is in line with what we had known to be true 20 years ago.

The reason for this is that we must know where we are going and what “done” means.  My colleague Glen Alleman has been waging his own dialogue with the #noestimates crowd and the cultists from the far edges of the Agile side who say that you do not have to assess progress because you don’t have an estimate, what with two week sprints and all that.  But my own experience with Agile proves that there is an overall plan and, yes, even if you don’t like it your customer doesn’t have unlimited resources and really expects that you come in within budget and the allotted time.

There is much more in common in IT and A&D than both disciplines would like to admit.  After all, A&D is quite heavy in software development and deployment, which is essential to most modern systems.  No doubt there are good reasons why requirements change, but the recent trend has been the shifting baseline, where variances are lost as the project is reset to some other definition of “done,” each revision contributing to cost growth.

In that environment EVM then really does only become a reporting tool viewed as an inconvenient historical document that records management by contingency.  Is this, then, a project management problem or a contract management problem?

I would posit that this is a failure of control mostly on the contract management side of the ledger.  Mr. Alleman’s discipline can be applied perfectly but as long as the underlying project space definition is under constant revision, his measurements will continue to shift.  Some on the Agile side seem to have that very agenda in mind–change the goal posts and one never has to be accountable.

While it makes eminent sense to trade off new technologies for old when development proves that there are more economical pathways to achieving the technical goals of the project, this is rarely the case.  Contracting officers routinely allow buy-ins to contracts knowing that the performance specification may be weak, and so down the line the contract will be modified significantly after award.  Under R&D cost-plus contracts this is somewhat baked into the nature of the contract type and the efforts being undertaken–which is the reason for the periodic reviews–but this also leads to abuses such as zeroing variances as tradeoffs between control accounts, rubber baselines, and harvesting contracts for funding.  These practices would not occur without the approval of the contracting officer, but it is a fine line between allowing internal adjustments within scope and changing the definition of the scope.

The issue, then, is a systemic one.  The response, then, should be a multilateral, multidisciplinary approach to contract and project management.  This includes stronger discipline in financial management that ensures that designated funds are being used for the scope intended, realistic estimates, well written performance specifications, and a contracting corps that understands that variances are never zeroed, contracts never harvested since the funds belong to the budget holders but, more importantly, understanding that the less expensive alternative proposal in which the technical approach to the performance specification is not fully fleshed out and is significantly below the most realistic, risk-adjusted estimate, is out of the competitive range.