Regulations: The “Must Meet” Requirements
Regulations directly affect all organizations, products,
systems, and services. Further, they can be a rudder guiding the organization
or a brake causing the organization to stop making any progress in meeting its
charter, goal, or in completing its mission.
This post discusses laws, rules, specifications, standard, regulations
(or simply regulations) as a part of any enterprise architecture or systems
engineering effort.
The Customer Requirements Identification and Management tool
that I’ve developed, CARRMA®, uses the concept of Must Meet
requirements to store both the regulations and the metrics for meeting the
regulation. If more than one project has
a particular regulation imposed on it, the CARRMA®’s data store will
allow for reuse.
Regulations the rudders of an organization
Any commandment, law, rule, specification, standard, or
regulation creates process friction, by its very nature. It inhibits
what can be done or defines what
must be done. For example, saying “Thou Shall not Kill” means that it’s not
nice to end a vehemently intense discussion by bouncing your opponent “six feet
under”, though that might be very satisfying at the moment. That is, killing is not a good solution to an
intra-group disagreement since it doesn’t promote understanding, knowledge and
therefore value growth of the group and doesn’t instill trust with other
groups.
Hoping that I’ve made the point that regulations curb action or ensure action, by an over-the-top
example, a regulation acts like a rudder, making it difficult for a process and
thus a strategy to go one way, thereby making it easier to go another. This, in turn, may directly affect the organization’s
charter, mission, or goal. In any
rational system it should enable both the charter/mission/goal and the
strategies and processes for achieving these.
Fortunately or more importantly, unfortunately systems and
organizations built by humans are not entirely rational and sometimes not rational
at all. If the economy is the engine that
powers the ship-of-state in an organization, then each commandment, law, rule,
specification, standard, or regulation enacted is a rudder with its own wheel
guided by part of the crew steering the organization toward their own Avalon.
Arrow’s Paradox and Catch 22s
At some point the number of rudders pointing at all points
of the compass are such that the organization be it private or a ship-of-state
either comes to a complete halt or turns in tight circles. The rudders have formed a damn that effectively
stops all forward progress of the organization, which no amount of churning by
the organization’s economic engine can overcome. Some of these regulation rudders are small
and some are very large. Twist the large
ones hard and the ship brakes to a crawl and it may not turn at all.
Arrow’s Paradox
A bigger problem is that too many regulation rudders will
simply cause the organizational ship to stop and not make any of the
ports. Dr. Kenneth Arrow’s is known for “Arrow’s
Impossibility Theorem” [Sidebar: For which he won
the Nobel Prize], which is also known as Arrow’s Paradox. He demonstrated mathematically that if an
organization has three or more goals that they want to optimize, they will be
able to only optimize on two (or I suspect they can sub-optimize on all three).
The point here isn’t that organizations can’t have more than
one goal or objective; it is that if the organization attempts to define more
than two (or maybe three) objectives using the “policy/regulation” strategy,
the organization will slow down, wobble around, and achieve none of the
objectives.
If you add in that in a democracy the goals and objectives
change as controlling constituencies change, normally you end up with more and
more laws, regulations, rules, and standards each attempting to use its
regulatory rudder to change the course of the ship-of-state to reach the objective
for which it was enacted. The net result
is that either the ship-of-state will end up on the rocks or going in circles.
From personal experience with federal contracts and from a
recent DoD report, I can illustrate the problem. One goal, which probably should be the only
goal of DoD contracting, is to provide the most effective weapons in the world
for the US Military. That is, the
weapons should be the greatest force multiplier.
However, the contracting office is faced with a second
objective (a second rudder) of acquiring these weapons cost efficiently. There are two metrics for cost efficiency,
the initial cost (including research, development, and construction), and
life-cycle costs (maintenance, upgrades, and disposal). The question for the contracting officer is, “Do
you contract for the cheapest initial cost product or for the one that will
cost the least over the product’s projected lifespan?”
Then there is a third rudder in the form of the dependability
of the product, system, or service. “Dependability encompasses all of the “illities”,
including reliability, maintainability, serviceability, and so on. Each of these has metrics and standards that
must be met. In some cases the metrics
for the standard or policy is either untestable in a timely manner or in a few
infeasible or impossible to meet. All of
these rudders will force addition time and expense into the effort.
A fourth rudder is reconfigurability and upgradeability of
the product, system, or service. Before
the US Civil War, the rate of change of weapons and support systems was such
that weapons and weapons systems had no need for this “Must Meet”
requirement/policy. The weapon would be worn
out long be the technology changed.
However, since then it’s obvious that technology has and is continuing
to accelerate (to the point that for many systems, they must be upgraded before
their development and implementation is completed). These continue to increase the initial design
costs. [Sidebar: Services Oriented Architecture can
reduce these costs greatly for IT systems, and modular systems/product can do
the same for hardware of all types.]
A fifth rudder, and first one that is politically/social motivated
as well as costly is the implied policy that all congressional districts and
states should have jobs related to weapons and intelligence system development,
especially where the senator or representative sits on committees dealing with
budgets and military programs. A recent
DoD study has shown that this can add 20 to 25 percent to the cost of a
product, system, or service for the DoD.
Then comes the politically motivated socially liberal
welfare policy rudders (those intended to regulate social welfare and social
change). For weapons and intelligence
tools, these require that a certain percent of the work on the product be from female
owned companies and another percentage be from “minority” owned businesses. [Sidebar: The social actives’ idea was that the only
way these groups could break into DoD contracting was through regulation. I think they were correct because most of the
work they did that I observed over the 25 years I was associate with government
contracted engineering demonstrated beyond a doubt that they were incompetent
to compete with a level playing field. Many
times the prime contractor had to supply the engineering capability to complete
the job over schedule and way over cost.] While it isn’t Politically Correct to attempt
to define how much money was spent on this contracting welfare, from personal
experience I expect that it is very significant.
The point of this section is not to discuss the problems
with the regulations and informal policies of DoD contracting, rather it’s to
demonstrate that as more laws, policies, regulations, business rules, standards,
and so on (the “Must Meet” requirements) are imposed on a program, especially,
extraneous ones, that both the effectiveness of product and the cost efficiency
of the project or program are reduced.
And at some point there are so many “Must Meet” requirements that the
effort, even at the enterprise architectural level will fail.
Catch-22
The extreme case of Arrow’s Paradox is the famous Catch-22
where two regulations are diametrically opposed leaving whatever effort, project,
program, organization, or enterprise going in circles and making no progress in
any direction. Even with a ship-of-state the size of the United States (which
is a supertanker sized economy), given enough Catch-22s and nothing will get
done; too many steersmen, too many rudders, and too many goals (targets,
harbors, or whatever).
A good current and everyday example of regulatory Catch-22
is deicing roads. Having icy sidewalks
can be very exciting and occasionally lethal—so it really is not a good thing. So deicing the sidewalks is mandatory. Deicing calls for the use chemicals like sodium
chloride (salt).
The problem is that there are regulations (must meet)
requirements for the use and storage of “salt” because it “pollutes the
environment” (and it does, you should see my grass near the sidewalk and road). So you must use chemicals to save lives but
you must not to save the environment.
Two regulatory “must meet” requirements (rudders) are in opposition, one
to save lives and one to save the environment.
This is a small example of a big problem that can and will bring the
economic ship-of-state to a dead stop.
Reducing the Number of Regulatory Brakes but Keeping the Rudders
To get any organization to at least head to a goal it should
be clear that removing internal policies that interfere with the attainment of
the goal is necessary. For large
organizations with many sub-organizations, the issue becomes one of identifying
which regulations guide the organization in the direction its charter, goal, or
mission state and which are braking it to a stop. For many organizations, but especially
democratic style governments, there will always conflicting goals and missions
and therefore conflicting regulations.
So how should a large organization or government determine which are
rudders and which are brakes?
To my mind, this is a good place to apply Enterprise
Architecture and the architectural model that I set out both in my book and in
this blog. The nice thing about that
architectural model is that it can start as a static model that can be used to
identify customer requirements and end up as a dynamic model of the enterprise
(even the Ship-of-State). As such, it
can identify policies that are braking or causing bottlenecks in the processes
enabling the strategies for attaining the goal or mission. Until you can dynamically model the enterprise,
you will never really be able to identify the unintended consequences and
negative externalities of any policy, standard, or regulation. Nor, as the goal or mission changes can you
identify those policies, standards, or regulations that truly impede progress
in the changed direction (though many politicians in the organization will be
able to tell you, or so they believe).
For those policies and standards internal to the
organization, the leadership should be able to understand which regulations support
the organization’s strategies and process and which don’t. Additionally, the leadership can propose
changes, deletions, and new regulations, which the enterprise architect can
then model to determine the likely consequences, both intended and unintended. Once the enterprise architects have oriented
the changes the leadership proposes [Sidebar: See
the OODA loop] the leadership can then choose what internal policies,
standards, and regulations to change and which changes to implement with a much
lower risk while seeing the their organization move more quickly toward achieving
its goal. [Sidebar:
The modeling will also show where leaders and managers of sub-units are working
on their own agenda which might or might not be steering toward the overall goal. Remember the Systems Engineering axiom, “Optimizing
the sub-systems sub-optimizes the system.”]
For governments, especially for the legislative branch, architectural
modeling is particularly important both to determine conflicting laws,
regulations, rules, standards and codes.
If, as the architectural models mature and their predictions help to
make better decisions, there may even be fewer vehemently intense discussions
about which laws, regulations, rules, standards, and codes to enact and which
to remove or rewrite…Interesting.
No comments:
Post a Comment