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.

Why Separate Design Constraints from the Customer's System Requirements?

Background

Traditionally,  Requirements Identification, Analysis, and Management was based on "Shall" statements, that is, "the product (service) shall...".  Fundamentally, the "Shall Statements" were contractual obligations to be met by the contractor in creating a new product.  Systems Engineers and Requirements Analysts would attempt to identify both the requirements' description and metrics for each (i.e., when the requirement was met) by starting the Requirements Identification and Management effort by "shredding" the contract to identify the requirements within "the shall" statements.

Once the contractually contracted "requirements" were identified, the Systems Engineer/System Architect would decompose those requirements, partially in an effort to:

1) identify any requirements gaps,
2) ensure that all requirements were single requirements and not a group of requirements, and
3)  identify evaluation procedures to ensure that the requirements were met. 

This last reason was a requirement of any Systems Engineering process because most of the contractual requirements had no method for identifying when they were met; they were statements of the capabilities the customer required.  For example, within Information Technology (IT) "the system shall be user friendly" is typical.  However, what the customer meant by "user friendly" was left to the imagination of the software developer.  This particular requirement has led to many "programmer friendly" systems being initially rolled out, a great many cost overruns to "fix the defects" (defects in the requirements), and a great deal of customer dissatisfaction.

With respect to the first two reasons for decomposition, I have seen both the contracts and the requirements stripped from the contracts of several historic aerospace programs and poor the resulting requirements were.  The consequence was that Systems Engineers, from the 1960s to the 1990s, spent a great deal of effort and time to decompose the requirements in an attempt to truly identify the real requirements (those that the customer wants, is willing to pay for, and with a definable and quantifiable measurement of when it is met. 

Ralph Young, in his book Effective Requirements Practices from 2001, discussed studies that found that less than 50% of the real requirements for a system were in the contractual agreement.  Further there were significant numbers of the known requirements that were either conflicting or simply wrong.  Since this has been the case for most efforts most of the time, you can understand why requirements decomposition (definition) became such an important function of the Systems Engineer.  The decomposition process included State Diagrams, Functional Flow Diagrams and many other "requirements analysis" techniques that enable the Systems Engineer (Requirements Analyst) to tease out as many "missing" requirements as possible. 

____________
The Program Management Issue with Requirements (A Sidebar)
Once completed (though many times before completion) the Program Managers and Finance Engineers put a project plan together based on the Heroic Assumption that all of the customer's requirements are known.  That is the foundational assumption of the Waterfall process for System Realization; and is patently false.  Consequently, project after program after effort fails to meet the programmatic requirements unless the Program Manager simply declares victory and leaves the mess for the operational Systems Engineers and Designers/Developers to clean up.  Generally, they do this through abbreviated validation or no validation at all.

The reason they make the assumption that "all the requirements are known upfront" is that it is the only way they can see to create a project schedule, project plan, and earned value metrics to control the effort.  Therefore, they religiously believe that their assumption is true, when time after time its proven false.  Einstein's definition of insanity is "perform the same test over and over and expecting different results".

Making the assumption that "not all of the requirements are known upfront" makes life much more difficult for the Program Manager, unless the process and functions is designed around that assumption.  While this has been done, I for one have done it, it is heretical to the Program Management catholic doctrine.  Until Program Management and Financial Engineering "disciplines" learn to put more emphasis on the Customer's System or Product requirements and less on cost and schedule, and understand that the known requirements are merely an incomplete and partially incorrect set of requirements, development and transformation programs will always miss their cost and schedule marks; in addition to having very dissatisfied customers.
(End of Sidebar)

From the mid-1960s to ~2000, I dealt with issue of requirements identification, trying most of the methods described in Ralph Young's book cited above.  The net result was that all requirements identification methods failed for one of four reasons.

1. The Systems Engineer didn't describe the requirements using the customers language and ideas and the Systems Engineer didn't rephrase or translate them into the language of the developers.  This leads to many defects, finger pointing exercises, and customer dissatisfaction.
2. The second is described in the sidebar.  That is, the waterfall process used in most development and transformation efforts was founded on an assumption that is just plain wrong.
3. For the types of efforts I was working on, IT transformation projects, the customer's system requirements were only partially based on the process(es) that they were supposed to support.  Most of the time they were short-sightedly based on the function that the particular customer was performing.  Consequently, "optimizing the functions, sub-optimized the process".
4. All customer system requirements were treated the same.  I found this to be incorrect and would lead to many defects.

Types of Requirements: Capabilities, Functional Requirements, and Design Constraints

When I started analyzing the requirements in various requirements documents and systems in the early 1990s, I found that there were two classes of requirements, and then requirements that weren't requirements at all, just wishful thinking.  The two classes are those that the system "must perform" (or process functions it must enable and support) and those the system "must meet".  An example of a must perform requirement is "The system will show project status using a standard form".  The standard form would be considered as a must meet requirement because a form is nothing that a system "must perform", but it is a requirement that the system "must meet".  This requirement constrains the design.  The designer/developer can't create a new form; he or she must create a system the produces the standard form.  Therefore, I define it as a Design Constraint, since it constrains the design.  Likewise, a requirement that the system "must perform" shows action.  Therefore, I define this type of requirement as a customer system functional requirement, or more simple a Customer System Requirement.  Finally, there are these "wishful thinking" statements.  Many times, these are, in fact, genuine customer needed capabilities, (unknown requirements).  The reason they are not requirements is that they have no metric associated with them to enable the implementer to know when they have been met.  Therefore, rather than ignore them, I've put them into a category (or type) I call Capabilities.  These are statements the Systems Engineer must investigate to determine if they are requirements or not.

In any software development or transformation effort, frequently, there are more design constraints than customer system requirements because there are so many types of design constraints and the relative number of functions is, normally, limited.  Typically, an organization does not radically reorganize or transform all of its processes and supporting systems concurrently; if there is a higher risk method to move to the going out of business curve, other than fraud, I don't know it.  Instead, the organization will develop or transform a single business function or service in a single project; though it may have several projects.

On the other hand, all development and transformation efforts of an organization are subject to the policies and standards of the organization, to contractual obligation of the organization, and to external laws and regulations.  All of these constrain the design of systems.  For example, Section 508 of the US Rehabilitation Act effects the development of all governmental websites by ensuring that the visually and auditorially impaired can use the site.  Again, the Clinger-Cohn Act effects both the choice of transformation efforts and the products IT can use within those projects, by not allowing software, which has been sunsetted or is being sunsetted, to be used in the operation of many businesses within the United States.  This act mandates that those systems must be updated to a current version of the system.  Obviously, these constrain the design of a new or a transforming system or service of an organization, irrespective of the function the system or service of the organization.

The organization has other design constraints, like having the organization's logo on all user interface displays, for example, or producing the same formats for the reports coming out of the new system, as from the prior system.  The organization may use Microsoft databases and therefore have expertise supporting them; in which case using Oracle or IBM products would not be feasible--except in very special circumstances (e.g., a contractual obligation).  Consequently, these "must meet" requirements are pervasive across all of an organization's development and transformation efforts.

Advantages of Separation
When, in the 1990s, I discovered this, I recommended to my management that we start a repository of design constraints to use on all projects of our aerospace and defense corporate organization and have recommended it many time since.   In my presentation I envisioned four benefits:

• It enables and supports the reuse of Design Constraints and their evaluation methods.  This makes evaluating them both consistent and cost efficient.
• It minimizes the risk of leaving a Design Constraint out of the requirements since the Systems Engineer has a long list of these from the repository.  This is a much better way than either trusting the Systems Engineer to remember or figure it out, or any private lists of design constraints kept by any single Systems Engineer.
• If the Customer System Requirements are separated from the Design Constraints, then the System Architecture process is more effective and cost efficient because the System Architect does not have to attempt to sort these out and keep them straight during the process.  (Note: the Customer System Requirements are the requirements that are decomposed and from which the System Architecture is derived.)
• Finally, if the organization uses an Enterprise Architecture process like I have described in I discussed in my posts A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture and Asset and Enterprise Architecture Repository then, understanding of what Systems will be affected with a change in policies or standards becomes a simple effort.

Enterprise Architecture and System Architecture

The discipline of Enterprise Architect is distinctly different from System Architect, though many confuse the two.  See the post, "The Definition of the Disciplines of Systems Engineering" for the definitions of the two disciplines.

Fundamentally, they are both sub-disciplines of Systems Engineering, and both deal with requirements, risks, issues, and evaluation, but are much more specialized in their roles, that is, what they use these Systems Engineering functions for.  The responsibilities of the Systems Engineer include working with the customer to identify the customer's programmatic (cost and schedule) and system (functions to be performed, and constraints on the design) requirements, identifying and managing risks (see my post "Risk Defined") and issues associated with the design, managing the configuration of the design, and ensuring that all of the customer's system requirements are met, through a verification and validation (V&V) process.

The responsibilities of the System Architect include transforming the customer's system requirements (see the post entitled "Types of Customer Requirements and the System Architecture Process" for the definition), as identified by the Systems Engineer, through decomposing them in a manner that enables the architect to derive the functions the deliverable must perform.  These are the system functional requirements for the deliverable.

The System Architect then structures and orders these system functional requirements (or system specifications) into a System Architect (or Functional Design).  The System Architect then has the responsibility to segment the System Architecture into closely coupled groups of the functions.  Once the System Architect has a system architecture segmented, he or she will allocate the grouped functions as component requirements for a trade off study, using these requirements as the criteria for the trade.  Additionally, the architect will add any required design constraint requirements to the allocation.

The Enterprise Architect has a much different role and responsibilities, yet the skill set is built on those of the systems engineer and system architect.  Fundamentally, the first responsibility of the Enterprise Architect is enable and support the decision-making process enables and supports effective and cost efficient investments in tools and processes that optimally advance the mission of the organization to reach its vision; I call this the Mission Alignment process.  The second is to support the Governance and Policy Management processes to ensure that the organization's policies and standards enable and support the organization's mission alignment for achieving its mission, rather than inhibiting it from the achievement.

In this regard, for the Enterprise Architect, the Mission Alignment process produces the organization's requirements for performing activities to achieve its goal (the organization's performance requirements that are the analog of the system performance requirements for a project).  At the same time, for the Enterprise Architect, the policies and standards are the analog of the design constraint type requirements.  Consequently, the Enterprise Architect will use many of the same process patterns as the Systems Engineer--just applied to decision-making as opposed to transforming some portion of the architecture.

The post is an extension of a presentation I made at the 2009 SEI SATURN conference.

Creating the Enterprise Architecture Process and the AEAR

Currently, the implementation of an Enterprise Architecture process supporting IT and other investment decision-making, and supporting governance is difficult, at best.  There are two reasons for this. 

First, as discussed in an early post (Using Enterprise Architecture to Reduce the Federal Debt), changing organizational (governmental, and bureaucratic) culture is a slow painful process.  Any process that requires cultural change will create an enormous amount of organizational process friction (particularly from transactional management--the gatekeeper--managers that know the rules, enforce the rules, live by the rules, and thus do not like changes to the rules).  Additionally, it significantly limits the middle manager with a private agenda (the empire builder) to implement the private agenda.  Generally, this takes a champion, like the CEO of the organization to participate any change; then the middle managers will slow roll it.  Additionally, Subject Matter Experts may participate in this slow rolling, if they feel they will be out of a job, or if they feel they are in any other way threatened--Dr. Micheal Hammer speaks well to this overall topic.

Second, even if all of the cultural hurtles are overcome, the second reason for Enterprise Architecture losing any impact, is that Enterprise Architects feel the need for complete "as-is" architecture in the Asset and Enterprise Architecture Repository (AEAR) of the organization before they can start to use the process.  Consequently, they ask for large sums of money and years to create the repository.  The financial engineers of the organization and other looking for ways to cut the organization budget, look at this with jaundice eyes, as an appropriate cut, since there is no ROI apparent, only longer term VOI (Value On Investment).

However, there are ways to greatly reduce both the cost and time (to market) for creating the AEAR and ramping up the Enterprise Architecture process.  More on this in future posts

Types of Customer Requirements and the System Architecture Process

There are two types of customer requirements: functional and design constraints.

Functional requirements are the "must perform" requirements. 

• "The wing on an aircraft must provide 10 tons of lift when configured for takeoff." 
• "The refrigeration must keep food below 40 degrees, but above 32 degrees Fahrenheit."
• "The kitchen faucet must allow for convenient cleaning of large pots."

Design constraints are the "must meet" requirements. "

• "The USB port on the computer must meet the current USB port standards."
• "The application must have two factor authentication."
• "The electric motor must operate using standard 60 cycle, 110 volt current."

The System Architect decomposes the customer's functional requirements and derives the functions the tool or system needs.  Then structures and orders these functions into a System Architecture that may be called a functional design.  The System Architect subsequently allocates the tool's or system's functions to components.

However, the design constraints are not part of the system architecture.  Instead, the System Architect simply allocates these to the components at the time he or she allocation the functions.

Using this System Architecture process will greatly reduce the complexity of complex implementation and transformation efforts, which significantly reduces the probably of failure of the effort