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.