Practice, Rehearsal or Exercise

As leaders, we need to better distinguish between these three activities.

In three domains that are "performance" domains, these words have somewhat different connotations.

Professionals: Doctors and Lawyers practice – that is they perform their profession. They do not rehearse, nor do they exercise, at least they do not differentiate between the performance of their profession and the preparation for performance.

Artists: Musicians and Actors practice – that is they spend time preparing themselves for a performance event. This can be in the form of a rehearsal, a planned unattended performance of all or part of some body of work that is to be performed. They also do exercises or drills – repetition of non-performance work designed or selected specifically to improve technique, capacity, or dexterity.

Athletes: Virtually all athletes practice, that is they spend time preparing themselves for a performance event. Their practice is in the form of simulated play or drills, repetition of simulated performance activities designed or selected specifically to improve technique or agility. They also exercise, but this is primarily to improve or maintain capacity or flexibility.

So leaders, when you coach your teams, are you conscious of the difference?  How do you help your teams build technique or agility? How do you help your teams maintain or improve capacity or flexibility? How do you help your teams prepare to perform? Practice, Rehearsal and/or Exercise?

Business Capability Requirements

Many times when software requirements are collected, organized and documented, the focus is on the software capabilities needed. But software capabilities are not sufficient to get business value. One must also document the expected pattern of integrating the software capabilities into the business process to understand how the value will be realized.

Stating requirements in terms of business capabilities is a way to do this. Business Capability requirements always exist in a business context. A business process, a business model, an operating unit, etc. They are not independent from this context. Software capability requirements are necessarily independent of any specific business context, as the software is independent of the business operation. This notion of independence is not unique, it is analogous to a branch office procedure or policy, where we want to develop a generalized branch office operating procedure that works independently of any specific branch office, but allows all branch offices to operate and integrate with the home office in standard ways. In the same way, most software capabilities are generalized, so that they are independent of the business process, a report shows what it shows, a screen allows the input of data, but those actions outside of the context of a business process do not realize any value.

Let's walk through some examples of business capability requirements and some potential software capability requirement that might be integrated to meet the business capability requirements. We start by defining the business context.

Business context:

There are 20 offices, each having one or more departments or teams, that perform a specific client servicing process. In the current state, it requires two or three different roles from the team to complete this process in collaboration. Overall, the process takes 1.5 man hours. We also know that 1 in 10 contracts have to be revised after signing, and 1 in 20 approved contracts do not get imaged in the same day. Here are the current steps in the process:

  • Rep Role
    • Interview client to capture information
    • Enter service contract on paper log
    • Fill out of paper forms
    • Get the client to sign those forms
  • Approver Role
    • review those forms for correctness and completeness
    • Countersign the forms
    • document the approval on paper log
  • Associate or Rep Role
    • update an existing software system with data from the forms.
    • scan the paper forms into the imaging system
    • File the paper forms in the client file.
    • Countersign the paper log indicating that the process is complete.

Business capability requirements:

Increase the capacity of each office to perform by 200% without increasing staff.
Decrease the number of process exceptions by 50% without increasing staff.
Decrease the amount of time that the client is required to be involved in the process by 50%.

Software Capability Requirements:

  • Provide an ability to generate signed paper forms, based on the answers to interview questions so that the staff and client involvement time to fill in paper forms is reduced by at least 50%.
  • Provide an ability to validate input to ensure client responses meet internal contract criteria – so that we reduce the number of signed contracts that need to be revised by at least 50%.
  • Provide an ability to capture electronic signature for clients and approvers so that staff time spent scanning paper forms is no longer necessary.
  • Provide the ability to integrate data from the forms capture process into online systems so that staff time spent on manual key entry is eliminated.
  • Provide the ability to automatically generate images of the signed and approved contract so that staff time spent scanning is eliminated, and all imaging process errors are eliminated.
  • Provide an ability to audit of all service contracts that have been initiated in a given time period, and the status of that contract, so that the staff time spent updating a paper log is eliminated.


Notice that each of the software capability requirements is related to a business capability requirement, and also some context information through a "so that" clause in the requirement. This structure is so that we can ensure that the software capabilities are directly tied to the business goal in the business context. If we created the abilities without meeting the "so that", we have not "satisfied" the requirement. The "so that" describes the business value that we want, and software capabilities that do not add business value are a waste.

The business capability requirements describe success criteria for the project. Before we get busy exposing the details of how we want the software capabilities to work, we must establish the success criteria, so that the builders can know when they have done it. We communicate this up front, because the builders should know why what they are doing is important.

The business capability requirements are separated from any statement of return on investment. We are freeing up staff time and reducing the errors in a process, What the business uses that staff time for is immaterial to the design of the software.

The software capability requirements do not specify any specific system that should receive a feature or capability. We know from the context that there are at least two software systems involved in the business context, yet neither of them directly mentioned in the software capability requirements.

Software capability requirements should be completely devoid of "how" they should describe a "what" and relate it to a "why". The what is a software capability, not a specific software component or feature. The specific components and features are part of a solution proposal or high level design,


When there are larger decision about the solution as yet unmade (such as buy or build) documenting the requirements in terms of capabilities, rather than specific means of providing those capabilities becomes very important, It allows one to evaluate vendors independently, and against a build decision on level ground, or without bias.

Vendor Evaluation Framework

When your organization is a consumer of software capabilities and a producer of software capabilities, every project may be subject to a buy versus build decision. Many organizations struggle to have a rational repeatable process to make these decisions. Turf battles between IT and functional business units, personalities, experiences and emotions often become involved in these decisions, and as a result the decision is often made poorly.

A decision framework for buy versus build should be rational, based on the projection of expected benefits of from either direction. This requires us to renounce hidden agendas, political objectives, and be empirical.

In a build versus buy decision, we are comparing already existing capabilities in the vended solution against the our confidence in the ability of our IT unit to build software that meets our requirements.

From the business perspective factors that go into such a decision are:

  • New Business – Does the business practice that will benefit from the software capabilities already exist, or is the business practice dependent on the software capabilities in order to be realized?
  • New Solution – Is the new solution replacing an existing software solution, or are these net new software capabilities?
  • Secret Sauce – Does the business practice that will benefit from the software capabilities provide your organization competitive advantage?
  • Well Regimented – Is there well understood process documentation for the business practice that will benefit from the software capabilities?

From a vendor perspective, factors that go into the decisioin are:

  • Corporate Risk – Is the vendor financially sound, ripe for a takeover, entreprenurial or managed, focused or comglomerated?
  • Relationship Risk – Are you going to be the vendors biggest client, smallest? Do you have expertise or market share that they want? How long is their implementation pipeline?
  • Capability Risk – How good are they at delivering on time, delivering quality software? How good are they at understanding your business, your needs?
  • Product Risk – How much of your current/future need does the current version of their product meet right now?
  • Roadmap Risk – How much is your organization like their other clients? Are they focused on gaining market share in your market segment?

From a Internal IT perspective, factors that go into the decision are:

  • Capacity – Is your IT organization able to deliver solutions quickly, or ramp up to deliver when needed?
  • Flavor – Is your IT organization more oriented to integrating and supporting solutions or major appliction construction?
  • Relationship – How is your relationship with your IT group? Do you partner well to accomplish things, or are there political impediments to progress?
  • Predictable – Does your IT organization deliver on its committments with tranparency and integrity?

From a Financial Perspective :

  • Initial Cost – what do we spend to get the software capabilities? Installed? Working?
  • Integration Cost – what does it take to get the information we need into/out of this application?
  • Testing Cost
  • Training/Business Change cost
  • Annual Support Cost – what will it cost us per year over the expected life of this application?
    • Staff Cost
    • License/Vendor Maintenance Cost
    • Cost of Taking new releases, or making Capital Improvements
    • Cost of maintaining infrastructure (hardware, OS, dbms, application platform)

Last, we must consider product risk – how well the existing vendor products meet our current and future needs. This assumes that we can articulate our current needs and/or predict what our future needs might be. If we don't have this well in hand, we need to be able to articulate and prioritize current and future needs based on business value. If we can't do this, neither buy nor build will be successful.

The Cause

Causes of problems are sometimes elusive. Symptoms are misleading, reporters expectations are misguided, layers of business process and automation, and years of workarounds and patch jobs render the situation very confusing.

The cause of a problem has a category related to it's proximity to the symptom revealing component:

  • Local cause – when analysis reveals that the problem is specific to the component itself.
  • Adjacent cause – when analysis reveals that the cause is in components directly adjacent to the component revealing the symptom.
  • Subsystem cause – when analysis reveals that the cause is in components closely related to the symptomatic component.
  • Systemic cause – the cause is isolated in a component that is shared or used by many unrelated components in the system.
  • External cause – the cause is outside of the boundaries of the system – or business process. This is often referred to as "garbage in, garbage out".

The cause of a problem has a category related to its probable frequency of occurrence:

  • Incessant – when one occurrence of the is not likely to complete before the next begins. If the symptom is performance related, the result can be a complete log jam.
  • Regular – when an occurrence is expected every time a process happens.
  • Routine – when an occurrence is expected only under certain conditions, that happen routinely.
  • Infrequent – when an occurrence is expected only under certain conditions, that happen infrequently.
  • Unlikely – when an occurrence is expected only under a rare confluence of unlikely conditions.

The cause of a problem has category related to its class or type:

  • Human Error – A human did not correctly execute according to process and procedure.
  • Sequence Error – Process was executed out of sequence.
  • Resource Issue – Some critical resource was unavailable when needed to complete the process.
  • Process Definition Issue – The process definition did not account for some real condition, and error resulted.
  • Automation Issue – Some process automation (either software or machinery) malfunctioned.

When documenting a cause for a problem, consider that each of these categories should be assigned. Note that these categories are equally applicable to problems expressed in terms of a manual or automated systems or processes. In our current mostly automated state, we have as much likelihood of a problem involving both automated components and manual components. Even when we are only responsible for the software, or the "systems" components, we need to reflect that the problem can be caused by errors in the manual components of the "system".

Design vs. Specifications

Discussion about what constitute design vs. specifications has been a part of many projects and systems product teams that I have been on.  In some groups we built detailed specifications for every component, and other groups just focused on the assembly of the parts in the design, and let each developer build the parts her own way.

If your design is component specs without assembly instructions, then it becomes impossible to tell whether your design will actually meet the requirements.  If your design is assembly instructions, without component interfaces, it is hard to tell whether your design is going to work.  If your design does not include a PUNCH LIST of components that need to be built, it will be hard to build a plan to get to complete.

Contemplate this analogy:

Project: build a truck to transport 15 tons of High Explosives across the country.
* Must get there in less than 70 hours
* Must prevent explosives from detonating

Design Criteria:
* Distance is 3500 miles – must be able to average 50 miles per hour including gas and food stops.
* Explosives will detonate if inside temp exceeds 105 degrees Fahrenheit
* Explosives will detonate under acceleration of 1.4 g

When designing this vehicle I need to ensure that I meet the requirements and design criteria.  When reviewing the design, I need more than anything to understand how the design meets that requirements and design criteria.  How does knowing that I am using 3/4" lug bolts torqued to 150 lbs-ft to secure the wheels to the axles help me understand this?  What I am going to be concerned with first is:

* What will be the expected fuel economy and fuel capacity (how many fuel stops)?
* What is the top speed of the vehicle, and the fuel economy at top speed?
* What is the expected gross vehicle weight and carrying capacity of the vehicle?
* What mechanism am I going to use to damp the acceleration of the vehicle or cargo when encountering normal or abnormal bumps?
* What method am I going to use to keep the load cool?

In order to understand whether the proposed vehicle will meet the requirements, my design must expose the answers to these questions. 

Do your software designs expose information this way, or do you require your audience to "figure it out"?

The Impact

 No description of a problem should be considered complete without some explanation of the impact. Impact is simply stated as the result of not solving the problem. All statements of impact should have a cost, a timeline to realize the impact, and a likelihood or probabibility of realization. None of these are precise measurements, because measurement would only be valid after the impact was realized. These are informed conjecture.

Let me walk through an example:

In a manufacturing plant, a piece of equipment essential to making hottentot widgets breaks down. We are currently manufacturing to back fill our inventory, and do not have any open customer orders for hottentot widgets. This piece of equipment is one of two that are capable of doing the required work, so that I can continue to manufacture, but at half speed.

In this case, impact is only realized after I have sufficient customer orders to exhaust my inventory of hottentot widgets, and insufficient capacity to meet my customers delivery expectation (causing my customer to cancel the order and place with an alternate supplier). The immediate cost would be the profit on the canceled order. A subsequent cost might be that the customer would then favor the alternate supplier in a way that causes me a longer term loss of profitable business.

Given that I have three clients who purchase hottentot widgets regularly, my timeline to the immediate cost would be determined by the normal schedule for those clients and my current inventory. The probability of this impact would be realtively high 95% – in that if I don't fix that machine, it will happen. The longer term cost might only happen on one client, and only after two missed ship dates, amybe only with a 60% probability. This second risk can be mitigated by byuying the widgets from the competitor myself and selling them at a loss to keep my customer happy.

Let's say that the immediate cost is $10000, and the timeline to realization is 2 weeks, with a probablility of 95%. That is an easy impact to understand. If I have the machine fixed with 2 weeks, there is a strong likelihood, I can get by with no impact. Call the service company and schedule the technician. However, if by the middle of week 2, things have not been resolved, I might get a little excited. I would probably be calling the service provider daily or more frequently, escalating with their management, potentially threatening to use a competitor if they can't meet my need.

Understanding the impact in terms of the cost, timeline and probability are important to assessing the urgency of a solution. They tell me when I need to get out my cape and tights, and when even that is too late. More than anything, they allow me to manage my customers' and my management's expectations and to react to their concerns in ways that build confidence and credibility.

The Symptom

 Problem solving is done better when the symptom is articulated separately from the cause and the impact. The symptom should be articulated as the experience of the person reporting the problem, and his or her opinion about where the process/system failed to meet his or her expectations. There may be some steps leading up to the failure, and maybe an outcome (what happened after the failure.

Analysis of what is necessary to reproduce the symptom is valuable. Validation that they symptom can be reproduced following some steps is extremely valuable.

The context, or business process that the reporter was executing is important. A description of what should have happened instead is also valuable. These are part of the symptom.

— the cause is separate from the symptom. When reporting the problem, speculation with respect to the cause is simply that, speculation.
— the impact is separate from the symptom. When reporting the problem, the impact is only to be understood in the context in which the problem was reported.