Like all great products, the foundation of profitability isn’t so much in the business arrangements as it is in the engineering–and how engineering is done crucially affects its quality.  For OTs the key is RAD-B:  Requirements Requirements, Architecture, Design, and Baselines.  We can show your team how to make these more than cost-effective–your team can make them the basis of project financial success.

Requirements

Requirements are the key to financial viability of an OT:  They explicitly state what the contractor is “signing up for”—and the System Requirements Review (SRR) is a venue tailor-made to come to formal agreement with the customer on what was only vaguely stated in the solicitation or awarded OT.  Better yet, this agreed-on set of requirements serves as the baseline for the inevitable changes to come, and negotiations as needed on contract modifications to support them.

Architecture

Architecture is the key to pricing, to planning, to design, to integration, and to maintainability.  Putting some forethought into it will pay off many times over.

Pricing:  Which is easier:  Pricing one huge system, or a series of small, well-defined ones?   Clearly, the latter.  It’s not only easier, it’s more reliable (since we’re not taxing the mental scope of SMEs nearly so much) and (given a reasonable SE model implementation) directly traceable to those requirements we spent so much time building.  “Why does it cost what it does?”  With a good architecture as a foundation, you’ll know.

Planning:  A good, comprehensible architecture makes it easy for PMs and systems engineers to visualize the scheduling of the project and to successively refine the definition, implementation, integration, and verification and validation of the respective components.  Good architecture feeds good planning, and vice versa.

Design:  Design becomes much easier when architecture is done right—designers in each domain (whether mechanical, software, network, cyber, or others) can much more readily focus on the real issues in their realm of expertise rather than continually wrestling with higher-level issues that should have been considered a priori.  (“Does this module have to include X?  Why can’t we put it in module Z?”)  If an architecture is lacking, when these issues are elevated the answers will be ad hoc–and often the cause of grief further down the line as unanticipated changes stack up throughout.

Integration:   Good architecture specifies interfaces up front and separates concerns among components, making integration—and the inevitable troubleshooting—vastly more straightforward to plan and to conduct.

Maintainability:  Regardless of whether your system is a “prototype” or a production item, it’s a sure bet that it will have to be maintained for some significant period during its life.  A good architecture makes for an easy-to-maintain system because components are of comprehensible size, making production of manuals and other maintenance support artifacts vastly easier and cheaper than for One Big System.  And, when modules change, only certain parts of the maintenance package need change—not the whole thing, and we don’t have to go (usually vainly) searching through the manuals to find every possible impact of the change.

Design

Agreement on the design opens the door to successful implementation for both customer and supplier, especially in an OT environment.  Why is this?  It boils down to defining scope; showing traceability; and making project planning and procurements concrete and achievable.

Scope:  Presentation and agreement on the design represents an agreement on exactly what the supplier has agreed to build, when, and how.  This is absolutely crucial in the OT environment, where projects are typically “innovative, medium to high risk, or have a short timeline.”[i]  It is by now clear to all parties what to expect in the first few project Planning Intervals—and more crucially, what is the basis for discussions when the inevitable changes are required.

Traceability to requirements:  A well-executed architecture and design show not only what the design is, but why is has been chosen in relation to the requirements previously agreed to.  It’s much easier for the customer to agree to a design when he or she knows why it’s been chosen—and exactly how it satisfies the requirements and the high-level customer needs.

Planning and procurement:  The design provides the basis for refining prior plans, especially for implementation and for procurement of materials.  The PM now knows with a high degree of certainty what it will take to build to the original requirements.  To be sure, a properly Agile approach will elicit numerous changes—but now the PM and systems engineer have a solid understanding of the baseline from which changes will be made, making estimation and negotiation much more fruitful than otherwise.

Baselines—and how to use Reviews in support of them

How do we make this pay?  Simple, but not easy:  Build and enforce baselines that are visible to all. 

While DAU specifies three—Functional, Allocated, and Product, and this is a very good place to start, we must consider that a baseline is significantly expensive to establish and maintain, so more is not necessarily better.  

Depending on the size and sophistication of the project, we may keep the “classic three” along with the associated reviews, or for a smaller project (such as in many OTs), two may be enough:  A Requirements baseline and a Design baseline, with milestones to formally review and jointly approve them.  These become the foundation for changes, making their analysis straightforward and the scope discussion manageable.

The key for requirements and design reviews is explicit and recorded agreement on the results, so there is no ambiguity about what goes into each baseline.  While this prospect can create some anxiety for the technical team as they prepare for the review, a few fairly simple techniques can greatly facilitate and smooth the process–and we teach and show how to do them:

• Structuring the presentation into comprehensible segments rather than presenting “the whole boatload” before asking for questions or comments.
• Ensuring minutes are taken, as a record of the proceedings—especially the changes. Consider using more than one note-taker:  Often, note-takers are not familiar with the system or the technology, so will have difficulty capturing particular points; or may simply fail to hear.  Using two or more note-takers (depending on the size of the group) helps mitigate these problems.
• Using the Agile technique of a confidence vote after each segment. Depending on the audience size and composition, you may want to do this with everyone present (logistically tougher but includes all viewpoints) or with a selected group of customers, users, and subject matter experts (easier, lightweight, focuses on the most important people—but may miss some valid objections or points).  In any event (again borrowing from Agile), get to the heart of disagreements or perceived omissions right away; using a meeting similar to the Scaled Agile  Management Review and Problem-Solving is an efficient way to do this at the end of each day.
• If changes are significant or extensive, consider using a follow-up meeting or “Delta Review” to come to agreement with the customer.
• If the customer is shy about “signing off” on the model, send the final model and meeting minutes to all attendees; ask for objections in leadership meeting such as IPTs.

What about Agile?

It may be evident by now that we have laid the foundation that makes Agile financially viable in the OT environment:  By establishing solid requirements and design baselines, we have not inhibited Agile but rather established a basis of comparison by which we can determine if required changes have already been paid for (in the original OT) or are out of scope and therefore require a contract modification to make feasible.  The process by which to estimate changes has already been defined and exercised by pricing the system based on the architecture and refining it over the design.

Good up-front engineering doesn’t contradict Agile or SAFe—it makes them achievable in the business environment.