Articles from April 2011

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.

Observations:

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,

Importance:

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.

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.

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.
Requirements:
* 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"?