CFO and CTO Versus CPO

The CFO and CTO

In this age, 1990 to 2020, the Chief Financial Officer (a financial engineer) is boss in most companies and corporations and the goal is "INCREASING STOCKHOLDER VALUE".  This includes everything from selling the company, to cooking the books, to reducing the wages, retirement, and benefits to the employee, to selling technology and knowledge to the Chinese.

In these companies and corporations, the CEO decides on a direction then asked the CFO if it is OK.  Twice I saw this for myself.  Once the CEO of a company I worked for decide to build a new plant.  This was short-term dumb, because it would reduce the next quarter's profit, but was long-term smart because the company would, and did, survive and thrive.  When the CFO said no, the CEO fired the CFO because the CEO was the son of the founder and owner.

In the second instance I saw the CFO reduce a major defense contractor from an integrated and high-morale team of over 50,000 to less than 25,000 demoralized  employees (where one Vice President call the employees "assets" that he could move or layoff at his discretion.  This was done so that the stockholders and management could make "windfall profits" when the company was sold. 

All of this weakens the economy of the nation and reduces the average worker's income, and shorten the life-span of the organization, because of the "economic lamprey eels" known as crony capitalists and day-traders.

While Chief Technology Officers don't have the political power of the Chief Financial Officers, but they too can wreck a company.  They do this by investing too much in some technologies and/or too little in others.

Frequently, they do this at the behest of the CEO, CFO, or VP of Marketing.  There are four reasons.  

First, because these individuals have read something or been to a conference of some product.  They insist that the product be used because they believe the advertising and they do not want to spend money on comparative evaluation. On several occasions, I've seen where this has led to total failure of the effort.

I've seen projects, with budgets in the tens of millions, fail due lack of requirements.  In several of these cases the supplier's of a particular product defined the requirements.  Surprise, their product was the only one to meet the requirements even though it didn't meet the users' needs and requirements.

Second, because the CFO or CTO has set a policy, including policies that require all units in a large organization to use the same tooling for different jobs or not use a tool, even though its the right tool for the job (project or program).  I had this happen to me.

In one case, I was part of a team that was using a new tool from IBM for building websites.  The tool required that we have a minimum of a 19" display to help us use the tool properly.  It took weeks before the team could get a waver to get the larger screens, then they magically disappeared on to the desks of the personnel that installed new systems.  Again, it took some doing before we had the displays we needed.

In the early and middle 1980s, I was innovating on data communications with expertise in Local Area Networks.  I had just finished leading a team that created a paperless shop floor factory system for improving its effectiveness and cost efficiency.  It used standardized protocols like 802.3 (Ethernet).  I created the shop floor network in less than 90 days that I was told was needed (otherwise I would get fired) and at half the budget allocated by IBM for the effort.  And it worked; the system won the Society of Manufacturing Engineers Lead award.

I then accepted employment at a major defense contractor of the time.  They too, were attempting to automate the shop floor of one of their factories.  They actually had employees on bicycles running around on the shop floor--they people were call expediters.  Again, I recommended the solution to the project manager.  However, the project manager decided it work because it didn't use the IBM tools and therefore it came from the wrong vendor.  One year and tens of millions of dollars later the project failed.  However, due to the next reason the project manager--a she--became a Vice President and the technical employees were RIFed.

The third reason CTOs fail is politics.  In all industries in the US, but particularly in government related industries in the US, politics always trumps competence.  Minority and female-owned businesses must always be given a percentage of the work, whether or not they are competent.  In several proposal efforts the personnel in the lab I led had to finish creating a concept demonstration in a few hours after these "firms" spent months not completing the job.

And they must fill a certain number of upper level positions whether or not they are competent.  I was interesting to me these female directors and VPs required an IT assistant to do their job as an IT VP.  This is the fourth reason CTOs fail, sheer incompetence.

One thing that these "politically correct" managers insisted on was that the technical team meet all of their foggy vague technical requirements with in a short period and on a preset budget.  After I attempted to refine the technical requirements I found that it would take twice the budget, that is a minimum of $20 million, as the $10 million could only meet about half their requirements in the time they specified.

When I recommended that we construct the system with an Initial Operating Capability (IOC) and then add components to meet the unmet requirements, they gave an unqualified NO!  They were asking for the equivalent of building a 10,000 sq. ft custom beachfront home in "the Hamptons" with an infinity pool and 4 car garage in 3 months for $100,000.  The project was predestined to fail.

For example, I recommended buying and installing a small computer system so that we could evaluate the new system.  It took from February until August to get the 33 thousand dollar system approved.  In the meantime the space allocated for it was taken up by other equipment and it sat outside for several months until space could be found. 

When we finally had a first version running, because of the bureaucratic gears grinding slowly and oh so finely I was told that we could not test the system because of the lateness; we had to meet the schedule.  No testing the system failed.

I could give many more examples of the failures of this type.  I could see these coming but didn't have the social or political skills to call a spade a pointy club.  Still finance engineering, politics, and social engineering wrecked many, many projects and programs.

A Chief Process Officer

However, there is a better way.  But it's one not taught in business colleges of Universities.  That's because it doesn't focus on finance, accounting, management, or marketing.  Instead, it focuses on the enterprise's economic engine and supporting infrastructure.   It's the organization process for creating value for its customers.

Typically, the business schools focus of the economic battery of the organization.  Think of a car's battery.  While it starts the engine it then provides the electricity that runs all of the accessories, from power windows to stereos and navigation systems--now even the accelerator pedal uses electricity.  The organization's economic battery is siphoned by the management and stockholders of the organization's profit, totally ignoring the economic engine--the company's processes and infrastructure.

If the organization had a Chief Process Officer (CPO) similar, but not identical to the Chief Operating Officer (COO), a job that has been eliminated by most companies to be replaced by the CFO.  The COO was responsible for the day to day operations of the organization's economic engine.  The job of the CPO would architect/design processes, standards, policies, tooling, and knowledge/training/talent to support the the vision, mission, or goal(s) of the organization as identified or defined by the CEO.

The CPO is responsible and accountable for:

• First, the processes to ensure that the organization's customer(s) get the product, system, or service that meets their requirements.
• Second, the standards and policies that enable and support the process.
• Third, the knowledge and talents required by the process.
• Fourth, the tooling and equipment needed for the process.

The staff of the CPO would include:

• The personnel officer accountable for hiring, training, or at worst contracting personnel with the required knowledge and/or talents required.
• The Chief Process Architect who is accountable for modeling the current and potential future process architecture.  The architect's team would include a number of systems engineers, technology specialists, and systems architects.
• The systems engineers would identify and manage the customer's requirements and design and process risks
• The technology specialist would identify and evaluate potential technological solutions.
• The systems/enterprise architects would model the current and future processes to determine if the current process(es), technologies, standards and policies can be made (first) more effective in meeting the customers requirements, and (second) more cost efficient.

• The Chief Financial Officer providing financial data to the modeling team.

With this organizational structure, the would provide better products, systems, or services to the customer and more cost efficiency for the organization,

Enterprise Portfolio Management and Enterprise Architecture Paper Available

I have added another paper to my list of papers.  This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-related.

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?

SOA, Cloud Computing, and Event and Model Driven Architecture

SOA and Cloud Computing, the Predicate to Model and Event Driven Architecture

In a recent post (see Functions Required in the Cloud PaaS Layer to Support SOA), I discussed two SOA patterns and two Cloud Computing patterns and showed how they are, in fact the same patterns applied to the SOA and the Cloud Computing domains.  For SOA, the concepts are Enterprise SOA (ESOA) and Ecosystem or Internet SOA (ISOA), while for Cloud Computing, the concepts are Private and Public Clouds. The correlation of these concepts is shown in Table 1.

	Ownership Domain		Integration Type		App. Layer Comm.
SOA	1 Dom	2+ Dom	Orchest.	Choreo.	ESB	Internet
ESOA	X		X		X
ISOA		X		X		X
Cloud
Private	X		X		X
Public		X		X		X
MAEDA
Model	X		X		X
Event		X		X		X

 Table 1

There are three attributes for both SOA and Cloud Computing shown in Table 1; Where the Services operate (the Ownership Domain variable), whether the service uses orchestration or choreography (Integration Type [see SOA Orchestration and Choreography Comparison]) and where the service components interact (The Application Layer Communications).  As the table demonstrates, on the dimensions shown, an ESOA is a model of the Software as a Service (SaaS) layer of the Private Cloud, while the ISOA is a model of the SaaS of the Public Cloud.  Consequently, SOA and Cloud Computing can be the same at the SaaS layer.  Since the SaaS drives most of the requirements for the Platform as a Service (PaaS [see Functions Required in the Cloud PaaS Layer to Support SOA]) and the Infrastructure as a Service (IaaS) layers, the results should be a nearly identical Technical Enterprise Architecture (or functional design) [Sidebar: but, perhaps with different labels to satisfy the purists, perhaps, "True Believers", in each camp].

Model and Event Driven Architecture

In a Part 3 of a four part paper, The Future of Information Technology: Enterprise Architecture 2006 to 2026, Part 3: Model and Event Driven Architecture (2008 to 2017), The Journal of Enterprise Architecture (February 2007), p. 28-39, I posit Model and Event Driven Architecture as an outgrowth of SOA.  This is an integration of Model Driven Architecture as espoused by the Object Management Group and a widely discussed, but somewhat nebulous Event Driven Architecture.
Model Driven Architecture and SOA
The current concept of Model Driven Architecture (MDA) starts from IT functional requirements, as modeled in UML diagrams and ends up with a complete application to roll into production.  With respect to SOA, using MDA would mean that the software developers create the Service Components using MDA and assemble these components into a Composite Application using orchestration based on MDA.  In fact, modeling the assembly of the composite application is a quick way to spot both coding and system functional design defects.

However, in a broader interpretation of MDA, implementers of new systems, application, and/or services could start with Business Process Modeling to identify business process requirements and functions and use these to derive the IT functions.  This enables the Systems Engineer and System Architect to capture more complete requirements and trace the IT functions to the business or organizational functions they support.  This modeling concept better fulfills the process envisioned for SOA, than merely using MDA to create the composite applications.  Now the services are traceable to the business or organizational processes and functions; which means that when the process changes, the effects on the composite application can be modeled and the composite application is more easily updated to enable and support the new process or function.

Event Driven Architecture and SOA

Event Driven Architecture (EDA) focuses on creating agile software, that is, software that can successfully react to external stimuli in a timely manner.  To perform this mission an EDA must be able to dynamically change both the functions it performs and the ordering of these functions in response to the stimulus.  This function falls along the branching logic dimension, which at one extreme is the simply "IF" statement and at the other is Artificial Intelligence (AI).  Obviously, the concepts from Knowledge Management (KM) can come into play with the functions along this dimension.  The key to EDA is determining what really constitutes an event.  This requires Complex Event Processing (CEP).  In terms of the OODA Loop, CEP constitutes the OO portion ("Observe" and "Orient").

Actually, EDA can support three of the four functions of the OODA based on the concept of types of "event" rules.  There are three type are Knowledge Rules, Event Rules, and Value Rules.  A knowledge rule supports the Observe function of the OODA loop.  A Knowledge Rule

An event rule supports the Orient function of the OODA loop. Several measurements may predict an Event.  An Event Rule is a codification or formalization of this grouping and ordering of the measurements within a confidence interval.  For example, in the 1920s the prediction of a hurricane forming was decidedly hit or miss (a very wide confidence interval).  Today, hurricane and tornado predictions are much more valid (a much smaller confidence interval); in fact, there are possibilities for predicting earthquakes and Tsunamis.

In many cases, it is not a single event that causes a major or catastrophic problem or issue, but an event chain.  This has been found in the vast majority of recent aircraft accidences.  Understanding these event chains is CEP.  Another example is that now, the weather service not only predict that a tropical storm or hurricane will occur, but also identify where it will make landfall, and or if it will make landfall.  These two events, "there is a hurricane", and its "coming our way" are part of the event chain that determine whether, "we'll sit this one out", or "it's time to leave".  To decide requires the decision-maker to understand the risks and rewards of the choice.

A value rule supports the decision-maker in the Decide function of the OODA loop.  A value rule determines the value to the organization of alternatives when an event or event chain has occurred.  In the case of the hurricane, the decision-maker makes the decision-based on the events, and value of staying versus leaving.  One well known example of value rules comes from Isaac Asimov.  The three value rules for robotics are:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

While the knowledge rules are state attributes and change of state attribute, the events create decision points in the process.  With SOA, the orchestration or choreography engines use the processes flows from the assembly process plus the rules, based on the governance, to enable the process flow among the functions (service components) of the composite application.  If the SOA is the Ecosystem SOA (public cloud), then the composite application uses choreography to dynamically interlink the service components [Sidebar: In a web services type of application, these service components are the web services.]  Choreography enables the application to choose which function or service component to use next anywhere on the Internet.  By coupling the choreography repository and engine with a organizational rules repository, and CEP rules repository and engine, the composite application can dynamically link to any appropriate service component that is available that, according to its combined rules will produce the best outcome.  The down side to this is that, first, as the number of alternates increases, the composite application will slow down, and second, the composite application may become much more stochastic than would normally be expected or useful.

Model and Event Driven Architecture and Enterprise Architecture

Model and Event Driven Architecture is an amalgamation of Model and Event Driven Architecture, and in such an alloy increases the speed of the composite application, while reducing the risk that the application may become stochastic.  At the same time, the composite application is much more agile than that built using MDA.

The cost of this amalgamation is in terms of the complexity of the combined orchestration/ choreography/CEP engine (functionality) and the leadership and management discipline needed to ensure that the governance and "event" rules are enabling and supporting the organization's vision and mission, and that they are as internally consistent as possible--that is, a minimum number of "catch 22s".  This will require the a person with the role and responsibilities of an Enterprise Architect, as well as those of Systems Engineer and System Architect.

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.

Systems Engineering, Product/System/Service Implementing, and Program Management

A Pattern for Development and Transformation Efforts

Recently a discussion started in a LinkedIn Group that recruiters, HR, and Management was using the term "Systems Engineer" indiscriminately.   The conclusion was that the discipline of Systems Engineering and the role of the Systems Engineer in Development and Transformation Efforts is poorly understood by most people, and perhaps by many claiming to be Systems Engineers.  In my experience of building a Systems Engineer group from 5 to 55, I can attest to this conclusion.

Currently, I am working on a second book, with the working title of "Systems Engineering, System Architecture, and Enterprise Architecture".  In the book, I'm attempting to distill 45+ years of experience and observation of many efforts, from minor report revisions to the Lunar Module, F-14, B-2, and X-29 aircraft creation efforts, to statewide IT outsourcing efforts.  This post contains excerpts of several concepts from this manuscript.

The Archetypal Pattern for Product/System/Service Development and Transformation

At a high level there is an architectural process pattern for Product/System/Service development and transformation.  I discuss this pattern in my current book, Organizational Economics: The Formation of Wealth, and it is one key pattern for my next book.  This pattern is shown in Figure 1.

Figure 1--The Three Legged Stool Pattern



As shown in Figure 1, the architectural process model posits that all development and transformation efforts are based on the interactions of three functions (or sub-processes), Systems Engineering, Design and Implementation, and Program Management.  This is true whether a homeowner is replacing a kitchen faucet or NASA is building a new spacecraft.  Each of these sub-processes is a role with a given set of skills.

Consequently, as shown in Figure 1, I call this process pattern "The Three-legged Stool" pattern for development and transformation.  I will discuss each sub-process as a role with requirements.  Therefore, this is what I see as the needs or requirements for the process and the skills for the role.  In my next book, I will discuss more about how these can be done.

As shown in Figure 1, the program management role is to enable and support the other two roles with financial resources and expect results, in the form of a product/system/service meeting the customer's requirements.

Systems Engineering (and System Architecture) Role

The first role is the Systems Engineer/System Architect.  This role works with the customer to determine the requirements--"what is needed."  I've discussed this role in several posts including Enterprise Architecture and System Architecture and The Definition of the Disciplines of Systems Engineering.  Three key functions of this sub-process are:

• Requirements Identification, Management, and Verification/Validation (see various other posts as well)
• Risk Management
• Configuration Management

These are the key responsibilities for the role, though from the posts, cited above, "The devil (and complexity of these) is in the detail".

The key issue with the Systems Engineering/System Architect role within a project/program/effort is that the requirements analysis procedure becomes analysis paralysis.  That is, the Systems Engineer (at least within the "waterfall" style effort, that assumes that all of the requirements are known upfront) will spend an inordinate amount of time "requirements gathering"; holding the effort up, to attempt to insure that all of the requirements are "know"--which is patently impossible.

 I will discuss solutions to this issue in the last two sections of this post.

Design and Implementation Role

When compared with Systems Engineering, the Design and Implementation functions, procedures, methods, and role are very well understood, taught, trained, and supported with tooling.  This role determines "How to meet the customer's needs", as expressed in the "What is needed (requirements)", as shown in Figure 1.  These are the product/system/service designer, developers, and implementers of the transformation; the Subject Matter Experts (SMEs) that actually create and implement.  These skills are taught in Community Colleges, Colleges, Universities, Trade Schools, and on-line classes.  The key sub-processes, procedures, functions, and methods are as varied as the departments in the various institutions of higher learning just mentioned.

There is a significant issue with designers and implementers, they attempt to create the "best" product ever and go into a never ending set of design cycles.  Like the Systems Engineering "analysis paralysis", this burns budget and time without producing a deliverable for the customer.  One part of this problem is that the SMEs too often forget is that they are developing or transforming against as set of requirements (The "What's Needed").  In the hundreds of small, medium, and large efforts in which I've been involved, I would say that the overwhelming percentage of time, the SMEs never read the customer's requirements because they understand the process, procedure, function, or method far better than the customer.  Therefore, they implement a product/system/service that does not do what the customer wants, but does do many functions that the customer does not want.  Then the defect management process takes over to rectify these two; which blows the budget and schedule entirely, while making the customer unhappy, to say the least. The second part of this problem is that each SME role is convinced that their role is key to the effort.  Consequently, they develop their portion to maximize its internal efficiency while completely neglecting the effectiveness of the product/system/service.  While I may be overstating this part somewhat, at least half the time, I've seen efforts where, security for example, attempts to create the equivalent of "write only memory"; the data on it can never be used because the memory cannot be read from.  This too, burns budget and schedule while adding no value.

Again, I will discuss solutions to this issue in the last two sections of this post.

Program Management Role

As shown in Figure 1, the role, procedures, and methods of Program Management is to support and facilitate Systems Engineering and Design and Implementation roles.   This is called Leadership.   An excellent definition of leadership is attributed to Lao Tzu, the Chinese philosopher of approximately 2500 years ago.  As I quoted in my book, Organizational Economics: The Formation of Wealth:

• "The best of all leaders is the one who helps people so that, eventually, they don’t need him.
• Then comes the one they love and admire.
• Then comes the one they fear.
• The worst is the one who lets people push him around.

Where there is no trust, people will act in bad faith.  The best leader doesn’t say much, but what he says carries weight.  When he is finished with his work, the people say, “It happened naturally"."[1]

[1] Lao Tzu, This quote is attributed to Lao Tzu, but no source of the quote has been discovered.

If the program manager does his or her job correctly, they should never be visible to the customer or suppliers; instead they should be the conductor and coordinator of resources for the effort.  Too often the project and program managers forget that this is their role and what the best type of leader is. Instead, they consider themselves as the only person responsible for the success of the effort and "in control" of the effort.  The method for this control is to manage the customer's programmatic requirements (the financial resources and schedule).  This is the the way it works today.

The Way This Works Today: The Program Management Control Pattern

There are two ways to resolve the "requirements analysis paralysis" and the "design the best" issues, either by the Program Manager resolving it, or through the use of a process that is designed to move the effort around these two landmines.

The first way is to give control of the effort to manager.  This is the "traditional" approach and the way most organization's run development and transformation efforts .  The effort's manager manages the customer's programmatic requirements, (budget and schedule), so the manager plans out the effort including its schedule.  This project plan is based on "the requirements", most often plan includes "requirements analysis".

[Rant 1, sorry about this: My question has always been, "How is it possible to plan a project based on requirements when the first task is to analyze the requirements to determine the real requirements?"  AND, I have seen major efforts (hundreds of millions to billions) which had no real requirements identified...Huh?]

The Program or Project Manager tells the Systems Engineer and Developer/Implementer when each task is complete; because that's when the time and or money for that task on the schedule is done, regardless of the quality of the work products from the task.  "Good" managers keep a "management reserve" in case things don't go as planned.  Often, if nothing is going as planned, the manager's knee jerk reaction is to "replan"; which means creating an inch-stone schedule.  I've seen and been involved in large efforts where the next level of detail would be to schedule "bathroom breaks".  This method for resolution of "analysis paralysis" and "design the best" will almost inevitably cause cost and schedule overruns, unhappy customers, and defective products because the effort's control function to control costs and schedules.

The Program Management Control Pattern
Figure 2 shows the Program Management Control Pattern.  The size of the elipse shows the percieved importance of each of the three roles.



Figure 2--The Program Management Control Pattern



First, the entire "Three Legged Stool" Pattern is turned upside down is the Program Management Control Pattern.  Rather than the Program Manager enabling and supporting the development process by understanding and supporting the development or transformation process, the Program Manager "controls" the process.  In Lao Tzu leadership taxonomy, this process pattern makes the Program Manager one of the latter increasingly ineffective types.  It also reverses importance of who produces the value in the effort.

To be able to "Control" the effort, the Program Manager requires many intermediate artifacts, schedules, budgets, and status reports, which use up the resources of the efforts and  are non-valued work products, the customer might look at these artifacts once during a PMR, PDR, CDR, or other "XDR" (Rant 2: Calling these review Program Management Reviews, instead of some type of Design Review", Preliminary, Critical, etc., demonstrates the overwhelming perceived importance of the programmatic requirements by Program Managers.)  I submit that all of these intermediate artifacts are non-value added because 3 months after the effort is completed, the customer or anyone else will not look at any of them except if the customer is suing the the development or transformation organization over the poor quality of the product.  All of these management reviews require resources from the Developers/Implementers and the Systems Engineers.

One extreme example of this management review procedure was the procedures used in development of new aircraft for the US Air Force and Navy during the 1980s and 90s--sometimes facts are stranger than fantasy.  The DoD required some type of "Development Review" every 3 months.  Typically, these were week-long reviews with a large customer team descending on the aircraft's Prime Contractor.  Program Management (perhaps, rightly) considered these of ultimate importance to keeping the contract and therefore wanted everyone ready.  Consequently, all hands on the effort stopped work 2 weeks prior to work on status reports and presentation rehearsals.  Then, after the "review" all hands would spend most of an additional week reviewing the customer's feedback and trying to replan the effort to resolve issues and reduce risk.  If you add this up, the team was spending 1 month in every 3 on status reporting.  And I have been part of information technology efforts, in this day of instant access to everything on a project where essentially the same thing is happening.  Think about it, these aircraft programs spent one third of their budget, and lengthened the programs by 1/3 just for status for what?  Intermediate artifacts of no persistent value--Who looked at the presentations of the first Preliminary Design Review after the aircraft was put into operations?  [Rant 3: Did the American citizen get value for the investment or was this just another Program Management Entitlement Program funded by the DoD?]

Second, as shown in Figure 2, the Systems Engineering role is substantially reduced  in the perception of the Program Manager.  An example of this was brought home to me on a multi-billion program, when I asked the chief engineer where the requirements were stored, he quoted the Program's Director as saying, "We don't need no damn requirements, we're too busy doing the work."  This Director underlined this thinking; he kept hiring more program management, schedule planners, earned value analysts, and so on, while continuous reducing then eliminating the entire Systems Engineering team and leaving only a few System Architects.  He justified this by the need to increased control and cost reduction to meet his budget [Rant 4: and therefore to get his "management bonus"--no one ever heard of the Design or a System Engineering Bonus].  Actually, I've seen this strategy put into play on large (more than $20M) three programs with which I was associated and I've heard about it on several more within the organization I was work for and in other organizations, over the past 10 years.  

Another program that I worked on as the Lead Systems Engineer that had the same perception of the Systems Engineer (including the System Architect's role within the Systems Engineering discipline/role).  It is an extreme example of all that can go wrong because of lack of Systems Engineering.  This effort was development of a portal capability for the organization.  It started with a that had 10 management personnel and myself.  They articulated a series of ill-thought-out capability statements, continued by defining a series products that had to be used (with no not identification of Customer System or IT Functional requirements), with a 6 weeks schedule, and ended with a  budget that was 50 percent of what even the most optimistic budgeteers could "guessitmate".  They (the three or four levels of management represented at the meeting) charged me with the equivalent of "Making bricks without straw or mud in the dark", that is, creating the portal.  Otherwise, my chances of getting on the Reduction In Force (RIF) list would be drastically increased.

Given that charge, I immediately contacted the software supplier and the development team members from two successful efforts within the organization to determine if there was any hope of the effort within the programmatic constraints to accomplish the task.  All three agreed, it could not be done in less than 6 months.  Faced with this overwhelming and documented evidence, they asked me what can be done.  The result was based on their "capability" statements, and "Requirements (?)" documents from the other two projects, I was able to cobble together a System Architecture Document (SAD) that these managers could point to as visible progress.  Additionally, I used a home grown risk tool to document risks as I bumped into them.  Additionally, I instituted a risk watch list report on a weekly basis, which all the managers ignored.

At this point one fiscal year ended and with the new year, I was able to have the whole, nationwide, team get together, in part, to get everyones requirements and design constraints.  Additionally, I presented an implementation plan for the capabilities I understood they needed.  This plan included segmenting the functions for an IOC build in May, followed by several additional several additional builds.  Since this management team was used to the waterfall development process, the rejected this with no consideration; they wanted it all by May 15th.  In turn, I gave them a plan for producing, more or less, an acceptable number of functions, and an associated risk report with a large number of high probability/catastrophic impact risks.  They accepted the plan.  The plan failed; here is an example of why.

One of the risks was getting the hardware for the staging and production systems in by March 15th.  I submitted the Bill of Materials (BOM) to the PM the first week in February.  The suppliers of the hardware that I recommended indicated that the hardware would be shipped within 7 days of the time the order was received.  When I handed the BOM to the PM, I also indicated the risk if we didn't get the systems by March 15th.  On March 1st, I told him that we would have a day for day slippage in the schedule for every day we didn't receive the hardware.  The long and the short of it was that I was called on the carpet for a wire brushing on July 28th when we had the program held up because of lack of hardware.  Since I could show the high-level manager that, in fact, I had reported the risk (then issue) week after week in the risk report she received, her ire finally turned on the PM, who felt he had the responsibility.

The net result of these and several other risks induced either by lack of requirements or lack of paying attention to risks resulted in a system that was ready for staging the following December.  Management took it upon themselves to roll the portal into production without the verification and validation testing.  The final result was a total failure of the effort due to management issues coming from near the top of the management pyramid.  Again, this was due to a complete lack of understanding of the role of Systems Engineering and Architecture.  In fact, this is a minor sample of the errors and issues--maybe I will write a post on this entire effort as an example of what not to do.

In fact the DoD has acknowledged the pattern shown in Figure 2 and countered it by creating System Engineering Technical Advisory (SETA) contracts.

The Utility of Program Management

[Rant 5: Here's where I become a Heritic to many, for my out of the warehouse thinking.]  In the extreme, or so it may seem it is possible that projects don't need a project manager.  I don't consider that a rant because it is a fact.  Here are two questions that makes the point.  "Can an excellent PM with a team of poorly skilled Subject Matter Experts (SMEs) create a top notch product?" and  "Can a poor PM with a team of excellent SMEs create a top notch product?"  The answer to the first is "Only with an exceptional amount of luck", while the answer to the second is "Yes! Unless the PM creates too much inter-team friction."  In other words, except for reducing inter-team friction, which uses resources unproductively, and for guiding and facilitating the use of resources, the PM produces no value, in fact, the PM creates no value, just reduces friction, which preserves value and potential value.

None of the latter three types of leaders, as described by Lao Tzu, can perform perform this service to the team, the ones I call in my book, the Charismatic, the Dictator, or the Incompetent. In other words, the PM can't say and act as if "The floggings will continue until morale improves".

Instead, the PM must be a leader of the first type as described by Lao Tzu and as I called in my book as "the coach or conductor".  And any team member can be that leader.  As a Lead Developer and as a Systems Engineer, I've run medium sized projects without a program manager and been highly successful--success in this case being measured by bringing the effort in under cost, ahead of schedule, while meeting or exceeding the customers requirements  Yet, on those none of the programs, for which I was the lead systems engineer and which had a program manager and who's mission was to bring in the effort on time and within budget, was successful.  On the other hand, I've been on two programs where the PM listened with his/her ears rather than his/her month and both paid attention to the System Requirements; those efforts were highly successful.

The net of this is that a coaching/conducting PM can make a good team better, but cannot make a bad team good, while a PM in creating better projects plans, producing better and more frequent status reports, and creating and managing to more detailed schedules will always burn budget and push the schedule to the right.

A Short Cycle Process: The Way It Could and Should Work

As noted near the start of this post, there are two ways to resolve the "requirements analysis paralysis" and the "design the best" issues, either by Program Management Control, or through the use of a process that is designed to move the effort around these two landmines.

This second solution uses a development or transformation process that assumes that "Not all requirements are known upfront".  This single change of assumption makes all the difference.  The development and transformation process must, by necessity, take this assumption into account (see my post The Generalize Agile Development and Implementation Process for Software and Hardware for an outline of such a process).  This takes the pressure off the customer and Systems Engineer to determine all of the requirements upfront and the Developer/Implementer to "design the best" product initially.  That is, since not all of the requirements are assumed to be known upfront, the Systems Engineer can document and have the customer sign off on an initial set of known requirements early in the process (within the first couple of weeks), with the expectation that more requirements will be identified by the customer during the process.  The Developer/Implementer can start to design and implement the new product/system/service based on these requirements with the understanding that as the customer and Systems Engineer identify and prioritize more the of the customer's real system requirements.  Therefore, they don't have to worry about designing the "best" the first time; simply because they realize that without all the requirements, they can't.

 

Changing this single assumption has additional consequences for Program Management.  First, there is really no way to plan and schedule the effort; the assumption that not all the requirements are known upfront means that if a PM attempts to "plan and schedule" the effort is an "exercise in futility."  What I mean by that is if the requirements change at the end/start of the new cycle, then the value of a schedule of more than the length of one cycle is zero because at the end of the cycle the plan and schedule, by definition of the process, change.  With the RAD process I created, this was the most culturally difficult issue I faced with getting PM and management to understand and accept.  In fact, a year after I moved to a new position, the process team imposed a schedule on the process.

Second, the assumptions forces the programmatic effort into a Level Of Effort (LOE) type of budgeting and scheduling procedure.  Since there is no way to know what requirements are going to be the customer's highest priority in succeeding cycles, the Program Manager, together with the team must assess the LOE to meet each of the requirements from the highest priority down.  They would do this by assessing the complexity of the requirement and the level of risk with creating the solution that meets the requirement.  As soon as the team runs out of resources forecast for that cycle, they have reached the cutoff point for that cycle.  They would present the set to the customer for the customer's concurrence.  Once they have customer sign off, they would start the cycle.  Sometimes a single Use Case-based requirement with its design constraints will require more resources than are available to the team during one cycle.  In that case, the team, not the PM, must refactor the requirement. 

For example, suppose there is a mathematically complex transaction, within a knowledge-based management system, which requires an additional level of access control, new hardware, new COTS software, new networking capablities, new inputs and input feeds, new graphics and displays, and transformed reporting.  This is definitely sufficiently complex that no matter how many high quality designers, developers, and implementers you up on the effort, it cannot be completed within one to perhaps even three months (This is  the "9 women can't make a baby in a month" principle).  Then the team must refactor (divide up) the requirement into chunks that are doable by the team within the cycle's period, say one to three months.  For example, the first cycle might define and delimit the hardware required and develop the new level of access control; and so on for the number of cycles needed to meet the requirement.

Third, with this assumption of "not having all the requirements", the PM must pay most attention to the requirements, their verification and validation, and to risk reduction.  All of these functions lay within the responsibility of the Systems Engineer; but the PM must pay attention to them to help best allocate the budget and time resources.

Fourth, there is no real need for PMRs, status reports, or Earned Value metrics.  The reason is simple, high customer involvement.  The customer must review the progress of the effort every month at a minimum, generally every week.  This review is given by the developers demonstrating the functions of the product, system, or service on which they are working.  And if the customer is always reviewing the actual development work, why is there a need for status, especially for an LOE effort?

Fifth, rolling a new system or service has significant implications for the customer.for the timing and size of the ROI for the development or transformation effort.  With an IOC product, system, or service, the customer can start to use it and in using the IOC will be able to, at a minimum, identify missing requirements.  In some cases, much more.  For example, in one effort, in which I performed the systems engineering role, during the first cycle the team created the access control system and the data input functions for a transactional website.  During the second cycle, the customer inserted data into the data store for the system.  While doing this, the customer discovered sufficient errors in the data to pay for the effort.  Consequently, they were delighted with the system and were able to fund additional functionality, further improving their productivity.  If the effort had been based on the waterfall, the customer would have had to wait until the entire effort was complete, may not have been as satisfied with the final product (more design defects because of unknown requirements), would not have discovered the errors, and therefore, would not have funded an extension to the effort.  So it turned out for a win for the customer-- more functionality and greater productivity--and for the supply--more work.

In using a short cycle process based on assuming "unknown requirements", there will always be unfulfilled customer system requirements at the end of this type of development or transformation process.  This is OK.  It's OK for the customer because the development or transformation team spent the available budgetary and time requirements in creating a product, system, or service that meets the customer's highest priority requirements, even if those requirements were not initially identified; that is, the customer "got the biggest bang for the buck".  It's OK for the team because a delighted customer tends to work hard at getting funding for the additional system requirements.  When such a process is used in a highly disciplined manner, the customer invariably comes up with additional funding.  This has been my experience on over 50 projects with which I was associated, and many others that were reported to me as Lead Systems Engineer for a Large IT organization.

Conclusions and Opinions

The following are my conclusions on this topic:

1. If a development or transformation effort focuses on meeting the customer's system requirements, the effort has a much better chance of success than if the focus is on meeting the programmatic requirements.
2. If the single fundamental assumption is changed from "All the requirements are known up front" to "Not all the requirements are known up front" the effort has the opportunity to be successful or much more successful by the only metric that counts, the customer is getting more of what he or she wants, and that increases customer satisfaction.
3. If the development or transformation effort can roll out small increments will increase the customer's ROI for the product, system, or service.
4. Having a Program Manager, who's only independent responsibility is managing resources be accountable for an effort is like having the CEO of an organization report to the CFO; you get cost efficient, but not effective products, systems, or services.  [Final Rant: I know good PMs have value, but if a team works, that is because the PM is a leader of the first type: a coach and conductor.] Having a Program Manager that understands the "three legged stool" pattern for development or transformation, and who executes to it will greatly enhance the chance for success of the effort.