Changing the Congressional Budget Office to the Congressional Enterprise Architecture Office

The Current Mission of the CBO
Currently, the mission of the Congressional Budget Office (CBO):

"is to provide Congress with objective, timely, nonpartisan analyses needed for economic and budget decisions and the information and estimates required for the Congressional budget process" [from CBO TESTIMONY Statement of Robert D. Reischauer Director Congressional Budget Office before the Joint Committee on the Organization of Congress,[the] Congress of the United States]

The director broke that into three operating strategies:

1. Helping the Congress formulate a budget plan;

2. Helping the Congress stay within that plan; and,

3. Helping the Congress consider policy issues related to the budget and the economy.

The Problem with the Current Mission

This Mission and Strategies is part of the economic, political, and social problems currently facing the United States, and, potentially, a source for the solution of those problems. The reason that the CBO is part of the problem is that finance engineering has influenced Congress to emphasize the "financial" part of an overall Enterprise Architecture. That is, Congress proposes functional and component changes to the US Federal Government and the CBO responds with an analysis, which Congress can choose to spin-doctor to its political purposes. Consequently, Congress can choose to support any industry; examples include agriculture (subsidies) and housing (mortgage deductions, etc.), gambling (gambling deductions), and so on.

A Solution the Congressional Enterprise Architecture Office

As I demonstrate in my book, Organizational Economics: The Formation of Wealth, the body performing the controlling (see IDEF0 post) and governing functions of any organization has three Missions, Security, Standards, and Infrastructure.  This is particularly true of any organization that has a spatial domain.  These missions appear in the Preamble of the US Constitution and throughout that document.

Given these three high-level missions, and my discussion of the role and responsibilities of the Enterprise Architect (as a sub-discipline of Systems Engineering), what the US Federal Government needs is a real implementation of the FEA Framework and a formal Enterprise Architecture process.  This process aligns the departments’, agencies’, and other organizations’ of the Federal Government with the three high-level missions of government. 

Additionally, Enterprise Architecture proposes where develop, transform, reform, end or otherwise change the organizations’ missions, strategies, processes, and tooling.  For the US Federal Government, (or any other organization of this scope and size), the EA process must be recursive, but traceable and integratable.  The CBO is in the position with some of the responsibilities for doing this. 

Why not have Congress empower them as the Congressional Enterprise Architecture Offiice?

Housing, Finance, and Government: Three "industries" that produce Minimal Value

The thesis of this post is that it is pretty silly to base an economy, like that of the United States, on housing, finance, and government, which is what Wall St. and Pennsylvania Ave. seem to want to do.

Types of Industries

All organizations are constructed from three types of sub-organizations, which are within their domain.  The Domains would normally be considered as political unit as per example, a city, county, state, or country.  However, even in private organizations, these types of organizations exist, within the organization’s functions and departments.  These organizational categories[i] are:

·         Primary Industry – Organizations that are in an industry that creates a product or service that is exported beyond the boundaries of the domain within which it is produced. 

·         Secondary Industry – Organizations that are in an industry that enables and supports one or more of the processes of the primary industry within the domain it operates.

·         Tertiary Industry – Organizations that in an industry that enable and supports both the primary and secondary industries by providing services that support the environment in the domain within which the primary and secondary industries operate.

As I demonstrate in my book, Organizational Economics: The Formation of Wealth, the primary industry (or industries) is the economic engine that forms the value of the organization for other organizations. Hamel and Prahalad called the turbine of this engine, the organization’s core competence.[ii] It produces the value for the organization.  All other “industries” enable and support this engine.  For example, the economic engine and primary industry for Detroit Michigan, has been and continues to be the automotive industry; in “silicon valley” it’s information technology, the State of Iowa is agriculture, and so on.

Secondary industries are sub-contractors and suppliers of hardware, software, and services to the primary industries.  These industries would include auto parts suppliers, tool manufacturers, transportation within the organizational domain, and other organizations directly supporting the primary industry or industries.

Tertiary industries are organizations that enable and support the personnel, or the domain’s infrastructure.  Schools, colleges, and universities, banks and other financial services, municipal services (e.g., electric, communications, roads and bridges, sewer, water, and so on), food stores, and other stores, hospitals and other medical services, restaurants, fast food outlets, and so on.  In other words, the majority of economic activities within an organizational domain.  Additionally, tertiary industries includes all types of construction.  It also includes the defense (see   Security a Mission of Government).  These industries are where most of the economic activity of an organization occurs.

Some organizational theoreticians include quaternary industries as a category.  These activities include standards and policies (see Standards a Mission of Government) and infrastructure (see Infrastructure a Mission of Government and Organizational Control).

Types of Value

In the first chapter of Organizational Economics, I describe three types values, knowledge value, capacity value, and political value. 

Knowledge value (see Knowledge Value) is value created by an increasing knowledge-base and includes research and development (invention and innovation), and knowledge transfer (education). Products based on new scientific discoveries and transferred into production are the most high valued.  Unique user interface designs like the iPhone or innovative medicines are examples of knowledge value. 

Capacity value (see Capacity Value) is “more of the same” value.  Once a product has been perfected and competitors have brought out versions, then what Adam Smith called “the invisible hand” starts to force reduction in cost of the product.  Many economists refer to the as commoditization of a product, but its value is in capacity production—which produces capacity value.

Political value (see Political Value) is of two types, mediating and exploitive.

·         Mediating (or mediated) political value is created by reducing the organization’s internal process friction.  Examples of mediating political value include contracts, laws, customs, codes, standards, policies, and so on.  In the military, mediating political value (reduction in process friction) comes from “the rules of engagement” (e.g., don’t shoot your fellow military).  The reduction in process friction is very often the difference between a process adding value and a process absorbing value.  The regulation of markets (and the processes of markets, themselves) is such an example.

·         Exploitive political value is indirect or “siphoned” value.  It is caused by someone in the position of responsibility or authority using the position for the reaping of value to their own benefit; “The Lord of the Manor” is the archetypal example, those these include dictators, lobbyists, bankers, day traders, and many judges and legislators.  Further, as I describe in my book, in many cases it includes various religious authorities.

Housing, Finance, and Government as Value creators

My thesis is  that housing, finance, and government either do not create value or very little value.  I base this on the understanding on how these fit within the dimensions described in the previous sections.

Housing

A house is worth a house.  While that seems to be a tautology (and it is), too many people forgot that during “the housing bubble”.  What that saying means is that the value of the house is only what value it imparts to the consumer of the house’s value.  The house is never worth more than when it was built, unless it is maintained and upgraded.  And even when it is upgraded the value of house begins to decrease as it is used (what’s being used, at the most abstract is its value).  The problem, recently, has been that governments tend to inflate their money supply—money being a reserve of value.  With the inflation of money (that is, the decrease in the value of money) the price of a house to increases—though its value remains the same; it’s worth one house.  Likewise, when the housing market “goes down”, the price of the house goes down, but the value remains the same; one house.

House construction and remodeling is a tertiary economic activity.  It produces some capacity value (more of the same value) for the builder and construction workers, but once completed and purchased, it starts loosing value.  In giving the people of the organization a place to live, a house supports the secondary and primary industries of the organization.

Obviously, this is not an activity that enables and supports the formation of wealth for an organization.  Consequently, basing an economy on housing, or at least a significant portion of an economy is foolish and silly.  Yet, in the period from 1995 to 2007, that is what many Americans built the perceived wealth on, and what the United States did.

Finance

Finance includes two subtypes; banks and markets.  The Wall Streeters, (e.g., bankers, hedge fund managers, stockbrokers, pension fund managers and so on) have forgotten that a bank is a value battery and “a market” is the transfer point for the value.

Banks dilute stored value of money through investments that increases risk and potentially increases the amount value through the implementation of discoveries and inventions as new products, systems, or services.  In and of itself, investing cannot increase the amount of value only reduces it.  Only when the money is invested in innovative ideas or the production capability (seeROI Vs VOI) does the value increase, so that, for example, loaning money for a house does not increase the value of the house or create value of any sort.   However, if a bank loans money to a farmer to buy seed or farming implements, the bank has made an investment that does create capacity value—food.  Consequently, banks are tertiary activities that do not produce an increase value, but they loan their repository of potential value (Money) to primary and secondary activities that do.

In the process of each transaction, the bankers siphon off some of the value as a “transaction” fee.  This siphoning is converting potential value into exploitive political value; and exploitive political value is value that is quickly destroyed.

Markets have two missions.  The first is to measure the value of a material, product, or organization. The second is to transform value from real to potential and back; that is trade materials or stocks for money (potential value) or money for materials and stocks.  “Making a market” does both of these; and in this Internet age, anyone can do this.  That is, the person can buy commodities, hold them, and sell them.  In the process, the price of the commodity (be it materials, products, or stocks) converges on a price.

Again, market are tertiary activities that can convert knowledge and capacity value into potential value and the reverse.  And, again, the “market makers” and “stock brokers” that siphon a percentage off, because they are “providing a service” (which to some degree they are), are converting some of the value and potential value into exploitive political value.  Unfortunately, a good many Wall Streeters have turned the markets into legal mega-slot machines, gaming them through “day trading” and even “micro-second trading” to siphon off a much value as possible as quickly as possible, converting it into exploitive political value.

Government

According to my Book, Organizational Economics: The Formation of Wealth, and as note above in this post, a government has three  missions—security, standards, and infrastructure (see. Internal and External security, standards, and infrastructure are mediating political value and all three are tertiary activities, that is, necessary but not sufficient conditions for the growth of value within the domain of the organization.  Further, the second and third activity can be Quaternary.  That is activities, like the enactment of laws and determination of regulations, policies, and standards that enable the standards and infrastructure activities.  These activities are very susceptible to manipulation for personal gain.  The personnel that enact or fund the activities can enjoy an extreme amount of exploitive political value, as I describe in my book.  In the past, it has been the lord of the manor, dictator, duke, king, emir,  priest, shaman, rabbi, Imam, or other religious leader.  Today, lobbyists must be included as they encourage the lawmakers to create uneven economic playing fields that favor one activity or one industry over another; this includes unions and other “not for profit” organizations as well as economic organizations. Consequently, mediated political value is at best much more easily converted into exploitive than either knowledge or capacity value, and is the catalyst for the conversion of these.

In this age, “Entitlements” are the single biggest place that creates exploitive political value.  These safety nets drain value from the infrastructure portion of government.  They are popular because the exploitive value goes into the pockets of the many rather than the few and popular with politicians because Entitlements buy votes.  But, entitlements are unsustainable for any organization as Greece and Italy have proven, and like the United States is likely to prove, now that the population is addicted to Entitlements.  For example, the occupy Wall St. movement feels that all college graduates are “entitled” to jobs (so what value is art history or black studies to an economic organization?).

The Net Result

Too much “unearned income” in too few wallets; too much “Entitlement income” in too many wallets.  I think what I’ve shown is that having an economy based on housing, finance, and government, like that toward which the United States is heading, is a sure recipe for going out of business.

We still have time, but do we have the leadership?

[i]These categories of industries were generally accepted in the 1920s onward, as primary: mining, and agriculture, secondary, manufacturing, and tertiary, services—these definitions are outdated and don’t get at the underlying concepts.  Therefore, I’ve redefined them for a more general meaning of the concepts.

[ii]G. Hamel and C. Prahalad, Competing for the Future: Breakthrough Strategies for Seizing Control of Your Industry and Creating the Markets of Tomorrow, (Boston: Harvard Business School Press, 1994).

---

The Chief Process Office of an Agile Organization

The IDEF0 Pattern and the Organization's Value Engine

In my book, Organizational Economics: the Formation of Wealth, I use the IDEF0 pattern to model the organization.  This pattern has three internal components, Control, Process, and Mechanisms (tooling and skills).  The Control, directs the Process, while the Mechanisms enable and support.  Therefore, the "value engine" of any organization is its Processes; value being judged by how well the organization is achieving its Vision, Mission, or Goals and Objectives.  This was first noted by Adam Smith in Chapter 1 of Book 1 of his book, "The Wealth of Nations".  This means that an organization's processes are semiannually important to their success.

So why is it that in most organizations there is a CFO and a CTO but no CPO?

The CFO and Processes
While Adam Smith created a word model of the organization that anticipated the IDEF0 model--including the controls and mechanisms around the process--he and his successor economic theoreticians ignored the model in favor of researching "capital", as if capital creates value.  The reason for this is that all economic organizations (businesses) have as one of their objectives (if not their only goal) to "make money", that is, to increase the value of the organization.

Adam Smith made a second mistake.  After demonstrating that tooling is a process multiplier and that capital is only used for acquisition of tooling, he then tacitly assigned all of the increase in the value of a process from the "division of labour" to capital's Return On Investment (ROI), when only the process multiplier part of the increase is due to the use of capital and when most of the increase is due to better processes.  This tacit assignment of value has fit nicely with management, finance engineering, and "owners" thinking and preferences since that time. 

[Sidebar: To many, this presents a conundrum.  Many times, as Adam Smith points out in Book 1 Chapter 1, one of the team members of the organization invents or innovates a new process, procedure, function, method, or tool that either makes the process more effective or cost efficient.  It's not clear, unless the organization is directly funding the research and development, that the invention or innovation belongs or should belong to the organization; but, in most companies in the US it does.  The reason is that one condition for employment is that the new employee signs over all rights to new inventions and innovations whether or not they are created on the organization's time.  Clearly, this is not entirely fair to the inventor--it should be a partnership between the inventor and the organization, that is, sharing of the value of the invention or innovation.  And both the work of Karl Marx and Ayn Rand are founded on this issue.]

If All of the ROI from process as well as the tooling is assigned through the CFO, then the assumption of others is that CFO is making good decisions, when actually, the value created by process has little to do with finance.

The Role and Responsibilities of the CPO
The role and responsibilities of the CPO is to ensure that the organization's processes, tooling, and policies and standards, enable and support the organization's vision, mission, and strategies.  Since this is the discipline of Enterprise Architecture, the CPO should be a trained Systems Engineer and Enterprise Architect (as described in several previous posts).

To meet these responsibilities, the CPO must continuously review which processes enable and support which strategies, what tooling supports the processes, and what policies and standards support the processes and which conflict.  By measuring these, the CPO can direct the organization's investments to support the organization in the most effective and cost efficient manner. 

Because of this responsibility, the organization's CFO and CTO must report to the CPO.  The CFO is responsible for the financial resources of the organization.  These are directed into process and tooling investment by the CPO.  The tooling enable and supports the processes; so, changing the direction or changing type of tooling, which is the responsibility of the CTO, is also directed by the CPO.

For most organizations, this new organizational structure would optimize their ability to compete, or at least would optimize their VOI and their agility.

Rebuilding the US Economy: Part 2, Real Job Creation

Creating Value

In Chapter One of my book, Organizational Economics: The Formation of Wealth, and in a post entitled Concept of Value, I discuss three types of value, knowledge, capacity, and political.  I will trust that the readers of this post have read one or the other [or both? :-)]. 

In my book I argue that, in general, governments (and governance) cannot create value, in terms of ROI.  Instead, governments have two interlocking roles; Creating the policies and standards (see my post The Purpose of Laws, Regulations, Policies, and Standards and Standards: A Mission of Government) and Governance that reduce Intra- and Inter-organizational friction and Creating the environment or context in which value can be created.  This involves that construction and maintenance of defense (see my Post: Security: A Mission of Government), and formal and fair markets, transportation, utilities, and communications systems(See my Post: Infrastructure: A Mission of Government and Organizational Control).

Creating Jobs

Currently, leaders of many nations are claiming they know how to create job others are struggling to determine how to do this.  Unfortunately, governments cannot create value, and since they cannot create value they cannot create jobs, as such; they can only create the context in which job creation is possible (this creates Value On Investment and the private sector can turn into ROI).

In the US, the Leadership in the period from 1933 to 1963 understood this.  This is the period in which the United States spent the most on creating the infrastructure necessary for job creation.   Examples include in the 1940s the TVA, the Hoover Dam, rural electrification, the national road systems (built by the WPA) and so on, enabled the industries of WWII to support, and some would argue to win the war.  In the 1950s, the Interstate Highway System.  All of this enabled the growing economy from the 1950s to the late 1960s.  In the early 1960s NASA's Man to the Moon program built the Internet and other technologies of the 1990s, which again, helped the economic growth of the 1980s to 1990s.

However, starting with Johnson and the entitlement programs, the US lost its way, living for 45 years on what was built up prior.  Instead of concentrating on infrastructure spending, the Johnson and succeeding administrations have concentrated on spending on a "social safety net".  Politicians have found this to be a much better way to get reelected.  And, in effect, this is creating exploitive political value from the knowledgeable by the ignorant (see Concept of Value or my book, Organizational Economics: The Formation of Wealth for the definition of exploitive political value).  I suspect that most everyone would agree, now, that having a job is the best "social safety net".  And that spending resources on the infrastructure is the only Mission that a government has to help to create jobs.

The second arrow that a government has in its quiver is its laws, regulations, policies, and standards.  The executive and legislative branches of government at the federal and state level all operate on the secondary road maintenance process. This is the process whereby county road departments fix or repair the roads.  After a road has been paved it always require maintenance due to use and the weather.  Initially, as road deteriorate,  the first cracks and potholes appear, crews are sent out to patch them. Then, as potholes appear in the potholes and the cracks open up again, the crews come back.  At some point the patches on the roughness caused by cracks and potholes make it impossible for the normal use.  When the citizens finally scream loudly enough, the road commission will send crews to "top coat" or pave over the entire surface.  Generally, this is enough to quiet the outcry, but within a year the potholes and cracks with start to reappear.  This restarts the maintenance (patching) cycle.

The US Congress and the various state legislatures attempt to use this process, also known as the "duct tape" process, to adjust or repair the laws, regulations, policies, and standards to support their Mission.  Since, at least in the US, there are two very distinct political camps with respect to the Federal Governments Mission.  One is the Keynesian "demand-siders" who say that putting government money (our money) into the hands of the "have-nots" will stimulate the system into growing jobs.  What has been found is that most people were burned by having too much credit and are taking the money to pay off debts and to save for the future.  One the other side are the "supply-siders" who say that governments ought to get out of the way (deregulate) and let business do its job of creating jobs.  This was tried in the 1990s and led to the bubbles of the 2000s and the bust of 2008.

Neither side realizes (or wants to realize) that supply and demand are all functions of a (mostly) closed loop system (as is the chicken or egg problem and many others).  Further, neither side wants to realize that there are only two ways to create jobs within any organization.  The first is through some stimulus external to the organization and the second is through the growth of knowledge.

In the 1930s, President Roosevelt enacted a series of "New Deal" programs.  These "demand-sider" programs, like the CCC, the WPA, and the TVA were designed to create jobs, pure and simple.  Fortunately for the country, these programs were also creating an entire country-wide economic infrastructure, that is they were creating Value On Investment (VOI).  Additionally, they started to lift the country out of the Great Depression.  But this was an artificial lift.  When the various programs were challenged and court and found to be unconstitutional in the mid-1930s, by 1937 the country went into recession.

In 1938, Brig. Gen. George C. Marshall was named Deputy Chief of Staff for the Army.  He was appalled at the state of the forces.  The United States had the 17th largest military in the world and was using WWI weapons that were leftover from the buildup in 1918.  With his low key approach, honesty, and a doctrine of preparedness (and the onset of WWI in Europe), by 1939, when he became Chief of Staff, Congress that had been wrangling about million dollar items started to provide first hundreds of millions and then billions of dollars for the Army (which include the Air Force) and the Navy.  Initially, this was for new weapons.  But the manufacturing of these new weapons required new factories and new tooling. 

Very quickly the US economy bounced back and then moved out smartly.  Companies, who had never paid attention to military contracts (and many of whose leaders were isolationists) were now drawn to these contracts like yellow jackets to a picnic.  "Suddenly", new construction and manufacturing jobs opened up and unemployment fell, hard (in fact so hard, that during WWII, women were first employed in large numbers).  Where Dr. "New Deal" (demand-sider) could not cure the jobs issue, Dr. WWII did.

In the process of up-dating the weapons, a great deal of research and development were done on both sides of the conflict.  The results included much more reliable radios, rockets (the V-2 led to the Moon rocket Apollo, (see my post The Cost of Rockets Built by NASA: Waterfall Process vs Short-cycle and Agile Processes), the computer, and the Atomic Bomb.  And all of these supported new businesses with new jobs after the war.

However, somewhat inadvertently, the United States government continued to support job creation in the 1950 and early 1960s through their support of basic research in nuclear physics, space, and military aircraft.  However, with the Johnson administration and succeeding administrations, all of this work was killed off in favor of "buy the votes" entitlement programs.  Now with a crumbling infrastructure and little real research and development, and little support for education or educational reforms (built on a good Enterprise Architecture Framework), all of the politicians are falling back on either demand-side or supply-side economic processes to create jobs; and neither will.

The common ground is the need for jobs.  And the only way is to straighten out the law, regulation, policies and standards "cluster-blub", cut entitlements, re-start programs like the super collider (and others of this type), and to create an education enterprise architecture that recognizes difference in the ways teachers teach and students learn, and which teaching methods are best for which students (plus making the central supervisor's office much more cost efficient).

[Sidebar: That is not to say that there are not people that deserve some help, though I suspect that between charitable organizations and good governmental regulation most of these people could be taken care of.]

Notice that it takes about 25 to 30 years (a generation) from the government investment until the investment truly bare full fruit.  It is very silly of the politicians and people of countries to expect it in less than a full generation.  However, in a recent interview, one retired US Department of Transportation head indicated that politicians cannot stand that when they appropriate a trillion dollars to upgrade highways, it takes at least 2 years to spend the funds--to me that seems way too short a time.  But the politicians (and their constituents) are of the instant gratification type and expect that 9 women can make a baby in a month.

My contention is that if we don't follow the plan outlined here, the US will continue on its merry way, until, like the economy in Ayn Rand's novel "Atlas Shrugged", it hits a discontinuity and falls into complete chaos.

Short Cycle, Agile, Level of Effort efforts, and Changes in Roles and Responsibilities

In a recent post I briefly discussed the changes in roles and emphasis when a development or transformation effort changes from a waterfall (Big Bang) effort to a short cycle-agile effort.  This post will discuss the topic in more detail in terms of a Short-Cycle, Agile, Level of Effort projects and programs.

Short Cycle

A development and transformation effort is a program or project that is changing some process, component, procedure, or tooling that supports an organization's Vision, Mission, and Strategies.  There are two types of efforts, Big Bang, and Short Cycle.  Big Bang development and transformation processes are straight line processes (see my post Product Architecture Thinking Versus System Architecture Thinking) in which there series of steps from requirements identification, through design, implementation, validation, and roll out.  It delivers the product in a single delivery--one Big Bang.

Alternatively, the Short Cycle (1 to 3 months) development and transformation process is a process that delivers the functional of the total product or system in small increments through a series of short duration development or transformation cycles.  Typically, the deliverable from the first cycle (a one month cycle) is "usable", after a fashion, and is called the Initial Operating Capability (IOC) of the system. 

I've found that the IOC will consist of the initial version of the system's access control together with a minimal set of input screens with associated data stores.  The reason for this IOC functional architecture is that security of an operational system is normally a "business" requirement; it's not wise to operate an open system.  Second, you need to "put garbage in" to "get garbage out."  If the team builds a report during the first cycle with no way to insert data to support the report, then the system is not operational in any sense.  However, if you build input screens with associated data store during the first cycle, then the customer can start inserting data during the second, while the team will likely be adding to the number of input screens and developing at least one report or information display.  My experience has been that it will take the customer about a month to get enough data in to have usable reports and output displays.  This means that by the end of the second cycle the system will be producing at least a minimum ROI for the customer.  This ROI will increase with each subsequent short cycle, which delights most customers.

Agility

The Agility of an organization  is defined as "its ability to successfully respond to unexpected challenges and opportunities".  The "successfully respond" phrase has two dimensions: making the right decision and making a timely decision.  Various components of the US military have a saying  "improvise, adapt, and overcome" that embodies the concept of agility.  This has long been a tradition of the US military.  For example, the Allies won D-Day in part, because they were much more agile.  That is, the NCOs, junior officers, and field grade officers improvised new tactics, based the manpower and equipment available, to achieve the initial mission of creating a beach head, when all of the plans for the invasion were breaking down--the capture of Omaha Beach is the seminal example.  On the other hand, the German forces followed their defense plans as closely as possible.  Consequently, senior officers were asking permission to move units to defend the coast.  By the time Hitler, hundreds of miles away, made the decision to release the panzer units, the Allies had enough units ashore to defend the beach head. 

The same definition of Agility can be used for a development or transformation process.  If a process is founded on the assumption that "All of the customer's System Requirements are known up front" then I would suggest that the process is rigid and inflexible--a totally brittle process.  That is, if new customer System Requirements are discovered as the development or transformation team is designing and implementing the system, then a formal Engineering Change Order (ECO) process (with contractual changes) is required.  All of this "administriva" costs time and resources that the team could otherwise use to create more of the product or system the customer wants.  Consequently, the customer will identify only those new requirements that will make the product or system completely unusable if not met.  This leads to poor systems and unhappy customers.  This is in contrast, agile processes based on "Not all the customer's System Requirements are known up front" so as to support the inclusion of new requirements as the system develops.

Level of Effort

Short cycle, agile development and transformation efforts require using the Level of Effort (LOE) pattern of contractual management rather than any other type.

What is a Level of Effort Project or Program?

A Level of Effort (LOE) program or project is one where the budget for the effort is spent uniformly across the duration of the effort.  Therefore, the amount of development or transformation work is uniform across the effort's duration.  This differs from the Big Bang style of development in that, normally, the Big Bang starts with a small team performing the initiation tasks, builds up the effort during detailed design and component and assembly verification and reduces the effort during post-roll out product or service support.  If the product has too many defects the PM as the ability to add personnel and use up the budget faster.

With a LOE project or program, the PM does not have that ability.  Instead, if the design team has under estimated the complexity or risk in meeting a requirement, they have the ability to refactor the requirement into two or more requirements.  They can then complete the first of these during the current segment and the others during later segments.  The fact that I'm using the term segment implies that I think that an LOE effort can only be successfully used with short cycle efforts; each segment being a cycle.  So, in short cycle, agile, LOE efforts, the System Requirements are the variable, while the budget and schedule are held as constants.

Why is it important?

Currently most efforts are still in the Big Bang style because most formal processes are of that type.  These processes include all of the required intermediate artifacts like a project plan, schedule, PDR, CDR, EWBS, IWBS, documentation for PMRs, ECOs, weekly status reports, and so on.  The reason I call these intermediate artifacts (or work products) is that they have no lasting value for the customer.

For example, since LOE projects and programs produces a uniform amount of output for each equal segment of these development or transformation efforts, there is little need for metrics like "Earned Value".  This is particularly true in short cycle development and transformation efforts where the customer can see and use the work products.  If properly performed at the end of each cycle, be it monthly or every 3 months, either the IOC version or an upgrade is rolled out.  It can be rolled out into the operational environment, or in some cases into a preproduction environment (an environment where the customer can use the new system in parallel with the old system).  Since the customer can use the IOC or upgraded system, what is the purpose of metrics like the "Earned Value" metrics (since the goal of the EV metrics is to show progress)?

Changes in Roles and Responsibilities of the Team

If, as I've experienced, there is little need for most intermediate artifacts supporting the PM procedures and methods because there is little need for those procedures and methods, then there must be changes in the roles and responsibilities of the program or project's team using a short-cycle, agile, LOE development or transformation process.

First, the process is short-cycle (one to three months) and agile ("not all the requirements are known up front"), so the process must have these two characteristics.  Having these two characteristics, immediately reduces the role of the PM, as discussed above.  No longer are all of the PM procedures  for a PDR, CDRs, EWBS, IWBS, PMRs, ECOs, weekly status reports, earned value reports, and so on necessary; in fact, they are counterproductive in that they reduce the effectiveness and cost efficiency of the effort.

Second, the emphasis is on creating or transforming a product or system to meet the customer's highest priority System Requirements, which may or may not be known at the start of the effort.  The last clause in the prior sentence is the high-level capability statement for agility.  This has two consequences.

• There is a requirement for capturing new requirements in every cycle of the effort.  This is within the role of the Systems Engineer.
• There is a requirement for the customer to prioritize the complete set of requirements at the start of each cycle.

These requirements indicates that the Systems Engineer's responsibility in identifying and managing requirements has increasing importance to any development or transformation effort.

[Sidebar:  There are studies to indicate that in software development efforts 10 to 20 percent of the software developer's effort is spent on functions not called for in the requirements.  Frequently, the customer asked for these to be removed, which costs more time and resources; and none of which produces value for the customer.  But this isn't only a problem for software developers today. A famous example is that at the start of WWII, the M-3 tank came rolling out of the factory with a police siren. No one could explain why since it wasn't in the requirements.  So, having the entire effort focus on the requirements will frequently greatly reduce costs of design and development as well as program management.]

Third, the development of functions or services are tied directly to the Functional Requirements, which link through a traceability matrix to the customer's System Requirements (see my post Types of Requirements for definitions) [though, in some smaller software development efforts, this level of decomposition may not be necessary].  Since, by the definition of a requirement, it must have a metric for when it is met, all verification and validation procedures and methods must be traceable to these metrics.  Additionally, with short-cycles the risk that the designers/developers/implementers will induce defects greatly increases.  An Induced Defect is one that is created in the process of a roll out or update of a system.  The key procedure to reduce the number of induced defects is regression testing--performing all of the same verification and validation procedures and methods used on prior releases.  Within short-cycle and agile processes, linking the V&V procedures and methods to the requirements and regression V&V emphasize both the importance of the requirements--therefore the requirements management system--and the role and responsibilities of the Systems Engineer.

Fourth, because, as discussed above, short-cycle, agile processes require LOE program management, the role of the PM is diminished further.  No longer can the PM "control" the effort by adding to reducing resources to a particular task.  Instead, the Systems Engineer must decide in each cycle how many of the highest priority requirements the team can meet during the next cycle.  Consequently, the PM is really only responsible for working with the suppliers and consultant (both external and internal to the organization), ensuring that the processes, procedures, and methods of the short-cycle, agile process are properly executed, and reporting results to higher management.

These changes in roles and responsibilities are a dramatic shift in the cultural of development and transformation.

Product Architecture Thinking Versus System Architecture Thinking

Cultural Thinking about Architecture

Until the early 1960s, the discipline of architecture (or functional design) focused on the creation/design/ development/implementation of products like buildings, cars, ships, aircraft, and so on.  Actually, other than buildings, most of the Architects were called "functional" designers, or some such term, to differentiate them from detailed designers and engineers/design analysts.  This is part of the reason that most people associate architecture and an architect with the design of homes, skyscrapers, and other buildings, but not with products, systems, or services.  In fact Architects themselves are having a hard time identifying their role.

In the late 1990s, the US Congress mandated that all Federal Departments must have an Enterprise Architecture to purchase new IT equipment and software.  The thrust of the reasoning was that a Department should have an overall plan, which makes a good deal of sense.  I suspect the term "Enterprise Architecture" to denote the unification of the supporting tooling, though they could have used "Enterprise IT Engineering" in the manner of Manufacturing Engineering, which unifies the processes, procedures, functions, and methods of the assembly line.  And yet, Enterprise Architecture means something more, as embodied the the Federal Enterprise Architecture Framework (FEAF).  The architecture team that created this framework to recognize that processes, systems, and other tooling must support the organization's Vision and Mission.  However, its up to the organization and Enterprise Architect to implement processes that can populate and use the data in the framework effectively.  And that's the rub.

Functions vs Processes and Products vs Systems
In the late 1990s and early 2000s the DoD referred to armed drones as Unmanned Combat Air Vehicles (UCAVs), then in the later 2000s, they changed the name of the concept to Unmanned Combat Air Systems (UCAS).  Why?

There are three reasons having to do with a change in western culture, the most difficult changes for any organization.  These are: 1) a change from linear process understanding to linear and cyclic, 2) a change from thinking about a set of functions to understanding a function as part of a process, and a change in thinking from product to system.

Linear vs Cyclic Temporal Thinking
Product thinking is creating something in a temporally linear fashion, that is, creating a product has a start and an end.  D. Boorstin in the first section of his book, The Discovers, discusses the evolution of the concept of time, from its cyclic origins through the creation of a calendar to the numbering of years, to the concept of history as a sequence of events.  To paraphrase Boorstin, for millennia all human thinking and human society was ruled by the yearly and monthly cycles of nature.  Gradually, likely starting with the advent of clans and villages a vague concept of a linear series of events formed.  Still, the cycles of life are still at the core of most societies (e.g., in the east, the Hindu cycles, and the Chinese year, and in the West, Christmas and New Years, and various national holidays). 

The concept of history change cultural thinking from cycles to a progression through a series of linear temporal events (events in time that don't repeat and cause other events to occur).  In several centuries this concept of history permeated Western Culture.  The concept of history broke and flattened the temporal cycles into a flat line of events.  With this concept and with data, information, and knowledge, in the form of books, meant that Western culture now had the ability to fully understand the concept of progress.  Adam Smith applied this concept to manufacturing, in the form of a process, which divided the process into functions (events), and which ended up producing many more products from the same inputs of raw materials, labor, and tooling.

Function vs Process

In the Chapter 1 of Book 1 of An Inquiry into the Nature and Causes of the Wealth of Nations (commonly called The Wealth of Nations), Adam Smith discussed the concept of  the"Division of Labour".  This chapter is the most important chapter of his book and the concept of the Division of Labor is the most important concept; far more important than "the invisible hand" concept or any of the others.  It is because this concept of a process made from discrete functions is the basis for all of the manufacturing transformation of the Industrial Revolution.  Prior to this, the division of labor was an immature and informal concept; after, many cottage industrialists adopted the concept or were put out of business by those that did.

Adam Smith did this by using a very simple example, the making of straight pins.  In this example he demonstrated that eight men each serving in a specialized function could make more than 10 times the number of pins in a day when compared with each of the men performing all the functions.  He called it the division of labor; we call it "functional specialization".

Functional specialization of skills and tooling permeates Western Culture and has led to greater wealth production than any prior concept that has been created.  Consequently, as Western Civilization accreted knowledge, the researchers, engineering, and skilled workers became more expert in their specialized function and increasingly less aware of the rest of the process.

Currently, most organizations are structured by function, HR, accounting, contracts, finance, marketing or business development, and so on.  In manufacturing there are designers (detailed design engineers), engineers (analysts of the design), manufacturing engineers and other Subject Matter Experts (SMEs).  Each of these functions vie with one another for funding to better optimize their particular function.  And most organizations allocate funding to these functions (or sometimes groups of functions) for the type of optimization.

Unfortunately, allocating funds by function is a very poor way to allocate funds.  There is a principle in Systems Engineering that, "Optimizing the sub-systems, sub-optimizes the system".   J.B. Quinn, in “Managing Innovation: Controlled Chaos”, (Harvard Business Review, May-June 1985), demonstrated this principle, as shown in Figure 1.

Figure 1--Function vs Process Funding

As shown in Figure 1, at the bottom where you cannot really see it, for every unit of money invested in a function, the organization will get, at best, one unit of money improvement in the total process.  However, if the investment effects more than one function would yield 2(N-1)-1 in total improvement in the process.  So focusing on investing in the process will yield much better results and focusing on the function.  This is the role of the Enterprise Architect, and the organization's process and systems engineer using the Mission Alignment process.  While this point was intuitively understood by manufacturing (e.g., assembly line manufacturing engineering) for well over 150 years, and was demonstrated in 1985, somehow Functional Management is not willing to give up their investment decision perquisite.

Product vs System

Influenced by the Wealth of Nations, from about 1800 on, industries, first in Britain, then across the Western world, and finally globally, used Adam Smith's concept of a process as an assembly line of functions to create more real value than humankind had ever produced before.  But this value was in the form of products--things.  Developing new "things" is a linear process.  It starts with an idea, an invention, or an innovation.  Continues with product development to initial production and marketing.  Finally, if successful, there is a ramp up of production, which continues until superseded by a new product.  This is the Waterfall Process Model. 

The organization that manufactured the product had only the obligation to ensure that the product would meet the specifications the organization advertised at the time the customer purchased the product, and in a very few cases, early in the product's life cycle.  Generally, these specifications were so general, so non-specific, and so opaque that the manufacturing company could not be held responsible.  In fact, a good many companies that are over 100 years old, exist only because they actually supported their product and its specifications.  Their customers turned into their advertising agency.

This model is good for development (what some call product realization) and transformation projects, but the model has two fatal flaws, long term.  The first (as I discuss in my post Systems Engineering, Product/System/Service Implementing, and Program Management) is that the waterfall process is based on the assumption that "All of the requirements have been identified up front"; a heroic assumption to say the least (and generally completely invalid).  The second has equal impact and was caused by the transportation and communications systems of the 1700s to the 1950s.  This flaw is that "Once the product leaves of the factory it is no longer the concern of the manufacturer."

This second flaw in historical/straight line/waterfall thinking effects both the customer and the supplier.  The customer had and has a hard time keeping the product maintained.  For example, most automobile companies in the 1890s did not have dealerships with service departments; in fact they did not have dealerships, as such.  Instead, most automobiles were purchased by going to the factory or ordering by mail.  And even today, most automobile manufacturers don't fully consider the implications of disposal when design a vehicle.  So they are thinking of an automobile as a product not a system or system of systems (which would include the road system and the fuel production and distribution systems.  The flavor of this for the United States is in its disposable economic thinking; in everything from diapers to houses (yes, houses...many times people are purchasing houses in the US housing slump, knocking them down, to build larger much more expensive housing...at least in some major metropolitan areas).  Consequently, nothing is built to last, but is a consumable product.

Systems Thinking and The Wheel of Progress
Since the 1960s, there has been a very slow, but growing trend toward cyclic thinking with organizations.  Some of this is due to the impact of the environmental movement, and ecosystems models.  More of this change in thinking is due to the realization that there really is a "wheel of progress".  Like a wheel on a cart, the wheel of progress goes through cycles to move forward.
 
The "cycle" of the "wheel of progress" is the OODA Loop Process, that is, Observe, Orient, Decide, Act (OODA) loop.  The actual development or transformation of a system occurs during the "Act" function.  This can be either a straight-line, "waterfall-like" process or a short-cycle "RAD-like" process.  However, only when the customer observes the of the transformed system in operation, orients the results of the observation of the system in operation to the organization's Vision and Mission to determine if it is being effective and cost efficient, then deciding to act or not during the rest of the cycle.  The key difference between product and systems thinking is that each "Act" function is followed by an "Observe" function.  In other words, there is a feedback loop to ensure that the output from the process creates the benefits required and that any defects in the final product are caught and rectified in the next cycle before the defect causes harm.  For example, Ford treated is Bronco SUV as a product rather than a system.  "Suddenly", tire blowouts on the SUV contributed to accidents, in some of which the passengers were killed.  If Ford had treated the Bronco as a system, rather than a product, and kept metrics on problems that the dealers found, then they might have caught the problem much earlier.  Again, last year, Toyota, also treating their cars as products rather than systems, found a whole series of problems.

OODA Loop velocity
USAF Col. John Boyd, creator of the OODA Loop felt that the key to success in both aerial duels and on the battlefield is that the velocity through the OODA Loop cycle was faster than your opponent's.  Others have found that this works with businesses and other organizations as well.  This is the seminal reason to go to short cycle development and transformation.  Short cycle in this case would be 1 to 3 months, rather than the "yearly planning cycle" of most organizations.  Consequently, all observations, orientation and deciding should be good enough, not develop for the optimal, there isn't one. [this follows the military axiom that Grant,  Lee, Jackson, and even Patton followed "Doing something now is always better than doing the right thing later".]  Expect change because not all of the requirements are known, and even if they are known, the technological and organizational (business) environment will change within one to three months.  But remember the organization's Mission, and especially its Vision, change little over time; therefore the performance the metrics, the metrics that measure how optimal the current systems and proposed changes are, will change little.  So these metrics are the guides in this environment of continuous change.  Plan and implement for upgrade and change, not stability--this is the essence of an agile systems. 

This is true of hardware systems as well as software.  For example, in 1954, Haworth Office Furniture started building movable wall partitions to create offices.  Steel Case and Herman Miller followed suit in the early 1960s.  At that point, businesses and other organizations could lease all or part of a floor of an office building.  As the needs of the organization changed these partitions could be reconfigured.  This made for agile office space, or office systems (and the bane of most office workers, the cubicle), but allows the organization to make most effective and cost efficient use of the space it has available.

The Role of the Systems Engineering Disciplines
There are significant consequences for the structure of an organization that is attempting to be highly responsive to the challenges and opportunities presented to it, while in its process for achieving its Mission and Vision in a continuously changing operational and technical environment.  It has to operate and transform itself in an environment that is much more like basketball (continuous play) than American football (discrete plays from the scrimmage line with its downs)--apologies to any international readers for this analogy.  This requires continuous cyclic transformation (system transformation) as opposed to straight line transformation (product development). 

Treating Process in Product Thinking Terms
Starting in the 1980s, after the publication of Quality is Free, by Phil Crosby in 1979, the quality movement and quality circles, the concept of Integrated Product Teams (IPTs, which some changed to Integrated Product and Process Teams, IPPTs) organizations have been attempts to move from a focus on product thinking toward a focus on system thinking).  Part of this was in response to the Japanese lean process methods, stemming in part from the work of Edward Deming and others.  First international attempt to is ISO 9000 quality Product Thinking (starting in 2002), though in transition to Systems thinking, since it is a one time straight-through (Six Sigma) methodology, starting with identifying a process or functional problem and ending with a change in the process, function, or supporting system.

Other attempts at systems thinking were an outgrowth of this emphasis on producing quality products (product thinking).  For example, the Balanced Scorecard (BSC) approach, conceptualized in 1987. The BSC was attempting to look at all dimensions of an organization by measuring multiple dimensions.  It uses four dimensions to measure the performance of an organization and its management instead of measure the performance of an organization on more than the financial dimension.  The Software Engineering Institute (SEI) built layer four, measurement, into the Capability Maturity Model for the same purpose.

In 1990, Michael Hammer began to create the discipline of Business Process Reengineering (BPR), followed by others like Tom Peters and Peter Drucker.  This discipline treats the process as a process rather than as a series of functions.  It is more like the Manufacturing Engineering discipline that seeks to optimize the processes with respect to cost efficiency per unit produced.  For example, Michael Hammer would say that no matter size of an organization, it's books can closed at the end of each day, not by spending two weeks at the end of the business or fiscal year "closing the books".  Or in another example, you can tell if an organization is focused on functions or processes by its budgeting model; either a process budgeting model or a functional budgeting model.

Like the Lean concept, and to some degree, ISO 9000, ITIL,and other standards, BPR does little to link to the organization's Vision and Mission, as Jim Collins discusses in Built to Last (2002); or as he puts the BHAG, BIG HARRY AUDACIOUS GOALS.  Instead, it focuses on cost efficiency (cost reduction through reducing both waste and organizational friction, one type of waste) within the business processes.

System Architecture Thinking and the Enterprise Architect
In 1999, work started on the Federal Enterprise Architecture Framework (FEAF) with a very traditional four layer architecture, business process, application, data, and technology.  In 2001, a new version was released that included a fifth layer, the Performance Reference Model.  For the first time the FEAF links all of the organization's processes and enabling and supporting technology to its Vision and Mission.  Further, if properly implemented, it can do this in a measurable manner (see my post Transformation Benefits Measurement, the Political and Technical Hard Part of Mission Alignment and Enterprise Architecture).  This enables the Enterprise Architect to perform in the role that I have discussed in several of my posts and in comments in some of the groups in the LinkedIn site.  These are decision support for investment decision-making processes and support for the governance and policy management processes (additionally, I see the Enterprise Architect as responsible for the Technology Change Management process for reasons that I discuss in Technology Change Management: An Activity of the Enterprise Architect).   Further, successful organizations will use a Short Cycle investment decision-making (Mission Alignment) and implementing (Mission Implementation) process, for reasons discussed above. [Sidebar: there may be a limited number of successful project that need multiple years to complete.  For example, large buildings, new designs for an airframe of aircraft, large ships--all very large construction effort, while some like construction or reconstruction of highways can be short cycle efforts--much to the joy of the motoring public.]   The Enterprise Architect (EA), using the OODA Loop pattern, has continuous measured feedback as the change operates.  Given that there will be a learning curve for all changes in operation; still, the Enterprise Architect is in the best position to provide guidance as to what worked and what other changes are needed to further optimize the organization's processes and tooling to support its Mission and Vision.  Additionally, because the EA is accountable for the Enterprise Architecture, he or she has the perspective of entire organization's processes and tooling, rather than just a portion and is in the position to make recommendations on investments and governance.

System Architecture Thinking and the Systems Engineer and System Architect
One consequence of the short-cycle processes is that all short-cycle efforts are "level of effort" based.  Level of Effort is a development or transformation effort is executed using a given a set level of resources over the entire period of the effort.  Whereas in a waterfall-like "Big Bang" process scheduling the resources to support the effort is a key responsibility of the effort (and the PM), with the short-cycle the work must fit into the cycles. With the waterfall, the PM could schedule all of the work by adding resources or lengthened the time required to design, develop, implement and verify; now the work must fit into a given time and level of resource.  Now, the PM can't do either because they are held constant.
 If, in order to make an agile process, we use axiom that "Not all of the requirements are known at the start of the effort", rather than the other way around, then any scheduling of work beyond the current cycle is an exercise in futility because as the number of known requirements increases, some of the previously unknown requirements will be of higher priority for the customer than any of the known requirements.  Since a Mission of a supplier is to satisfy the needs of the customer, each cycle will work on the highest priority requirements, which means that some or many of the known requirements will be "below the line" on each cycle.  The final consequence of this is that some of the originally known requirements will not be met by the final product.  Instead, the customer will get the organization's highest priority requirements fulfilled.  I have found that when this is the case, the customer is more delighted with the product, takes greater ownership of the product, and finds resources to continue with the lower priority requirements.

On the other hand, not fulfilling all on the initially known requirements (some of which were not real requirements, some of which contradicted other requirements) gives PMs, the contracts department, accountants, lawyers, and other finance engineers the pip!  Culturally,generally  they are incapable of dealing in this manner; their functions are not built to handle it when the process is introduced.  Fundamentally making the assumption that "Not all the requirements are known up front" makes the short-cycle development process Systems Requirements-based instead of Programmatic Requirements-based.  This is the major stumbling block to the introduction of this type of process because it emphasizes the roles of the Systems Engineer and System Architect and de-emphasizes the role of the PM.

The customer too, must become accustomed to the concept, though in my experience on many efforts, the once the customer unders the customer's role in this process, the customer becomes delighted.  I had one very high-level customer that said after the second iteration through one project, "I would never do any IT effort again that does not use this process."

Types of Requirements

Definition of a Requirement

A Requirement is a measurable expression of what a customer wants and for which the customer is willing to pay.  Therefore, a requirement has three attributes:

1. It has a description of what the customer wants or desires or some derivation or transformation of what the customer wants or desires.
2. That want or desire is measurable in a way to ensure that the want or desire is fulfilled.
3. The customer is willing to pay for the supplier to fulfill the want or desire.

All types of requirements these attributes.  However, there is another class of documented wants and desires of customers that many customers and Systems Engineers misclassify as requirements.  These wants and desires do not have the second attribute, a metric to determine when the requirement is met.  I call these capabilities and the description, capability statements.  Customers are particularly enamored of the capability statements since, "Customers don't know what they want, but do know what they don't want."  The reason that they are enamored of capability statements is that language is slippery and allows for a great deal of interpretation/interpolation.  This means that if the supplier presents them with a result the supplier feels meets their capability need, the customer can stay NO IT DOESN'T; and the supplier has no recourse but to default on the contract or or ask for "the real requirements" to implement the product against.  This is very expensive for the supplier and very enjoyable for the customer, especially if they really don't what they want (measurably) and want the supplier to pay for the research; which is essentially what the supplier is doing in this mode of operation.  I have been on too many "opportunities" where I have seen this in action, despite my best attempts to stay the effort until at lease some of the "the real" requirements are known.  When the effort has been stayed by the program or project manager and the customer begins to understand the importance of requirements, as opposed to capability statements, then the customer tends to pay much more attention to "getting the requirements document right".

Types of Requirements and Roles

I will define and delineate the types of requirements by the Roles the identifies or defines and documents them.  There are three roles within the major discipline of Systems Engineering that identify or define requirements, as I discussed in my posts The Definition of the Disciplines of Systems Engineering and Enterprise Architecture and System Architecture and a presentation of the same at 2009 SEI SATURN conference.  The roles are: the Systems Engineer, the System Architect, and the Enterprise Architect.

Systems Engineer

The Systems Engineer identifies and manages the Customer's Requirements.  The Systems Engineer never should define the customer's requirements, but work with the customer to identify the requirements.  Once identified, the Systems Engineer must manage the customer's requirements to validate that these requirements are met.  There are two types of Customer Requirements, Programmatic Requirements and Customer System Requirements.

Customer Programmatic Requirements

There are two types of programmatic requirements:

• Cost--What the customer is willing to pay for a product that meets the System Requirements
• Schedule--How long the customer is willing to wait for the product that meets the System Requirements

Program Management considers the programmatic requirements within their exclusive purview.  They are wrong!  To start with, the Systems Engineer must analyze the known requirements to determine whether or not the effort is even feasible within budget and time constraints. 

Sidebar
To often, business development (or marketing), or for internal efforts, "management" will promise more (in very general terms) than any supplier can deliver.  I call this, "Listening with your mouth!"  Good Systems Engineering practice requires ears.  The Systems Engineer must work with the customer to clearly (measurably) identify the customer's real requirements, in part, by listening to the customer and documenting the requirements the customer states.

End of Sidebar

Once the Systems Engineer, together with any Subject Matter Experts (SMEs), have determined that the effort is feasible, the Systems Engineer must use Requirements Analysis (which I will discuss in a future post) to determine any gaps or conflicts among the requirements.  These should be documented, and if possible, discussed with the customer.  Then the Systems Engineer, SMEs, and Contracts expert should put together a proposal, based on the known and inferred requirements, including a notional Work Breakdown Structure (WBS) with a Bases Of Estimate (BOE), and a notional project plan.  If the proposal is accepted, the Systems Engineer/System Architect and SMEs should refine the WBS and Project Plan before turning it over to the Program Manager (unless the Program Manager is also an SME or Systems Engineer, which, in my experience, they ain't).  In this scenario, the people with the knowledge and the skills to execute the plan are the ones that create the plan; not those only interested in managing the programmatic requirements.

Customer System Requirements

Of more interest to the Systems Engineer, because these are the requirements from which the product will be constructed, while meeting the programmatic requirements (which are a form of Design Constraint), are the Customer's System Requirements.  In the US DoD Mil-Spec nomenclature from the 1970s and 1980s, the customer's System Requirements are the A-Spec.  The reason I bring this up is to show that these requirements concepts are not new.  As I describe in an early post, Types of Customer Requirements and the System Architecture Process, there are two types of System Requirements, those that the product must perform and those the product must meet.

Sidebar
The metrics associated with the Customer's System Requirements are the System Validation criteria.  While some Systems Engineers would argue that they can only Verify that the product meets the customer's requirements.  That misses the distinction between verification and validation.  By the best definitions I've seen, verification indicates that the components or functions meet the component specifications or the functional requirements.  Validation means that the product meets the customer's system requirements, that is, it does what the customer requires.  Many times all the parts of a product work as specified by the System Architect, but the System Architect did not specify a product, in total, that would meet the customer's system requirements.  That is the key difference and the rest is semantics.
End of Sidebar

Customer Functional Requirements

The Customer's Functional Requirements are those requirements that the product, system, or service "must perform".  The customer's functional requirements are based on how the customer envisions using the product.  For example, in IT, it would be "one way one type of user would use the application, system, or service".  This is nearly the exact definition of a Use Case (see the Glossary for the exact definition).  I've found that Use Cases are the simplest, clearest way for the Systems Engineer to communicate the customer's functional requirements to the development/transformation team.  Again, a Functional Requirement is always an action.

Design Constraints

Design Constraints are those requirements that the product, system, or service "must meet".  For example, the customer might want a display in the new Service or a report from the new Service to be identical with that of the current application.   Or the customer might want given level of dependability, the term which the Reliability, Maintainability Serviceability organization uses as the umbrella for all the "-ilities" (e.g., reliability, maintainability, serviceability, scalability, recover-ability, response time, up-time, etc.).  These are all attributes of the product, system, service.

There are many types of Design Constraints.   For example, internal and external policies and standards all constrain a design of the product and there can be sever consequences if a supplier ignores one or more of theses Design Constraints, even if the Systems Engineer does not know of them.  The Systems Engineer has to verify that all of these Design Constraint, type requirements, are met before the product is put into operation.

System Architect

The System Architect transforms the customer's System Requirements in the product's Functional Requirements, then orders and structure these Functional Requirements into a System Architecture or Functional Design, allocates tightly coupled groups of these requirements, together with the Design Constraints, to candidate Components Requirements or Specifications, and finally to perform Trade-off Studies to determine the initial Bill Of Materials (BOM).

System Functional Requirements

The System Functional Requirements (or Functional Requirements) are a set of functions the product, system or Service must perform to meet the Customer's System Requirements.  In the US DoD Mil-Spec terms, this would be the B-Spec.  The Functional Requirements are the result of a transformation of the Customer's System Requirements by the System Architect.  This transformation is the result of two fairly complex procedures, Decomposition (a form of Requirements Analysis) and Derivation (which can use a fairly formal process including UML diagrams, but that requires significant creativity if done properly.)

System Component Requirements (or Specifications)

System Component Requirements (or Specifications) are the requirements for the actual components needed to create the product, system, or Service.  In the US DoD Mil-Spec terms, this would be the C-Spec.  Again, the System Architect transforms requirements, this time it is the Functional Requirements into the Component Requirements.  Again the transformation is a result of two fairly complex procedures, the creation of a System Architecture, also called a Functional Design through ordering and structuring the requirements.  Then the System Architect allocates both the grouped System Functional Requirements and the Design Constraints to potential components.  The System Architect can use metrics associated with the System Component Requirements (specifications) within a trade-off study function to determine the actual components that the product will use.

Enterprise Architect
The Enterprise Architect supports the organization's leadership in optimizing their investment decisions, their policies and standards, to enable the organization to achieve its Vision, and Mission, as I've discussed in A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture and Governance, and Policy Management Processes: the Linkage with SOA. Optimizing is not increased cost efficiency of the investment, but the effectiveness of the processes used to achieve the mission or goal, and the cost efficiency of the tooling in supporting the effective processes. This is exceptionally important to any organization, since it can mean the difference between thriving and not surviving.

To adequately perform his or her role, the Enterprise Architect must work with three types of requirements, the Organizational performance requirements, Organizational (business) process requirements, and service component requirements.

Organizational Performance Requirements

There are three layers of performance requirements for an organization they all derive from the organization's Vision Statement.  For example, the Vision Statement for the United States--one of the best I've seen--is its Preamble,

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.

As you can see, there are a series of statements "establish Justice", "provide for the common defence", and so on, that both provide the Vision and give a broad hint at both a series of Mission Statements and the method for measuring the achievement of the Vision through the various Missions.  These are the Vision Requirements.  These Vision Requirements enable the measurement of the success of the organization's various Missions.

To realize the Vision, organizations create various Missions.  Military organizations are best known for Missions, while many business organizations have a goal with multiple objectives fulfilling the role of Vision and Mission.  To perform a Mission, it has Mission Requirements, that is, needs that must be fulfilled to perform the Mission.  These include requirements for the Strategies, Processes, and enabling and supporting tooling.  The Enterprise Architect can use the metrics from these requirements to determine the success of the Strategies, Processes, and tooling in supporting the Mission, and through the Mission's requirements linkage to the Vision, their success in achieving the organization's Vision.

The final class of objects Strategy Requirements are needs of a strategy (guidance for achieving the Mission), in terms of the processes and tooling to enable and supporting it.  Products to enable and support these are supplied by the Processes and tooling.  Therefore, they are the key "business requirements" imposed on both the processes and tooling.

Organizational (Business) Process Requirements

The Organizational (Business) Process Requirements come from two sources.  The first set is the requirements of the Performance Architecture (Mission and Strategy Requirements) and the second set is derived from other Organizational Process Requirements.  This set of requirements falls into two categories.

Mission Alignment Requirements

Mission Alignment Requirements are needs of the Mission and Strategies that the processes and tooling must perform must perform to achieve the organization's vision.  Additional Mission Alignment requirements may be imposed on one process by another process.  These tie measurably back to the Mission and Strategies.  The Enterprise Architect uses them to determine which processes and tooling to retire, which to transform, update, or upgrade, and what new processes and tooling the organization requires move toward achieving it Mission and Vision.  This is the objective of the Mission Alignment process.

Policy and Standard Requirements
Policy and Standard requirements are needs the processes and tooling must meet to reduce the intra-organizational process friction, thereby making the processes and tooling both more process effective, and also more cost efficient.  The Enterprise Architect uses these requirements to identify candidate policies, standards, and business rules to enact, revise, or delete.  The Enterprise Architect will use this information and knowledge to support the organization's Governance process.

Service Component Requirements
As a result of the Mission Alignment process, the organization's leadership will fund individual development and transformation efforts.  Mission Alignment identifies "customer requirements" from the Enterprise level.  These are "Customer" Functional Requirements and are used by the effort's Systems Engineer.  The products of the Governance and Policy Management process are Design Constraints also used by the effort's Systems Engineer.

So, as you can see, all of these types of requirement form a requirements web or mesh.  And all of them, if use consistently and in concert can substantially boost the velocity of the organization toward its Mission and Vision.