EVM

Shake it Out – Embracing the Future in Program Management – Part One: Program and Project Management in the Public Interest

I heard the song from which I derived the title to this post sung by Florence and the Machine and was inspired to sit down and write about what I see as the future in program management.

Thus, my blogging radio silence has ended as I begin to process and share my observations and essential achievements over the last couple of years.

Some of my reticence in writing has been due to the continual drumbeat of both outrageous and polarizing speech that had dominated our lives for four years. Combined with the resulting societal polarization, I was overwhelmed by the hyper-politicized environment which has fostered disinformation and dysfunction. Those who wish to seek my first and current word on this subject need only visit my blog post, “In Defense of Empiricism” at the AITS Blogging Alliance here.

It is hard to believe that I published that post four years ago. I stand by it today and believe that it remains as valid, if not more so, than it did when I wrote and shared it.

Finally, the last and most important reason for my relative silence has been that I have been hard at work putting my money and reputation where my blogging fingers have been—in the face of a pandemic that has transformed and transfigured our social and economic lives.

My company—the conduit that provides the insights I share here—is SNA Software LLC. We are a small, veteran-owned company and we specialize in data capture, transformation, contextualization and visualization. We do it in a way that removes significant effort in these processes, ensures reliability and trust, to incorporate off-the-shelf functionality that provides insight, and empowers the user by leveraging the power of open systems, especially in program and project management.

Program and Project Management in the Public Interest

There are two aspects to the business world that we inhabit: commercial and government; both, however, usually relate to some aspect of the public interest, which is our forte.

There are also two concepts about this subject to unpack.

The first is distinguishing between program and project management. In this concept, a program is an overarching effort that may consist of individual efforts that, together, will result in the production or completion of a system, whether that is a weapons system, a satellite, a spacecraft, or an engine. It could even be a dam or some other aspect of public works.

A project under this concept is a self-contained effort separated organizationally from the larger entity, which possesses a clearly defined start and finish, a defined and allocated budget, and a set of plans, a performance management feedback system, and overarching goals or “framing assumptions” that define what constitutes the state of being “done.”

Oftentimes the terms “program” and “project” are used interchangeably, but the difference for these types of efforts is important and goes beyond a shallow understanding of the semantics. A program will also consider the lifecycle of the program: the follow-on logistics, the interrelationship of the end item to other components that will constitute the deployed system or systems, and any iterative efforts relating to improvement, revision, and modernization.

A word on the term “portfolio” is also worth a mention in the context of our theme. A portfolio is simply a summary of the projects or programs under an organizational entity that has both reporting and oversight responsibility for them. They may be interrelated or independent in their efforts, but all must report in some way, either due to fiduciary, resource, or oversight concerns, to that overarching entity.

The second concept relates to the term “public interest.” Programs and projects under this concept are those that must address the following characteristics: legality, governance, complexity, integrity, leadership, oversight, and subject matter expertise. I placed these in no particular order.

What we call in modern times “public interest” was originally called “public virtue” by the founders of the United States, which embody the ideals of the American Revolution, and upon which our experiment in democratic republicanism is built. It consists of conducting oneself in a manner in which the good of the whole—the public—outweighs personal interests and pursuits. Self-dealing need not apply.

This is no idealistic form of self-delusion: I understand, as do my colleagues, that we are, at heart, a commercial profit-making enterprise. But the manner in which we engage with government requires a different set of rules and many of these rules are codified in law and ethical practice. While others do not always feel obliged to live by these rules, we govern ourselves and so choose to apply these virtues—and to seek to support and change our system to encourage such behavior to as to be the norm—even in direct interactions with government personnel where we feel these virtues have been violated.

Characteristics of Public Interest Programs

Thus, the characteristics outlined above apply to program and project management in the public interest in the following manner:

Legality: That Public Interest Programs are an artifact of law and statute and are specifically designed to benefit the public as a whole.

At heart, program and project management are based on contractual obligations, whether those instruments apply internally or externally. As a result, everyone involved in the program and project management discipline is, by default, part of the acquisition community and the acquisition process. The law that applies to all government acquisition systems is based on the Federal Acquisition Regulation (FAR). There are also oversight and fiduciary responsibilities that apply as a result of the need for accountability under the Congressional appropriations process as well as ethical standards that apply, such as those under the Truth in Negotiations Act (TINA). While broad in the management flexibility they allow, violations of these statutes come with serious consequences. Thus, as a basis for establishing hard and fast guardrails in the management of programs and projects. Individual government agencies and military services also publish additional standards that supplement the legal requirements. An example is the Department of Defense FAR Supplement (DFARS). Commercial entities that hold government contracts in relation to Program Management Offices (PMOs) must sign on to both FAR and agency contractual clauses, which will then flow down to their subcontractors. Thus, the enforcement of these norms is both structured and consistent.

Governance: That the Organizational Structure and Disciplines deriving from Public Interest Programs are a result of both Contract and Regulatory Practice under the concept of Government Sovereignty.

The government and supplier PMOs are formed as a result of a contractual obligation for a particular purpose. Government contracting is unique since government entities are the sovereign. In the case of the United States, the sovereign is the elected government of the United States, which derives its legitimacy from the people of the United States as a whole. Constitutionally, the Executive Branch is tasked with the acquisition responsibility, but the manner and method of this responsibility is defined by statute.

Thus, during negotiations and unlike in commercial practice, the commercial entity is always the offeror and the United States always the party that either accepts or rejects the offer (the acceptor). This relationship has ramifications in contract enforcement and governance of the effort after award. It also allows the government to dictate the terms of the award through its solicitations. Furthermore, provisions from law establish cases where the burden for performance is on the entity (the supplier) providing the supplies and services.

Thus, the establishment of the PMO and oversight organizations have a legal basis, aside from considerations of best business practice. The details of governance within the bounds of legal guidance are those that apply through agency administrative law and regulation, oftentimes based on best business practice. These detailed practices of governance are usually established as a result of hard-learned experience: establishment of disciplines (systems engineering and technical performance, planning, performance management, cost control, financial execution, schedule, and progress assessment), the periodicity of reporting, the manner of oversight, the manner of liaison between the supplier and government PMOs, and alignment to the organization’s goals.

Complexity: That Public Interest Programs possess a level of both technical and organizational complexity unequaled in the private sector.

Program and project management in government involves a level of complexity rarely found in similar non-governmental commercial efforts. Aligning the contractual requirements, as an example, to an assessment of the future characteristics of a fighter aircraft needed to support the U.S. National Defense Strategy, built on the assessments by the intelligence agencies regarding future threats, is a unique aspect of government acquisition.

Furthermore, while relying on the expertise of private industry of such systems that support national defense, as well as those that support space exploration, energy, and a host of other needs, the items being acquired, which require cost type R&D contracts that involve program management, by definition are those where the necessary solutions are not readily available as commercial end items.

Oftentimes these requirements are built onto and extend existing off-the-shelf capabilities. But given that government investment in R&D represents the majority of this type of spending in the economy, absent it, technology and other efforts directed to meeting defense, economic, societal, climate, and space exploration challenges of the future would most likely not be met—or those that do will benefit only a portion of the populace. The federal government uniquely possesses the legal legitimacy, resources, and expertise to undertake such R&D that, pushing the envelope on capabilities, involves both epistemic and aleatory risk that can be managed through the processes of program management.

Integrity: The conduct of Public Interest Programs demands the highest level of commitment to a culture of accountability, impartiality, ethical conduct, fiduciary responsibility, democratic virtues, and honesty.

The first level of accountability resides in the conduct of the program manager, who is the locus of integrity within the program management office. This requires a focus on the duties the position demands as a representative of the Government of the United States. Furthermore, the program manager must ensure that the program team operate within the constraints established by the program’s or project’s contractual commitments, and that it continues to work to meeting the program goals that align with the stated interests and goals of the organization. That these duties are exercised regardless of self-interest is the basis of integrity.

This is not an easy discipline, and individuals oftentimes cannot separate their own interests from those of their duties. Yet, without this level of commitment, the legitimacy of the program office and the governmental enterprise itself is threatened.

In prior years, as an active-duty Supply Corps officer, I came across cases where individuals in civil service or among the commissioned officer community confused their own interests—for promotion, for self-aggrandizement, for ego—with those duties demanded of their rank or position. Such confusions of interests are serious transgressions. With contracted-out positions within program offices adding consulting and staffing firms into the mix, with their oftentimes diversified interests and portfolios, an additional layer of challenges is presented. Self-promotion, competition, and self-dealing have all too often become blatant, and program managers would do well to enforce strict rules regarding such behavior.

The pressures of exigency are oftentimes the main cause of the loss of integrity of the program or project. Personal interrelationships and human resource management issues can also undermine good order and discipline necessary for the program or project to organize itself into a cohesive, working team that is focused on a common vision.

Key elements mentioned in our opening thesis regarding ethical conduct, adherence to democratic virtues which include acceptance of all members of the team regardless of color, ethnicity, race, sexual identity, religion, or place of national origin. People deserve the respect and decency deriving from their basic human rights to enjoy human dignity, as well as of their position. Adding to these elements include honesty and the willingness to accept and report bad news, which is essential to integrity.

An organization committed to the principle of accountability will seek to measure and ensure that the goals of the program or project are being met, and that ameliorative measures are taken to correct any deficiencies. Since these efforts oftentimes involve years of effort involving significant sums of public monies, fiduciary integrity is essential to this characteristic.

All of these elements can and should exist in private, commercial practices. The difference that makes this a unique characteristic to program management in the public interest is the level of scrutiny, reporting, and review that is conducted: from oversight agencies within the Executive Department of the government, to the Congressional oversight, hearing and review processes, agency review, auditing and reporting, and inquires and critiques by the press and the public. Public interest program management is life in a fishbowl, except in the most secret efforts, and even those will eventually be subject to scrutiny.

As with a U.S. Navy ship that makes a port of call in a foreign country, the actions of the conduct of crew will not only reflect on themselves or their ship, but on the United States; so it is also with our program offices. Thus, systems of programmatic governance and business management must anticipate in their structure the level of adherence required. Given the inherent level of risk involved in these efforts, and given the normal amount of error human systems create even with good intentions and expertise, establishing a system committed to the elements of integrity creates a self-correcting one better prepared to meet the program’s or project’s challenges.

Leadership: Programs in the Public Interest differ from equivalent commercial efforts in that management systems and incentives based on profit- and shareholder-orientations do not exist. Instead, a special kind of skillset is required that includes good business management principles and skills combined with highly developed leadership traits.

Management skills tend to be a subset of leadership, though in business schools and professional courses they tend to be addressed as co-equal. This is understandable in commercial enterprises that focus on the capitalistic pressures regarding profit and market share.

Given the unique pressures imposed by the elements of integrity, the program manager and the program team are thrown into a situation that requires a focus on the achievement of organizational goals. In the case of program and project management, this will be expressed in the form of a set of “framing assumptions” that roll into an overarching vision.

A program office, of course, is more than a set of systems, practices, and processes. It is, first and foremost, a collection of individuals consisting of subject matter experts and professionals who must be developed into a team committed to the vision. The effort to achieve this team commitment is one of the more emotional and compelling elements that comprise leadership.

Human systems are adaptive ones, complex, which react and are created by both incentives and sanctions. Every group, especially involving creative and talented people, starts out being a collection of individuals with the interrelations among the members in an immature state. Underlying the expression of various forms of ambition and self-identification among mature individuals is the basic human need for social acceptance, born from the individual personal need for love. This motivation exists psychologically in all individuals except for sociopaths. It is also the basis for empathy and the acceptance of the autonomy of others, which form the foundation for team building.

The goal of the leader is to encourage maturity among the members of the group. The result is to create that overused term “synergy.” This is accomplished by doing those things as a leader necessary to develop members of the group that fosters trust, acceptance, and mutual respect. Admiral James L. Holloway, Jr., in his missive on Naval Leadership, instructed his young officers to eschew any concept of perfectionism in people. People make mistakes. We know this if we are to be brutally honest about our own experiences and actions.

Thus, intellectual honesty and an understanding on what motivates people within their cultural mores, above all else, is essential to good leadership. Americans, by nature, tend to be skeptical and independently minded. They require a level of explanation and due diligence that is necessary to win over their commitment to a goal or vision. When it comes to professionals operating within public service in government—who take an oath to the Constitution and our system of laws—the ability to lead tends to be more essential than just good management skills, though the latter are by no means unimportant. Management in private enterprise assumes a contentious workplace of competing values and interests, and oftentimes fosters it.

Program and project management in the public interest cannot succeed in such an environment. It requires a level of commitment to the goals of the effort regardless of personal values or interests among the individual members of the team. That they must be convinced to this level of commitment ensures that the values of leadership not only operate at the top of the management chain, but also at each of the levels and lateral relationships that comprise the team.

The shorthand for leadership in this culture is that the leader is “working their way out of their job,” and “that in order to be a good leader one must be a good follower,” meaning that all members of the team are well-informed, that their contributions, expertise and knowledge is acknowledged and respected, that individual points of failure through the irreplaceable person syndrome are minimized, and that each member of a team or sub-team can step in or step up to keep the operation functioning. The motivating concept in these situations are the interests of the United States, in lieu of a set of stockholders or some fiduciary reward.

Finally, there is the concept of the burden of leadership. Responsibility can be can be delegated, but accountability cannot. Leadership in this context entails an obligation to take responsibility for both the mission of the organization and the ethical atmosphere established in its governance.

Oversight: While the necessity for integrity anticipates the level of accountability, scrutiny, oversight, and reporting for Programs in the Public Interest, the environment this encompasses is unique compared to commercial entities.

The basis for acquisition at the federal level resides in the Article Two powers of the president as the nation’s Chief Executive. Congress, however, under its Article One powers, controls appropriations and passes laws related to the processes, procedures and management of the Executive Branch.

Flowing from these authorities, the agencies within the federal government have created offices for the oversight of the public’s money, the methods of acquisition of supplies and services, and the management of contracts. Contracting Officers are given authority through a warrant to exercise their acquisition authority under the guidance and management of a senior acquisition authority.

Unlike in private business, the government operates under the concept of Actual Authority. That is, no one may commit the government except those possessing a warrant. Program Managers are appointed to provide control and administration of cost type efforts, especially those containing R&D, to shepherd these efforts over the course of what usually constitutes a multi-year effort. The Contracting Officer and/or the senior acquisition authority in these cases will delegate contract administration authority to the Program Manager. As such, it is a very powerful position.

The inherent powers of the Executive Branch and the Legislative Branches of government create a tension that is resolved through a separation of powers and the ability of one branch to—at least in most cases—check the excesses and abuses of the other: the concept of checks and balances, especially through the operation of oversight.

When these tensions cannot be resolved within the processes established for separation of powers, the third branch of government becomes involved: this is the Judicial Branch. The federal judiciary has the ability to review all laws of the United States, their constitutionality, and their adherence to the letter of the law in the case of statute.

Wherever power exists within the federal government there exists systems of checks and balances. The reason for this is clear, and Lord Acton’s warning about power corrupting and absolute power corrupting absolutely is the operational concept.

Congress passes statutes and the Judiciary interprets the law, but it is up to the Executive Branch through the appointed heads of the various departments of government down through the civil service and, in the case of the Department of Defense, the military chain of command under civilian authority, to carry out the day-to-day activities in executing the laws and business of the government. This creates a large base of administrative law and procedure.

Administrative Law and the resulting procedures in their implementation come about due to the complexities in the statutes themselves, the tests of certain provisions of the statutes in the interplay between the various branches of government, and the practicalities of execution. This body of law and procedure is oftentimes confused with “regulation” in political discussions, but it is actually the means of ensuring that the laws are faithfully executed without undue political influence. It is usually supplemented by ethical codes and regulations as well.

As a part of this ecosystem, the Program in the Public Interest must establish a discipline related to self-regulation, due diligence, good business practice, fiduciary control, ethical and professional conduct, responsibility, and accountability. Just as the branches of the federal government are constructed to ensure oversight and checks-and-balances, this also exists with normative public administration within the Executive Branch agencies.

This is often referred to both positively and, mostly among political polemicists in the negative, as the bureaucracy. The development of bureaucracies in government is noted by historians and political scientists as an indication of political stability, maturity, and expertise. Without bureaucracies, governments tend to be capricious and their policies uncertain. The practice of stare decisis—the importance of precedent in legal decisions—is also part and parcel of stability. Government power can be beneficial or coercive. Resting action on laws and not the whims or desires of the individual person is essential to the good order and discipline of the federal government.

As such, program and project managers, given the extensive latitude and inherent powers of their position, are subject to rigorous reporting, oversight, and accountability regimes in the performance of their duties. In R&D cost-type program and project management efforts, the risk is shared between the supplier and the government. And the government flows down this same regime to the contractor to ensure the integrity of the effort in the expenditure of public monies and under the performance and delivery of public contacts.

This leads us to the last important aspect of oversight: public scrutiny, which also includes the press as the Fourth Estate. When I was a young Lieutenant in the Navy working in contracts the senior officer to whom I was assign often remarked: “Never do anything that would cause you to be ashamed were it to end up being read by your grandmother in the Washington Post.”

Unlike private business where law, contractual obligation, and fiduciary responsibility are the main pressures on tolerated behavior, the government and its actions are—and must be—under constant public scrutiny. It is expected. Senior managers who champ against the bit of this check on official conduct misunderstand their role. Even the appearance of malfeasance or abuse can cause one to steer into the rocks and shoals.

Subject Matter Expertise: Given the interrelated characteristics of legality, governance, complexity, integrity, leadership, and oversight—linked to the development of a professional, permanent bureaucracy acting through a non-partisan civil service—the practices necessary to successfully shepherd such efforts has produced areas of expertise and specialization. These areas provide a basis for leveraging technology in gaining insight into meeting all of the requirements necessary to the good administration and control of Program Management in the Public Interest.

The structures and practices of program and project management are reflected in the private economy. Some of this is contractually prescribed and some of it is based on best business practice learned through hard experience. In the interplay of government and industry, most often an innovation in one has been refined and improved in the other, only to find its way back to practice on the originating “side” of the transaction.

Initially in our history this cross-fertilization occurred through extraordinary wartime measures: standardization of rifled weaponry passed down by Thomas Jefferson and Eli Whitney, and for railroad track gauge standards issued by the Union government during the Civil War, are just two examples that turned out to provide a decisive advantage against laissez faire and libertarian approaches.

As the complexity of private business concerns, particularly in the international sphere, began to mimic—and in many cases surpass—the size and technical complexity of many individual government efforts, partnerships with civil authorities and private businesses saw the need for industry standardization for both electrical and non-electrical components and processes. The former was particularly important in the “Current Wars” between Edison and Westinghouse.

These simple and earlier examples highlight the great conundrum of standardization of supply, practice and procedure in acquisition: the need for economy through competition of many sources for any particular commodity or item weighed against the efficiency and interoperability needed to continue operations. Buying multiple individual items with the same function but produced using differing standards creates a nightmare of suboptimization. Overly restrictive standards can and have had the effect of reducing competition and stifling innovation, especially if the standard is proprietary.

In standards setting there are several interests involved that must be taken into account: the technical expertise (technical, qualitative, etc.) that underlies the standard, the public interest in ensuring a healthy marketplace that rewards innovation, diversity, and price competitiveness, the need for business-to-business cooperation and synergy in the marketplace, and the preponderance of practice, among others. In the Defense industry this also includes national security concerns.

This last consideration provides an additional level of tension between private industry and government interests. In the competition for market share and market niches, businesses are playing a zero-sum game that shifts between allies and competitors. Still, the interest of individual actors is focused on making a proprietary product or service dominant in the target market.

Government, on the other hand, particularly one that operates as a republic based on democratic processes and virtues and a commitment to equal rights, has a different set of interests that are, in many cases, diametrically opposed to those of individual players in the marketplace. Government needs and desires a broad choice of sources for what it needs, while ensuring that qualitative standards are met under a fair and reasonable price. When it does find innovation, it seeks to reward it, but only for the limited terms, conditions, and period of the contractual instrument.

The greater the risk in these cases—especially when cost risk is shared—the greater the need for standards, especially qualitative ones. The longer the term of the effort, the greater the need for checks and balances through evaluation, review, and oversight. The greater the dollar value, the greater importance for fiduciary and contractual accountability.

Thus, subject matter expertise has evolved over time, aligned with the functions and end items being developed and delivered. These areas include:

Estimating – A critical part of program and project management, this is a discipline with highly specialized quantitative methods for estimating and projecting project costs, resources, and duration. It is part of the planning phase prior to program or project inception. It can be used to support budget planning prior to program approval, during negotiations and, after award, to inform the project plan.

Systems Engineering – as described by the International Council of Systems Engineering, “a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.”

As it relates to program and project management, the technical documents related to providing the basis and structure of the lifecycle management of the end item application, including the application of technical standards, measures of effectiveness, measures of performance, key performance parameters, and technical performance measures. In simplistic terms, systems engineering defines when the item under R&D reaches the state of “done.”

Financial Management – at the program and project management level, the planning, organizing, directing and controlling the financial activities such as procurement and utilization of funds to adhere to the limitations of law and consistent with the terms and conditions of the contract and the its ancillary planning and execution documents.

At its core, financial management within this discipline includes the planning, programming, budgeting, and execution process for the financial requirements of successful program execution. As with any individual enterprise, cashflow for required activities with the right type of money determined by Congressional appropriation presents a unique and specialized skillset under program management in the public interest. Oftentimes the lack of funds necessary to address a particular programmatic risk or challenge can be just as decisive to program execution and success as any technical challenge.

Risk and Uncertainty – the concept of risk and uncertainty have evolved over time. Under classical economics (both Keynes and Knight), risk is where all of the future events and consequences of an action are known, but where specific outcomes are unknown. As such, probability calculus is applied to determine the risk management: mitigation and handling. Uncertainty, under this definition, is unknowable events that will result from our actions and is implicit in human action. There is no probability calculus or risk buy-down that can address areas of uncertainty. These definitions are also accepted under the concept of complexity economics.

My good colleague Glen Alleman (2013) at his blog, Herding Cats, casts risk as a product of uncertainty. This is a reordering of definitions, but not unuseful. Under Glen’s approach, uncertainty is broken into aleatory and epistemic uncertainty. The first—aleatory—comes from a random process, what Keynes, Knight, et al. would define as classical uncertainty. The second—epistemic—comes from lack of knowledge. The first is irreducible, which is consistent with classical economics and complexity economics; the second is subject to probability analysis and risk handling methodologies.

Both risk and uncertainty—aleatory and epistemic—occur within all phases and under each discipline within the project management environment. Any human action involves these forces of cause-and-effect and uncertainty—and limit our actions under the concept of “free will.”

Planning and Scheduling – usually these have been viewed as separate entities, but they are, in fact, part of a continuum, as are all of the disciplines mentioned, but more on that later in these blogs.

Planning involves the ability to derive the products of both the contract terms and conditions, and the systems engineering process. The purpose is to develop a high-level, time-phased plan that captures program events, deliverables, requirements, significant accomplishment criteria, and basic technical performance management achievement that will be the basis for a more detailed integrated master schedule.

The scheduling discipline is tasked with further delineating the summary tasks into schedule activities based on critical path methodology. A common refrain when I worked on the government side of program management was that you cannot eat an elephant in one gulp: you have to eat it one piece at a time.

As it relates to this portion of project methodology, I have, over the years, heard people say that planning and scheduling is more of an art instead of a science. Yet, the artifacts upon which our planning documents rest exist as part of the acquisition process and our systems and procedures are mature and largely standardized. The methods of systems engineering are precise and consistent.

The lexicon of planning and scheduling, regardless of the software applications or manual methods used, describe the same phenomenon and concepts, despite slightly different—and oftentimes proprietary—terminology. The concept of critical path analysis is well documented in the literature with slight, though largely insignificant, differences in application.

What appears as art is, in reality, a process that involves a great deal of complexity because these are the documents upon which all of the moving parts of the program are documented. Rather than art, it is a discipline that requires attention to detail and collaboration, aside from the power of computing.

Resource Management – as with planning and scheduling, resource management consists of a detailed accounting of the people, equipment, monies, and suppliers that are required to achieve the activities detailed in the program schedule.

In the detailed and specialized planning of projects and programs in the public interest, these efforts are cross-referenced and further delineated to the actual work that needs to be completed. A Work Breakdown Structure (or WBS), is the method of time-phasing the work using detailed tasks that integrate scope, cost, and schedule at the lowest level of achievement.

Baselining and Performance Management – are essential for project control in this environment. In this case, project and program schedule, cost, and resources are (ideally) risk adjusted and a performance management baseline is established: the basis for the assessment and control of the project.

This leads us to the methodology that is always on the cusp of being the Ozymandias of program management: earned value management or EVM. The discipline of EVM arose out of the Space Age era of the 1960s. The premise is simple: when undertaking any complex effort there is a finite amount of money and resources, and a target date for the needed end item. We need a method to determine whether the actual work performed in terms of budgeted resources and time is tracking to the plan to produce the desired end item application.

When looking at the utility of EVM, one must ask: while each of the disciplines noted above also track achievement over the lifecycle of the project or program, do any combine an analysis against budgeted time and resources? The answer is no, and so EVM is essential to management of these efforts.

Still, our other disciplines also track important information that is not captured by EVM. Thus, the entire corpus of our disciplines represents the project and program ecosystem. These processes, procedures, and the measures derived from them are interconnected. It is this salient fact that points us in the direction regarding the future of program management.

Conclusions from Part One

Given that we have outlined the unique and distinctive characteristics of public interest program management, the environment and basis upon which such program management rests, and the highly developed disciplines that have evolved as a result of the experience in system development, deployment, and lifecycle management, our inquiry must next explore the evolutionary nature of the program organization itself. Once identified and delineated, we must then determine the place of program organization within the context of developments in systems and information theory which will give us insight into the future of program management.

More on Excel…the contributing factor of poor Project Management apps

Some early comments via e-mails on my post on why Excel is not a PM tool raised the issue that I was being way too hard on IT shops and letting application providers off the hook.  The asymmetry was certainly not the intention (at least not consciously).

When approaching an organization seeking process and technology improvement, oftentimes the condition of using Excel is what we in the technology/PM industry conveniently call “workarounds.”  Ostensibly these workarounds are temporary measures to address a strategic or intrinsic organizational need that will eventually be addressed by a more cohesive software solution.  In all too many cases, however, the workaround turns out to be semi-permanent.

A case in point in basic project management concerns Work Authorizations Documents (WADs) and Baseline Change Requests (BCRs).  Throughout entire industries who use the most advanced scheduling applications, resource management applications, and–where necessary–earned value “engines,” the modus operandi to address WADs and BCRs is to either use Excel or to write a custom app in FoxPro or using Access.  This is fine as a “workaround” as long as you remember to set up the systems and procedures necessary to keep the logs updated, and then have in place a procedure to update the systems of record appropriately.  Needless to say, errors do creep in and in very dynamic environments it is difficult to ensure that these systems are in alignment, and so a labor-intensive feedback system must also be introduced.

This is the type of issue that software technology was designed to solve.  Instead, software has fenced off the “hard’ operations so that digitized manual solutions, oftentimes hidden from plain view from the team by the physical technological constraint of the computer (PC, laptop, etc.), are used.  This is barely a step above what we did before the introduction of digitization:  post the project plan, milestone achievements, and performance on a VIDS/MAF board that surrounded the PM control office, which ensured that every member of the team could see the role and progress of the project.  Under that system no one hoarded information, it militated against single points of failure, and ensured that disconnects were immediately addressed since visibility ensured accountability.

In many ways we have lost the ability to recreate the PM control office in digitized form.  Part of the reason resides in the 20th century organization of development and production into divisions of labor.  In project management, the specialization of disciplines organized themselves around particular functions: estimating and planning, schedule management, cost management, risk management, resource management, logistics, systems engineering, operational requirements, and financial management, among others.  Software was developed to address each of these areas with clear lines of demarcation drawn that approximated the points of separation among the disciplines.  What the software manufacturers forgot (or never knew) was that the PMO is the organizing entity and it is an interdisciplinary team.

To return to our example: WADs and BCRs; a survey of the leading planning and scheduling applications shows that while their marketing literature addresses baselines and baseline changes (and not all of them address even this basic function), they still do not understand complex project management.  There is a difference between resources assigned to a time-phased network schedule and the resources planned against technical achievement related to the work breakdown structure (WBS).  Given proper integration they should align.  In most cases they do not.  This is why most scheduling application manufacturers who claim to measure earned value, do not.  Their models assume that the expended resources align with the plan to date, in lieu of volume-based measurement.  Further, eventually understanding this concept does not produce a digitized solution, since an understanding of the other specific elements of program control is necessary.

For example, projects are initiated either through internal work authorizations in response to a market need, or based on the requirements of a contract.  Depending on the mix of competencies required to perform the work financial elements such as labor rates, overhead, G&A, allowable margin (depending on contract type), etc. will apply–what is euphemistically called “complex rates.”  An organization may need to manage multiple rate sets based on the types of efforts undertaken, with a many-to-many relationship between rate sets and projects/subprojects.

Once again, the task of establishing the proper relationships at the appropriate level is necessary.  This will then affect the timing of WAD initiation, and will have a direct bearing on the BCR approval process, given that it is heavily influenced by “what-if?” analysis against resource, labor, and financial availability and accountability (a complicated process in itself).  Thus the schedule network is not the only element affected, nor the overarching one, given the assessed impact on cost, technical achievement, and qualitative external risk.

These are but two examples of sub-optimization due to deficiencies in project management applications.  The response–and in my opinion a lazy one (or one based on the fact that oftentimes software companies know nothing of their customers’ operations)–has been to develop the alternative euphemism for “workaround”: best of breed.  Oftentimes this is simply a means of collecting revenue for a function that is missing from the core application.  It is the software equivalent of division of labor: each piece of software performs functions relating to specific disciplines and where there are gaps these are filled by niche solutions or Excel.  What this approach does not do is meet the requirements of the PMO control office, since it perpetuates application “swim lanes,” with the multidisciplinary requirements of project management relegated to manual interfaces and application data reconciliation.  It also pushes–and therefore magnifies–risk at the senior level of the project management team, effectively defeating organizational fail safes designed to reduce risk through, among other methods, delegation of responsibility to technical teams, and project planning and execution constructed around short duration/work-focused activities.  It also reduces productivity, information credibility, and unnecessarily increases cost–the exact opposite of the rationale used for investing in software technology.

It is time for this practice to end.  Technologies exist today to remove application “swim lanes” and address the multidisciplinary needs of successful project management.  Excel isn’t the answer; cross-application data access, proper data integration, and data processing into user-directed intelligence, properly aggregated and distributed based on role and optimum need to know, is.

Synchroncity — What is proper schedule and cost integration?

Much has been said about the achievement of schedule and cost integration (or lack thereof) in the project management community.  Much of it consists of hand waving and magic asterisks that hide the significant reconciliation that goes on behind the scenes.  From an intellectually honest approach that does not use the topic as a means of promoting a proprietary solution is that authored by Rasdorf and Abudayyeah back in 1991 entitled, “Cost and Schedule Control Integration: Issues and Needs.”

It is worthwhile revisiting this paper, I think, because it was authored in a world not yet fully automated, and so is immune to the software tool-specific promotion that oftentimes dominates the discussion.  In their paper they outlined several approaches to breaking down cost and work in project management in order to provide control and track performance.  One of the most promising methods that they identified at the time was the unified approach that had originated in aerospace, in which a work breakdown structure (WBS) is constructed based on discrete work packages in which budget and schedule are unified at a particular level of detail to allow for full control and traceability.

The concept of the WBS and its interrelationship to the organizational breakdown structure (OBS) has become much more sophisticated over the years, but there has been a barrier that has caused this ideal to be fully achieved.  Ironically it is the introduction of technology that is the culprit.

During the first phase of digitalization that occurred in the project management industry not too long after Radsdorf and Abudayyeah published their paper, there was a boom in dot coms.  For business and organizations the practice was to find a specialty or niche and fill it with an automated solution to take over the laborious tasks of calculation previously achieved by human intervention.  (I still have both my slide rule and first scientific calculator hidden away somewhere, though I have thankfully wiped square root tables from my memory).

For those of us who worked in project and acquisition management, our lives were built around the 20th century concept of division of labor.  In PM this meant we had cost analysts, schedule analysts, risk analysts, financial analysts and specialists, systems analysts, engineers broken down by subspecialties (electrical, mechanical, systems, aviation) and sub-subspecialties (Naval engineers, aviation, electronics and avionics, specific airframes, software, etc.).  As a result, the first phase of digitization followed the pathway of the existing specialties, finding niches in which to inhabit, which provided a good steady and secure living to software companies and developers.

For project controls, much of this infrastructure remains in place.  There are entire organizations today that will construct a schedule for a project using one set of specialists and the performance management baseline (PMB) in another, and then reconciling the two, not just in the initial phase of the project, but across the entire life of the project.  From the standard of the integrated structure that brings together cost and schedule this makes no practical sense.  From a business efficiency perspective this is an unnecessary cost.

As much as it is cited by many authors and speakers, the Coopers & Lybrand with TASC, Inc. paper entitled “The DoD Regulatory Cost Premium” is impossible to find on-line.  Despite its widespread citation the study demonstrated that by the time one got down to the third “cost” driver due to regulatory requirements that the projected “savings” was a fraction of 1% of the total contract cost.  The interesting issue not faced by the study is, were the tables turned, how much would such contracts be reduced if all management controls in the company were reduced or eliminated since they contribute as elements to overhead and G&A?  More to the point here, if the processes applied by industry were optimized what would the be the cost savings involved?

A study conduct by RAND Corporation in 2006 accurately points out that a number of studies had been conducted since 1986, all of which promised significant impacts in terms of cost savings by focusing on what were perceived as drivers for unnecessary costs.  The Department of Defense and the military services in particular took the Coopers & Lybrand study very seriously because of its methodology, but achieved minimal savings against those promised.  Of course, the various studies do not clearly articulate the cost risk associated with removing the marginal cost of oversight and regulation. Given our renewed experience with lack of regulation in the mortgage and financial management sectors of the economy that brought about the worst economic and financial collapse since 1929, one my look at these various studies in a new light.

The RAND study outlines the difficulties in the methodologies and conclusions of the studies undertaken, especially the acquisition reforms initiated by DoD and the military services as a result of the Coopers & Lybrand study.  But, how, you may ask does this relate to cost and schedule integration?

The present means that industry uses in many places takes a sub-optimized approach to project management, particularly when it applies to cost and schedule integration, which really consists of physical cost and schedule reconciliation.  A system is split into two separate entities, though they are clearly one entity, constructed separately, and then adjusted using manual intervention which defeats the purpose of automation.  This may be common practice but it is not best practice.

Government policy, which has pushed compliance to the contractor, oftentimes rewards this sub-optimization and provides little incentive to change the status quo.  Software industry manufacturers who are embedded with old technologies are all too willing to promote the status quo–appropriating the term “integration” while, in reality, offering interfaces and workarounds after the fact.  Those personnel residing in line and staff positions defined by the mid-20th century approach of division of labor are all too happy to continue operating using outmoded methods and tools.  Paradoxically these are personnel in industry that would never advocate using outmoded airframes, jet engines, avionics, or ship types.

So it is time to stop rewarding sub-optimization.  The first step in doing this is through the normalization of data from these niche proprietary applications and “rewiring” them at the proper level of integration so that the systemic faults can be viewed by all stakeholders in the oversight and regulatory chain.  Nothing seems to be more effective in correcting a hidden defect than some sunshine and a fresh set of eyes.

If industry and government are truly serious about reforming acquisition and project management in order to achieve significant cost savings in the face of tight budgets and increasing commitments due to geopolitical instability, then systemic reforms from the bottom up are the means to achieve the goal; not the elimination of controls.  As John Kennedy once said in paraphrasing Chesterton, “Don’t take down a fence unless you know why it was put up.”  The key is not to undermine the strength and integrity of the WBS-based approach to project control and performance measurement (or to eliminate it), but to streamline it so that it achieves its ideal as closely as our inherently faulty tools and methods will allow.

 

I’ve Got Your Number — Types of Project Measurement and Services Contracts

Glen Alleman reminds us at his blog that we measure things for a reason and that they include three general types: measures of effectiveness, measures of performance, and key performance parameters.

Understanding the difference between these types of measurement is key, I think, to defining what we mean by such terms as integrated project management and in understanding the significance of differing project and contract management approaches based on industry and contract type.

For example, project management focused on commodities, with their price volatility, emphasizes schedule and resource management. Cost performance (earned value) where it exists, is measured by time in lieu of volume- or value-based performance. I have often been engaged in testy conversations where those involved in commodity-based PM insist that they have been using Earned Value Management (EVM) for as long as the U.S.-based aerospace and defense industry (though the methodology was borne in the latter). But when one scratches the surface the approaches in the details on how value and performance is determined is markedly different–and so it should be given the different business environments in which enterprises in each of these industries operate.

So what is the difference in these measures? In borrowing from Glen’s categories, I would like to posit a simple definitional model as follows:

Measures of Excellence – are qualitative measures of achievement against the goals in the project;

Measures of Performance – are quantitative measures against a plan or baseline in execution of the project plan.

Key Performance Parameters – are the minimally acceptable thresholds of achievement in the project or effort.

As you may guess there is sometimes overlap and confusion regarding which category a particular measurement falls. This confusion has been exacerbated by efforts to define key performance indicators (KPIs) based on industry, giving the impression that measures are exclusive to a particular activity. While this is sometimes the case it is not always the case.

So when we talk of integrated project management we are not accepting that any particular method of measurement has primacy over the others, nor subsumes them. Earned Value Management (EVM) and schedule performance are clearly performance measures. Qualitative measures oftentimes measure achievement of technical aspects of the end item application being produced. This is not the same as technical performance measurement (TPM), which measures technical achievement against a plan–a performance measure. Technical achievement may inform our performance measurement systems–and it is best if it does. It may also inform our Key Performance Parameters since exceeding a minimally acceptable threshold obviously helps us to determine success or failure in the end. The difference is the method of measurement. In a truly integrated system the measurement of one element informs the others. For the moment these systems presently tend to be stove-piped.

It becomes clear, then, that the variation in approaches differs by industry, as in the example on EVM above, and–in an example that I have seen most recently–by contract type. This insight is particularly important because all too often EVM is viewed as being synonymous with performance measurement, which it is not. Services contracts require structure in measurement as much as R&D-focused production contracts, particularly because they increasingly take up a large part of an enterprise’s resources. But EVM may not be appropriate.

So for our notional example, let us say that we are responsible for managing an entity’s IT support organization. There are types of equipment (PCs, tablet computers, smartphones, etc.) that must be kept operational based on the importance of the end user. These items of hardware use firmware and software that must be updated and managed. Our contract establishes minimal operational parameters that allow us to determine if we are at least meeting the basic requirements and will not be terminated for cause. The contract also provides incentives to encourage us to exceed the minimums.

The sites we support are geographically dispersed. We have to maintain a help desk but also must have people who can come onsite and provide direct labor to setup new systems or fix existing ones–and that the sites and personnel must be supported within a particular time-frame: one hour, two hours, and within twenty-four hours, etc.

In setting up our measurement systems the standard practice is to start with the key performance parameters. Typically we will also measure response times by site and personnel level, record our help desk calls, and track qualitative aspects of the work: How helpful is the help desk? Do calls get answered at the first contract? Are our personnel friendly and courteous? What kinds of hardware and software problems do we encounter? We collect our data from a variety of one-off and specialized sources and then we generate reports from these systems. Many times we will focus on those that will allow us to determine if the incentive will be paid.

Among all of this data we may be able to discern certain things: if the contract is costing more or less than we anticipated, if we are fulfilling our contractual obligations, if our personnel pools are growing or shrinking, if we are good at what we do on a day-to-day basis, and if it looks as if our margin will be met. But what these systems do not do is allow us to operate the organization as a project, nor do they allow us to make adjustments in a timely manner.

Only through integration and aggregation can we know, for example, how the demand for certain services is affecting our resource demands by geographical location and level of service, on a real=time basis where we need to make adjustments in personnel and training, whether we are losing or achieving our margin by location, labor type, equipment type, hardware vs. software; our balance sheets (by location, by equipment type, by software type, etc.), if there is a learning curve, and whether we can make intermediate adjustments to achieve the incentive thresholds before the result is written in stone. Having this information also allows us to manage expectations, factually inform perceptions, and improve customer relations.

What is clear by this example is that “not doing EVM” does not make measurement easy, nor does it imply simplification, nor the absence of measurement. Instead, understanding the nature of the work allows us to identify those measures within their proper category that need to be applied by contract type and/or industry. So while EVM may not apply to services contracts, we know that certain new aggregations do apply.

For many years we have intuitively known that construction and maintenance efforts are more schedule-focused, that oil and gas exploration more resource- and risk-focused, and that aircraft, satellites, and ships more performance-focused. I would posit that now is the time for us to quantify and formalize the commonalities and differences. This also makes an integrated approach not simply a “nice to have” capability, but an essential capability in managing our enterprises and the projects within them.

Note: This post was updated to correct grammatical errors.

I Can’t Get No (Satisfaction) — When Software Tools Go Bad

Another article I came across a couple of weeks ago that my schedule prevented me from highlighting was by Michelle Symonds at PM Hut entitled “5 Tell-Tale Signs That You Need a Better Project Management Tool.”  According to Ms. Symonds, among these signs are:

a.  Additional tools are needed to achieve the intended functionality apart from the core application;

b.  Technical support is poor or nonexistent;

c.  Personnel in the organization still rely on spreadsheets to extend the functionality of the application;

d.  Training on the tool takes more time than training the job;

e.  The software tool adds work instead of augmenting or facilitating the achievement of work.

I have seen situations where all of these conditions are at work but the response, in too many cases, has been “well we put so much money into XYZ tool with workarounds and ‘bolt-ons’ that it will be too expensive/disruptive to change.”  As we have advanced past the first phases of digitization of data, it seems that we are experiencing a period where older systems do not quite match up with current needs, but that software manufacturers are very good at making their products “sticky,” even when their upgrades and enhancements are window dressing at best.

In addition, the project management community, particularly focused on large projects in excess of $20M is facing the challenge of an increasingly older workforce.  Larger economic forces at play lately have exacerbated this condition.  Aggregate demand and, on the public side, austerity ideology combined with sequestration, has created a situation where highly qualified people are facing a job market characterized by relatively high unemployment, flat wages and salaries, depleted private retirement funds, and constant attacks on social insurance related to retirement.  Thus, people are hanging around longer, which limits opportunities for newer workers to grow into the discipline.  Given these conditions, we find that it is very risky to one’s employment prospects to suddenly forge a new path.  People in the industry that I have known for many years–and who were always the first to engage with new technologies and capabilities–are now very hesitant to do so now.  Some of this is well founded through experience and consists of healthy skepticism: we all have come across snake oil salesmen in our dealings at one time or another, and even the best products do not always make it due to external forces or the fact that brilliant technical people oftentimes are just not very good at business.

But these conditions also tend to hold back the ability of the enterprise to implement efficiencies and optimization measures that otherwise would be augmented and supported by appropriate technology.  Thus, in addition to those listed by Ms. Symonds, I would include the following criteria to use in making the decision to move to a better technology:

a.  Sunk and prospective costs.  Understand and apply the concepts of sunk cost and prospective cost.  The first is the cost that has been expended in the past, while the latter focuses on the investment necessary for future growth, efficiencies, productivity, and optimization.  Having made investments to improve a product in the past is not an argument for continuing to invest in the product in the future that trumps other factors.  Obviously, if the cash flow is not there an organization is going to be limited in the capital and other improvements it can make but, absent those considerations, sunk cost arguments are invalid.  It is important to invest in those future products that will facilitate the organization achieving its goals in the next five or ten years.

b.  Sustainability.  The effective life of the product must be understood, particularly as it applies to an organization’s needs.  Some of this overlaps the points made by Ms. Symonds in her article but is meant to apply in a more strategic way.  Every product, even software, has a limited productive life but my concept here goes to what Glen Alleman pointed out in his blog as “bounded applicability.”  Will the product require more effort in any form where the additional effort provides a diminishing return?  For example, I have seen cases where software manufacturers, in order to defend market share, make trivial enhancements such as adding a chart or graph in order to placate customer demands.  The reason for this should be, but is not always obvious.  Oftentimes more substantive changes cannot be made because the product was built on an earlier generation operating environment or structure.  Thus, in order to replicate the additional functionality found by newer products the application requires a complete rewrite.  All of us operating in this industry has seen this; where a product that has been a mainstay for many years begins to lose market share.  The decision, when it is finally made, is to totally reengineer the solution, but not as an upgrade to the original product, arguing that it is a “new” product.  This is true in terms of the effort necessary to keep the solution viable, but that then also completely undermines justifications based on sunk costs.

c.  Flexibility.  As stated previously in this blog, the first generation of digitization mimicked those functions that were previously performed manually.  The applications were also segmented and specialized based on traditional line and staff organizations, and specialties.  Thus, for project management, we have scheduling applications for the scheduling discipline (such as it is), earned value engines for the EV discipline, risk and technical performance applications for risk specialists and systems engineers, analytical software for project and program analysts, and financial management applications that subsumed project and program management financial management professionals.  This led to the deployment of so-called best-of-breed configurations, where a smorgasbord of applications or modules were acquired to meet the requirements of the organization.  Most often these applications had and have no direct compatibility, requiring entire staffs to reconcile data after the fact once that data was imported into a proprietary format in which it could be handled.  Even within so-called ERP environments under one company, direct compatibility at the appropriate level of the data being handled escaped the ability of the software manufacturers, requiring “bolt-ons” and other workarounds and third party solutions.  This condition undermines sustainability, adds a level of complexity that is hard to overcome, and adds a layer of cost to the life-cycle of the solutions being deployed.

The second wave to address some of these limitations focused on data flexibility using cubes, hard-coding of relational data and mapping, and data mining solutions: so-called Project Portfolio Management (PPM) and Business Intelligence (BI).  The problem is that, in the first instance, PPM simply another layer to address management concerns, while early BI systems froze in time single points of failure into hard-coded deployed solutions.

A flexible system is one that leverages the new advances in software operating environments to solve more than one problem.  This, of course, undermines the financial returns in software, where the pattern has been to build one solution to address one problem based on a specialty.  Such a system provides internal flexibility, that is, allows for the application of objects and conditional formatting without hardcoding, pushing what previously had to be accomplished by coders to the customer’s administrator or user level; and external flexibility, where the same application can address, say, EVM, schedule, risk, financial management, KPIs, technical performance, stakeholder reporting, all in the same or in multiple deployed environments without the need for hardcoding.  In this case the operating environment and any augmented code provides a flexible environment to the customer that allows one solution to displace multiple “best-of-breed” applications.

This flexibility should apply not only vertically but also horizontally, where data can be hierarchically organized to allow not only for drill-down, but also for roll-up.  Data in this environment is exposed discretely, providing to any particular user that data, aggregated as appropriate, based on their role, responsibility, or need to know.

d.  Interoperability and open compatibility.  A condition of the “best-of-breed” deployment environment is that it allows for sub-optimization to trump organizational goals.  The most recent example that I have seen of this is where it is obvious that the Integrated Master Schedule (IMS) and Performance Management Baseline (PMB) were obviously authored by different teams in different locations and, most likely, were at war with one another when they published these essential interdependent project management artifacts.

But in terms of sustainability, the absence of interoperability and open compatibility has created untenable situations.  In the example of PMB and IMS information above, in many cases a team of personnel must be engaged every month to reconcile the obvious disconnectedness of schedule activities to control accounts in order to ensure traceability in project management and performance.  Surely, not only should there be no economic rewards for such behavior, I believe that no business would perform in that manner without them.

Thus, interoperability in this case is to be able to deal with data in its native format without proprietary barriers that prevent its full use and exploitation to the needs and demands of the customer organization.  Software that places its customers in a corner and ties their hands in using their own business information has, indeed, worn out its welcome.

The reaction of customer organizations to the software industry’s attempts to bind them to proprietary solutions has been most marked in the public sector, and most prominently in the U.S. Department of Defense.  In the late 1990s the first wave was to ensure that performance management data centered around earned value was submitted in a non-proprietary format known as the ANSI X12 839 transaction set.  Since that time DoD has specified the use of the UN/CEFACT XML D09B standard for cost and schedule information, and it appears that other, previously stove-piped data will be included in that standard in the future.  This solution requires data transfer, but it is one that ensures that the underlying data can be normalized regardless of the underlying source application.  It is especially useful for stakeholder reporting situations or data sharing in prime and sub-contractor relationships.

It is also useful for pushing for improvement in the disciplines themselves, driving professionalism.  For example, in today’s project management environment, while the underlying architecture of earned value management and risk data is fairly standard, reflecting a cohesiveness of practice among its practitioners, schedule data tends to be disorganized with much variability in how common elements are kept and reported.  This also reflects much of the state of the scheduling discipline, where an almost “anything goes” mentality seems to be in play reflecting not so much the realities of scheduling practice–which are pretty well established and uniform–as opposed to the lack of knowledge and professionalism on the part of schedulers, who are tied to the limitations and vagaries of their scheduling application of choice.

But, more directly, interoperability also includes the ability to access data (as opposed to application interfacing, data mining, hard-coded Cubes, and data transfer) regardless of the underlying database, application, and structured data source.  Early attempts to achieve interoperability and open compatibility utilized ODBC but newer operating environments now leverage improved OLE DB and other enhanced methods.  This ability, properly designed, also allows for the deployment of transactional environments, in which two-way communication is possible.

A new reality.  Thus given these new capabilities, I think that we are entering a new phase in software design and deployment, where the role of the coder in controlling the UI is reduced.  In addition, given that the large software companies have continued to support a system that ties customers to proprietary solutions, I do not believe that the future of software is in open source as so many prognosticators stated just a few short years ago.  Instead, I propose that applications that behave like open source but allow those who innovate and provide maximum value, sustainability, flexibility, and interoperability to the customer are those that will be rewarded for their efforts.

Note:  This post was edited for clarity and grammatical errors from the original.

 

The Times They Are A-Changin’–Should PMI Be a Project Management Authority?

Back from a pretty intense three weeks taking care of customers (yes–I have those) and attending professional meetings and conferences.  Some interesting developments regarding the latter that I will be writing about here, but while I was in transit I did have the opportunity to keep up with some interesting discussions within the project management community.

Central among those was an article by Anonymous on PM Hut that appeared a few weeks ago that posited the opinion that PMI Should No Longer Be an Authority on Project Management.  I don’t know why the author of the post decided that they had to remain anonymous.  I learned some time ago that one should not only state their opinion in as forceful terms as possible (backed up with facts), but to own that opinion and be open to the possibility that it could be wrong or require modification.  As stated previously in my posts, project management in any form is not received wisdom.

The author of the post makes several assertions summarized below:

a. That PMI, though ostensibly a not-for-profit organization, behaves as a for-profit organization, and aggressively so.

b.  The Project Management Body of Knowledge (PMBOK®) fails in its goal of being the definitive source for project management because it lacks continuity between versions, its prescriptions lack realism, and, particularly in regard to software project management, that this section has morphed into a hybrid of Waterfall and Agile methodology.

c.  The PMI certifications lack credibility and seem to be geared to what will sell, as opposed to what can be established as a bonafide discipline.

I would have preferred that the author had provided more concrete examples of these assertions, given their severity.  For example, going to the on-line financial statements of the organization, PMI does have a significant staff of paid personnel and directors, with total assets as of 2012 of over $300M.  Of this, about $267M is in investments.  It’s total revenue that year was $173M.  It spent only $115M from its cashflow on its programs and another $4M on governance and executive management compensation.  Thus, it would appear that the non-profit basis of the organization has significantly deviated from its origins at the Georgia Institute of Technology.  Project management is indeed big business with vesting and compensation of over $1M going to the President & CEO of the organization in 2012 alone.  Thus there does seem to be more than a little justification for the first of the author’s criticisms.

I also share in the author’s other concerns, but a complete analysis is not available regarding either the true value of the PMBOK® and the value of a PMP certification.  I have met many colleagues who felt the need to obtain the latter, despite their significant practical achievements and academic credentials.  I have also met quite a few people with “PMP” after their names whose expertise is questionable, at best.  I am reminded of the certifications given by PMI and other PM organizations today to a very similar condition several years ago when the gold standard of credentials in certain parts of the IT profession were the Certified Novell Engineer (CNE), and Microsoft Certified Solutions Expert (MCSE) certifications.  They still exist in some form.  What was apparent as I took the courses and the examinations was that the majority of my fellow students had never set up a network.  They were, to use the pejorative among the more experienced members among us, “Paper CNEs and MCSEs.”  In interviewing personnel with “PMP” after their name I find a wide variation in expertise, thus the quality of experience with supporting education tends to have more influence with me than some credential from one of the PM organizations.

Related to this larger issue of what constitutes a proper credential in our discipline, I came across an announcement by Dave Gordon at his The Practicing IT Project Manager blog of a Project Management Job Requirements study.  Dave references this study by Noel Radley of SoftwareAdvise.com that states that the PMP is preferred or specified by 79% of the 300 jobs used as the representative baseline for the industries studied.  Interestingly, the study showed that advanced education is rarely required or preferred.

I suspect that this correlates in a negative way with many of the results that we have seen in the project management community.  Basic economics dictates that people with advanced degrees (M.A. and M.B.A. grads) do come with a higher price than those who only have Baccalaureate degrees, their incomes rising much more than 4 year college grads.  It seems that businesses do not value that additional investment except by exception.

Additionally, I have seen the results of two studies presented in government forums over the past six months (but alas no links yet) where the biggest risk to the project was identified to be the project manager.  Combined with the consistent failure reported by widely disparate sources of the overwhelming majority of projects to perform within budget and be delivered on time raises the natural question as to whether those that we choose to be project managers have the essential background to perform the job.

There seems to be a widely held myth that formal education is somehow unnecessary to develop a project manager–relegating what at least masquerades as a “profession”–to the level of a technician or mechanic.  It is not that we do not need technicians or mechanics, it is that higher level skills are needed to be a successful project manager.

This myth seems to be spreading, and to have originated from the society as a whole, where the emphasis is on basic skills, constant testing, the elimination of higher level thinking, and a narrowing of the curriculum.  Furthermore, college education, which was widely available to post-World War II generations well into the 1980s, is quickly becoming unaffordable by a larger segment of the population.  Thus, what we are seeing is a significant skills gap in the project management discipline to add to one that already has had an adverse impact on the ability of both government and industry to succeed.  For example, a paper from Calleam Consulting Ltd in a paper entitled “The Story Behind the High Failure Rates in the IT Sector” found that “17 percent of large IT projects go so badly that they can threaten the very existence of the company.”

From my experiences over the last 30+ years, when looking for a good CTO or CIO I will look to practical and technical experience and expertise with the ability to work with a team.  For an outstanding coder I look for a commitment to achieve results and elegance in the final product.  But for a good PM give me someone with a good liberal arts education with some graduate level business or systems work combined with leadership.  Leadership includes all of the positive traits one demands of this ability: honesty, integrity, ethical behavior, effective personnel management, commitment, and vision.

The wave of the future in developing our expertise in project management will be the ability to look at all of the performance characteristics of the project and its place in the organization.  This is what I see as the real meaning of “Integrated Project Management.”  I have attended several events since the beginning of the year focused on the project management discipline in which assertions were made that “EVM is the basis for integrated project management” or “risk is the basis for integrated project management” or “schedule is the basis for integrated project management.”  The speakers did not seem to acknowledge that the specialty that they were addressing is but one aspect of measuring project performance, and even less of a factor in measuring program performance.

I believe that this is a symptom of excess specialization and lack of a truly professional standard in project management.  I believe that if we continue to hire technicians with expertise in one area, possessing a general certification that simply requires one to attend conferences and sit in courses that lack educational accreditation and claim credit for “working within” a project, we will find that making the transition to the next evolutionary step at the PM level will be increasingly difficult.  Finally, for the anonymous author critical of PMI it seems that project management is a good business for those who make up credentials but not such a good deal for those with a financial stake in project management.

Note:  This post has been modified to correct minor grammatical and spelling errors.

Full disclosure:  The author has been a member of PMI for almost 20 years, and is a current member and former board member of the College of Performance Management (CPM).

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 healthcare.gov 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.

 

 

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.

That Guvmint Stuff

Attended a meeting this week in which the discussion surrounded whether EVM is a financial reporting requirement or a project management tool.

Cited was a 2009 report to Congress that indicated that program managers were still viewing EVM as external to their operations–that it is a reporting requirement. Five years have passed since then but there is more than a little confirmation of the currency of this observation around us: the lack of PM participation at professional meetings and conferences, the chestnut complaint that EVM and other indicators are “looking in the rear view mirror” despite significant methodological and technological advances, and the inability to anticipate and handle manifested risk despite the fact that EVM and other metrics provided early warning of those risks.

It is not as if EVM is totally being ignored. Industry increasingly uses EVM as one of many of its tools to determine progress In order to course correct. Long gone are the days when mention of EVM would elicit the response that they don’t do “that Guvmint stuff.”

Also, the aforementioned report to Congress is part of a statutory requirement, so it’s not as if we are dealing with an esoteric methodology of little importance or visibility. So what gives?

My opinion is that the problem is twofold. First, the Congressional reporting requirement causes PMs to treat the data as something to be overcome, knowing that politics is involved. This is a case where the underlying culture closed ranks rather than embrace the change. Second, PMs are rewarded by senior management on entirely unrelated criteria.

Keep in mind that when I talk project management that we aren’t talking about schedules with 50 activities and a couple hundred work packages. These folks are into double caps PM: tens of thousands of schedule activities, hundreds of WBS assignments at the cost control level, complex calculations of indirect and direct costs against resource assignments, technical performance measures against a baseline over multiple years, all under an intense oversight environment. That elephant cannot be eaten all at once, it has to be consumed one piece at a time and it takes a strong partnership between the government PMO organization and the private industrial base.

Even something that appears to be failure can, in fact, turn out to be success. Exhibit 1 in this case goes to the performance of the M1A1 Abrams tank. For years this project was held up by anti-“Guvmint” and anti-DoD types as an example of government waste.  This seemed borne out by DoD’s own analysis by the Project on Government Oversight entitled “The Army’s M1 Tank:  Has It Lived Up To Expectations?”  (Sorry–the report is removed thus no link).  Turns out that just a year later in Desert Shield/Desert Storm spending that extra money (and perhaps the extra scrutiny) was decisive in making the ground war a turkey shoot, with the Russian T72 outgunned and with inferior range, among other issues.

m1a1 tank

Having been an operational U.S. Navy military professional I understand the culture that views methods such as EVM as unnecessary intrusions into the job of delivering the maximum “bang for the buck” to the Fleet. After all, lives are in the balance.

But I believe there is an equally, if not more, important overarching consideration that must be kept in mind by the career military officer and senior civilian. It is the principle of the public interest. If we committed all of the funds to meet any possible threat we would have no funds for anything else. This is the danger to which, I think, that Eisenhower was referring when he invoked his famous phrase. It is assuming that one consideration trumps all others, akin to the after action reports that I would read in which an aviator became so concerned with one problem that he or she didn’t notice that the aircraft was falling out of the sky.

EVM and other analytical methods do have their origins in oversight, and no doubt there is still some hangover that influences perceptions from that history, though it hasn’t been the case for almost 20 years. But, I would argue, invoking this history doesn’t pass the “so-what?” test. After all, it is the public’s money and accountability is part of being a PM. Such standards are much higher in military officers.

Study after study (published but not on-line alas) have shown that the largest risk factor in project management is the PM. In the end it comes down to leadership, but leadership of a different kind.

I believe that educating and grading PMs on their ability to effectively use the tools given them–similar to the way they are assessed in flying the aircraft, leading their units, or fighting the ship–is the only way to gain their attention and, in the process, elicit full value from the tremendous talents and essential perspectives and experience that they bring to the table.

Fight the Project if we must characterize it that way. The enemy is entropy, which cannot be defeated, which never sleeps, and cannot be effectively overcome without the right tools and techniques effectively applied.

Obviously much education still needs to be done.