project planning | Life, Project Management, and Everything

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.

Ground Control from Major Tom — Breaking Radio Silence: New Perspectives on Project Management

Since I began this blog I have used it as a means of testing out and sharing ideas about project management, information systems, as well to cover occasional thoughts about music, the arts, and the meaning of wisdom.

My latest hiatus from writing was due to the fact that I was otherwise engaged in a different sort of writing–tech writing–and in exploring some mathematical explorations related to my chosen vocation, aside from running a business and–you know–living life. There are only so many hours in the day. Furthermore, when one writes over time about any one topic it seems that one tends to repeat oneself. I needed to break that cycle so that I could concentrate on bringing something new to the table. After all, it is not as if this blog attracts a massive audience–and purposely so. The topics on which I write are highly specialized and the members of the community that tend to follow this blog and send comments tend to be specialized as well. I air out thoughts here that are sometimes only vaguely conceived so that they can be further refined.

Now that that is out of the way, radio silence is ending until, well, the next contemplation or massive workload that turns into radio silence.

Over the past couple of months I’ve done quite a bit of traveling, and so have some new perspectives that and trends that I noted and would like to share, and which will be the basis (in all likelihood) of future, more in depth posts. But here is a list that I have compiled:

a. The time of niche analytical “tools” as acceptable solutions among forward-leaning businesses and enterprises is quickly drawing to a close. Instead, more comprehensive solutions that integrate data across domains are taking the market and disrupting even large players that have not adapted to this new reality. The economics are too strong to stay with the status quo. In the past the barrier to integration of more diverse and larger sets of data was the high cost of traditional BI with its armies of data engineers and analysts providing marginal value that did not always square with the cost. Now virtually any data can be accessed and visualized. The best solutions, providing pre-built domain knowledge for targeted verticals, are the best and will lead and win the day.

b. Along these same lines, apps and services designed around the bureaucratic end-of-month chart submission process are running into the new paradigm among project management leaders that this cycle is inadequate, inefficient, and ineffective. The incentives are changing to reward actual project management in lieu of project administration. The core fallacy of apps that provide standard charts based solely on user’s perceptions of looking at data is that they assume that the PM domain knows what it needs to see. The new paradigm is instead to provide a range of options based on the knowledge that can be derived from data. Thus, while the options in the new solutions provide the standard charts and reports that have always informed management, KDD (knowledge discovery in database) principles are opening up new perspectives in understanding project dynamics and behavior.

c. Earned value is *not* the nexus of Integrated Project Management (IPM). I’m sure many of my colleagues in the community will find this statement to be provocative, only because it is what they are thinking but have been hesitant to voice. A big part of their hesitation is that the methodology is always under attack by those who wish to avoid accountability for program performance. Thus, let me make a point about Earned Value Management (EVM) for clarity–it is an essential methodology in assessing project performance and the probability of meeting the constraints of the project budget. It also contributes data essential to project predictive analytics. What the data shows from a series of DoD studies (currently sadly unpublished), however, is that it is planning (via a Integrated Master Plan) and scheduling (via an Integrated Master Schedule) that first ties together the essential elements of the project, and will record the baking in of risk within the project. Risk manifested in poorly tying contract requirements, technical performance measures, and milestones to the plan, and then manifested in poor execution will first be recorded in schedule (time-based) performance. This is especially true for firms that apply resource-loading in their schedules. By the time this risk translates and is recorded in EVM metrics, the project management team is performing risk handling and mitigation to blunt the impact on the performance management baseline (the money). So this still raises the question: what is IPM? I have a few ideas and will share those in other posts.

d. Along these lines, there is a need for a Schedule (IMS) Gold Card that provides the essential basis of measurement of programmatic risk during project execution. I am currently constructing one with collaboration and will put out a few ideas.

e. Finally, there is still room for a lot of improvement in project management. For all of the gurus, methodologies, consultants, body shops, and tools that are out there, according to PMI, more than a third of projects fail to meet project goals, almost half to meet budget expectations, less than half finished on time, and almost half experienced scope creep, which, I suspect, probably caused “failure” to be redefined and under-reported in their figures. The assessment for IT projects is also consistent with this report, with CIO.com reporting that more than half of IT projects fail in terms of meeting performance, cost, and schedule goals. From my own experience and those of my colleagues, the need to solve the standard 20-30% slippage in schedule and similar overrun in costs is an old refrain. So too is the frustration that it need take 23 years to deploy a new aircraft. A .5 CPI and SPI (to use EVM terminology) is not an indicator of success. What this indicates, instead, is that there need to be some adjustments and improvements in how we do business. The first would be to adjust incentives to encourage and reward the identification of risk in project performance. The second is to deploy solutions that effectively access and provide information to the project team that enable them to address risk. As with all of the points noted in this post, I have some other ideas in this area that I will share in future posts.

Onward and upward.

Technical Ecstacy — Technical Performance and Earned Value

As many of my colleagues in project management know, I wrote a series of articles on the application of technical performance risk in project management back in 1997, one of which made me an award recipient from the institution now known as Defense Acquisition University. Over the years various researchers and project organizations have asked me if I have any additional thoughts on the subject and the response up until now has been: no. From a practical standpoint, other responsibilities took me away from the domain of determining the best way of recording technical achievement in complex projects. Furthermore, I felt that the field was not ripe for further development until there were mathematics and statistical methods that could better approach the behavior of complex adaptive systems.

But now, after almost 20 years, there is an issue that has been nagging at me since publication of the results of the project studies that I led from 1995 through 1997. It is this: the complaint by project managers in resisting the application of measuring technical achievement of any kind, and integrating it with cost performance, the best that anyone can do is 100%. “All TPM can do is make my performance look worse”, was the complaint. One would think this observation would not only not face opposition, especially from such an engineering dependent industry, but also because, at least in this universe, the best you can do is 100%.* But, of course, we weren’t talking about the same thing and I have heard this refrain again at recent conferences and meetings.

To be honest, in our recommended solution in 1997, we did not take things as far as we could have. It was always intended to be the first but not the last word regarding this issue. And there have been some interesting things published about this issue recently, which I noted in this post.

In the discipline of project management in general, and among earned value practitioners in particular, the performance being measured oftentimes exceeds 100%. But there is the difference. What is being measured as exceeding 100% is progress against both a time-based and fiscally-based linear plan. Most of the physical world doesn’t act nor can it be measured this way. When measuring the attributes of a system or component against a set of physical or performance thresholds, linearity against a human-imposed plan oftentimes goes out the window.

But a linear progression can be imposed on the development toward the technical specification. So then the next question is how do we measure progress during the development curve and duration.

The short answer, without repeating a summarization of the research (which is linked above) is through risk assessment, and the method that we used back in 1997 was a distribution curve that determined the probability of reaching the next step in the technical development. This was based on well-proven systems engineering techniques that had been used in industry for many years, particularly at pre-Lockheed Martin Martin Marietta. Technical risk assessment, even using simplistic 0-50-80-100 curves, provides a good approximation of probability and risk between each increment of development, though now there are more robust models. For example, the use of Bayesian methodology, which introduces mathematical rigor into statistics, as outlined in this post by Eliezer Yudkowsky. (As an aside, I strongly recommend his blogs for anyone interested in the cutting edge of rational inquiry and AI).

So technical measurement is pretty well proven. But the issue that then presents itself (and presented itself in 1997) was how to derive value from technical performance. Value is a horse of a different color. The two bugaboos that were presented as being impassible roadblocks were weight and test failure.

Let’s take weight first. On one of my recent trips I found myself seated in an Embraer E-jet. These are fairly small aircraft, especially compared to conventional commercial aircraft, and are lightweight. As such, they rely on a proper distribution and balance of weight, especially if one finds oneself at 5,000 feet above sea level with the long runway shut down, a 10-20 mph crosswind, and a mountain range rising above the valley floor in the direction of takeoff. So the flight crew, when the cockpit noted a weight disparity, shifted baggage from belly stowage to the overhead compartments in the main cabin. What was apparent is that weight is not an ad hoc measurement. The aircraft’s weight distribution and tolerances are documented–and can be monitored as part of operations.

When engineering an aircraft, each component is assigned its weight. Needless to say, weight is then allocated and measured as part of the development of subsystems of the aircraft. One would not measure the overall weight of the aircraft or end item without ensuring that the components and subsystems did not conform to the weight limitations. The overall weight limitation of an aircraft will very depending on mission and use. If a commercial-type passenger airplane built to takeoff and land from modern runways, weight limitations are not as rigorous. If the aircraft in question is going to takeoff and land from a carrier deck at sea then weight limitations become more critical. (Side note: I also learned these principles in detail while serving on active duty at NAS Norfolk and working with the Navy Air Depot there). Aside from aircraft weight is important in a host of other items–from laptops to ships. In the latter case, of which I am also intimately familiar, weight is important in balancing the ship and its ability to make way in the water (and perform its other missions).

So given that weight is an allocated element of performance within subsystem or component development, we achieve several useful bits of information. First off, we can aggregate and measure weight of the entire end item to track if we are meeting the limitations of the item. Secondly, we can perform trade-off. If a subsystem or component can be made with a lighter material or more efficiently weight-wise, then we have more leeway (maybe) somewhere else. Conversely, if we need weight for balance and the component or subsystem is too light, we need to figure out how to add weight or ballast. So measuring and recording weight is not a problem. Finally, we allocate and tie performance-wise a key technical specification to the work, avoiding subjectivity.

So how to do we show value? We do so by applying the same principles as any other method of earned value. Each item of work is covered by a Work Breakdown Structure (WBS), which is tied (hopefully) to an Integrated Master Schedule (IMS). A Performance Management Baseline (PMB) is applied to the WBS (or sometimes thought a resource-loaded IMS). If we have properly constructed our Integrated Management Plan (IMP) prior to the IMS, we should clearly have tied the relationship of technical measures to the structure. I acknowledge that not every program performs an IMP, but stating so is really an acknowledgement of a clear deficiency in our systems, especially involving complex R&D programs. Since our work is measured in short increments against a PMB, we can claim 100% of a technical specification but be ahead of plan for the WBS elements involved.

It’s not as if the engineers in our industrial activities and aerospace companies have never designed a jet aircraft or some other item before. Quite a bit of expertise and engineering know-how transfers from one program to the next. There is a learning curve. The more information we collect in that regard, the more effective that curve. Hence my emphasis in recent posts on data.

For testing, the approach is the same. A test can fail, that is, a rocket can explode on the pad or suffer some other mishap, but the components involved will succeed or fail based on the after-action report. At that point we will know, through allocation of the test results, where we are in terms of technical performance. While rocket science is involved in the item’s development, recording technical achievement is not rocket science.

Thus, while our measures of effectiveness, measures of performance, measures of progress, and technical performance will determine our actual achievement against a standard, our fiscal assessment of value against the PMB can still reflect whether we are ahead of schedule and below budget. What it takes is an understanding of how to allocate more rigorous measures to the WBS that are directly tied to the technical specifications. To do otherwise is to build a camel when a horse was expected or–as has been recorded in real life in previous programs–to build a satellite that cannot communicate, a Navy aircraft that cannot land on a carrier deck, a ship that cannot fight, and a vaccine that cannot be delivered and administered in the method required. We learn from our failures, and that is the value of failure.

*There are colloquial expressions that allow for 100% to be exceeded, such as exceeding 100% of the tolerance of a manufactured item or system, which essentially means to exceed its limits and, therefore, breaking it.

Ch-ch Changes — Software Implementations and Organizational Process Improvement

Dave Gordon at The Practicing IT Project Manager lists a number of factors that define IT project success. Among these is “Organizational change management efforts were sufficient to meet adoption goals.” This is an issue that I am grappling with now on many fronts.

The initial question that comes to mind is which comes first–the need for organizational improvement or the transformation that comes results as a result of the introduction of new technology? “Why does this matter?” one may ask. The answer is that it defines how things are perceived by those that are being affected (or victimized) by the new technology. This will then translate into various behaviors. (Note that I did not say that “Perception is reality.” For the reason why please consult the Devil’s Phraseology.)

This is important because the groundwork laid (or not laid) for the change that is to come will then translate into sub-factors (accepting Dave’s taxonomy of factors for success) that will have a large impact on the project, and whether it is defined as a success. In getting something done the most overriding priority is not just “Gettin’ ‘Er Done.” The manner in which our projects, particularly in IT, are executed and the technology introduced and implemented will determine the success of a number of major factors that contribute to overall project success.

Much has been written lately about “disruptive” change, and that can be a useful analogy when applied to new technologies that transform a market by providing something that is cheaper, better, and faster (with more functionality) than the market norm. I am driving that type of change in my own target markets. But that is in a competitive environment. Judgement–and good judgement–requires that we not inflict this cultural approach on the customer.

The key, I think, is bringing back a concept and approach that seems to have been lost in the shuffle: systems analysis and engineering that works hand-in-hand with the deployment of the technological improvement. There was a reason for asking for the technology in the first place, whether it be improved communications, improved productivity, or qualitative factors. Going in willy-nilly with a new technology that provides unexpected benefits–even if those benefits are both useful and will improve the work process–can often be greeted with fear, sabotage, and obstruction.

When those of us who work with digital systems encounter someone challenged by the new introduction of technology or fear that “robots are taking our jobs,” our reaction is often an eye-roll, treating these individuals as modern Luddites. But that is a dangerous stereotype. Our industry is rife with stories of individuals who fall into this category. Many of them are our most experienced middle managers and specialists who predate the technology being introduced. How long does it take to develop the expertise to fill these positions? What is the cost to the organization if their corporate knowledge and expertise is lost? Given that they have probably experienced multiple reorganizations and technology improvements, their skepticism is probably warranted.

I am not speaking of the exception–the individual who would be opposed to any change. Dave gives a head nod to the CHAOS report, but we also know that we come upon these reactions often enough to be documented from a variety of sources. So how to we handle these?

There are two approaches. One is to rely upon the resources and management of the acquiring organization to properly prepare the organization for the change to come, and to handle the job of determining the expected end state of the processes, and the personnel implications that are anticipated. Another is for the technology provider to offer this service.

From my own direct experience, what I see is a lack of systems analysis expertise that is designed to work hand-in-hand with the technology being introduced. For example, systems analysis is a skill that is all but gone in government agencies and large companies, which rely more and more on outsourcing for IT support. Oftentimes the IT services consultant has its own agenda, which oftentimes conflicts with the goals of both the manager acquiring the technology and the technology provider. Few outsourced IT services contracts anticipate that the consultant must act as an enthusiastic–as opposed to tepid (at best) willing–partner in these efforts. Some agencies lately have tasked the outsourced IT consultant to act as honest broker to choose the technology, mindless of the strategic partnering and informal relationships that will result in a conflict of interest.

Thus, technology providers must be mindful of their target markets and design solutions to meet the typical process improvement requirements of the industry. In order to do this the individuals involved must have a unique set of skills that combines a knowledge of the goals of the market actors, their processes, and how the technology will improve those processes. Given this expertise, technology providers must then prepare the organizational environment to set expectations and to advance the vision of the end state–and to ensure that the customer accepts that end state. It is then up to the customer’s management, once the terms of expectations and end-state have been agreed, to effectively communicate them to those personnel affected, and to do so in a way to eliminate fear and to generate enthusiasm that will ensure that the change is embraced and not resisted.

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.

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.

Standing in the Shadow of (Deming) — How does Agile Stack Up? — Part One

I’ve read a few posts across the web over time in which Agile Cult proponents have tried to tie the Agile Manifesto as being on a continuum from Deming. Given the #NoEstimates drive you would expect someone to cherry pick a portion of item 3 of his Fourteen Points of Management, that is, “Cease dependence on inspection to achieve quality,” omitting the remainder of the point: “Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” There are even a few that have attempted to appropriate Deming’s work by redefining the meaning of his systems approach and philosophy. (A classic symptom of ideologues and cults, but more on that in a later post).

W. Edwards Deming was from all accounts a brilliant statistician. In 1927 he met physicist and statistician Walter A. Shewhart of Bell Telephone Laboratories who is generally accepted as the originator of statistical quality control. Shewhart’s work focused on processes and the related technical tool of the control chart. One of his most important observations was his data presentation rules, which are:

1. Data have no meaning apart from their context and,

2. Data contain both signal and noise. To be able to extract information, one must separate the signal from the noise within the data.

These concepts are extremely important in avoiding the fallacy of reification, in which to regard something abstract as a material or concrete thing. This is a concept that I have come back to at various times in this blog, particularly as it relates to statistical performance measures such as EVM and risk measurement. Shewhart’s work no doubt was influenced by the work of astronomer, statistician, mathematician, and philosopher Charles Sanders Peirce in this regard.

Another important feature of Shewharts approach was the development of the Shewhart or Deming (Plan-Do-Study-Act) cycle. This is:

Plan: identify what can be improved and what change is needed
Do: implement the design change
Study: measure and analyze the process or outcome
Act: if the results are not as hoped for

Deming’s insight and contribution came when he realized that Shewhart’s methods not only applied to equipment performance but also to both manufacturing and management practices. He further refined his methods by applying and training U.S. war industry personnel in Statistical Process Control (SPC) during the Second World War. After the war he served under General MacArthur during the U.S. occupation and rebuilding of Japan as a census consultant to the Japanese government. He then made his mark in assisting Japanese industry in applying his statistical and management methods to their rebuilding efforts.

To illustrate how different Deming was from Agile and #NoEstimates, it is useful to understand that the purpose of his methods, rooted in empirical methods (the accepted definition and not the appropriated ideological Agile definition), were focused on improving quality and reducing costs. The formula for this approach is summed up as follows:

Quality = Results of Work Efforts/Total Costs

We have seen the validation of this formula with each generation of technological development, particularly in software and hardware development. But in order to gauge success in order to insert quality into the process we must estimate, measure, inspect, and validate. These are elements of the feedback loop that are essential in establishing a quality improvement process.

As Dave Gordon at the Practicing IT Project Manager blog stated in his post entitled Received Knowledge, Fanaticism, and Software Consultants, in the end, for all of the attempts at special pleading and to misdirect the assessment of risk in the system through Agile methods, it still all comes down to coding–and coding quality can be measured. “But this doesn’t drive out fear!” can be heard in the reply by mediocre Agile coders, cherry picking Deming. No, not if you’re not creating quality code in this particular example. Human Resources Management (HRM) for good and bad is a leadership and management responsibility, and nowhere in a full reading of Deming does he eliminate these decisions given the denominator of cost in the equation of quality.

This is one aspect of IT coding that is slightly different from our other systems: software design and coding is as much as an art as a skill. This is what we mean by elegance when we see well written code–it coheres as a simple systemic solution to the problem at hand that maximizes performance by leveraging the internal logic of the language being used and, as such, avoids defects not only in its current version but also is written in such a way that its internal logic, simplicity, and cohesion will allow for incremental improvement, and the avoidance and elimination of defects in future builds.

My first real life experience with this concept came during my first assignment as a project manager when I was a young Navy Lieutenant in San Diego. I had just learned how to code software and had performed at the top of my class in pursuing a degree in software engineering. This apparently qualified me in the eyes of my superiors to take over a failing program (read to mean: above cost and behind schedule) tasked with building a standard procurement system for the Navy (later the joint procurement system). In reviewing the reasons for failure it became apparent that the army of systems analysts, technical consultants, and software developers were pulling the effort into conflicting directions. My first act was to narrow the field to one lead developer and one very good coder, letting the rest to find other employment. I then pared from there in building a cohesive team (within the realistic span of control) focused on quality and project success after we had defined what success would look like. And, yes, we used estimates. We recovered the program in six months until it was transferred to D.C. and placed under a more senior officer–the occasional price of success.

Neither Deming’s propositions nor Agile software development methodology are received knowledge or wisdom (see my last post on Carl Sagan), though the latter makes special pleading along those lines. Both are open to questioning, validation, and testing. This principle is implicit in Deming’s own System of Profound Knowledge regarding what he described as the Theory of Knowledge–an approach resting firmly within the principles of the scientific method. Manifestos are beliefs, opinions, and assertions absent proof and, as such, many of the propositions of Agile are worlds away from Deming.

Note: Minor edits made to correct grammatical errors in the original.

Livin’ on a Prayer — The Importance of Plan B

Glen Alleman over at Herding Cats has a great presentation up on the importance of risk handling by having a Plan B based on the Shackleton Expedition. This is an important point and one that goes against the oft-heard assertion, particularly in software development, that we are “exploring,” that our systems are evolutionary, that we are delivering value one increment at a time.

Murphy’s Law of combat operations states that “No OPLAN ever survives initial contact.” This experience is in line with Eisenhower’s comment that “When preparing for battle, I have always found that plans are useless but planning is indispensable.” What these observations mean is that we know that once tested by reality–the reality of combat in the case of the examples given–that almost nothing will go according to plan.

As part of operational planning, the staff identifies risks, alternatives, and contingencies. Everyone in the planning process is made familiar with these alternatives–Plan B, Plan C, etc. We may “think” that the plan we have chosen is the best one, based as it is on certain assumptions and the 80% solution. But when in the midst of an operation no one can anticipate everything. Knowing, however, that during the planning process that what one is seeing before them is very much in line with one of the alternative scenarios allows us to initiate the alternative plan. Rather than having to throw everything out, including the progress that has been made, or having to improvise from zero, we have a basis to make well-informed decisions based on the alternatives. To do otherwise is folly and may lead to defeat in the case of military operations. For more workaday situations, like project management, to do otherwise is folly and may lead to project failure.

This is why our community should be following the ACA roll-out, regardless of the surrounding politics, as I stated in a previous blog. The ACA program is a fascinating real-life and highly visible experiment in program and project management. Much of the publicity in the press focused on the federal government’s website roll-out. But that fails to distinguish two important concepts: that a program is not the same as a project, and that the website was not the entire project for the initial enrollment period for the ACA. It is, to quote Macbeth, “…a tale told by an idiot, full of sound and fury, signifying nothing.”

The reason for my unsympathetic assessment of the critics of the roll-out is because they are using the wrong measures of success, which was the number of people ultimately enrolled. (Now projected to be about 7.8 million for the website alone, and for between 14 to 20 million overall). There was a plan B and a plan C. The facilitators turned out to be very important in the early stages and represented an effective Plan B. Adjustments in the enrollment period also allowed for some flexibility, giving the digital systems time to recover, and provided a Plan C.

There will be more detailed postmortems as the players begin to publish once the dust has settled. Early controversy within the IT community has focused on whether the failure rested with Agile or Waterfall. I think this is a false debate since no software methodology can credibly claim to inherently handles risk or rises to the level of a project management method. I think the real issue of interest to IT professionals will focus on the areas of testing and recovery: the first because early reports were that testing was insufficient and the latter because the recovery was remarkably fast, which undermines the credibility of the critics of testing.