Articles by Rich

In a discussion with a colleague this week, I was trying to articulate how writing business capability requirements can help guide both development and software acquisition processes.  My explanation apparently was not very good, because he definitely got the impression that I was talking about some super strategic high level requirement that was not really implementable or helpful. 

I had to go back and read my own post to figure out why my conversation had that unintended impact.

I failed to articulate the need for a business context for the requirement.  Without this, he got seriously hung up on how general the requirement sounded: "reduce the amount of time or labor input to complete some process by 30%".  It is the context that makes this requirement real.  There is real analysis in preparing the context, and understanding the business value in resolving issues in context.

Business Capability Requirements are generalized, meaning that they do not propose a path to solution, and from that perspective they treat one solution like another.  My colleague got this confused with strategy, because I failed to provide any specific context for the requirement, and so his brain instantly applied it at a very high level.  This is because it is generalized.  However the value in writing requirements this way is that they clearly separate the value target from the path to solution.

The software capability requirements imply (but do not describe) a path to solution.  These often accompany business capability requirements, and should reference them.  If your organization is like those that I have worked in, you see these much more frequently, and usually without the business context or an understanding of the business capabilities that are to be affected.

My colleague immediately translated generality into broad scope.  Generality in this case is scope neutral, you can apply the scope in context at any level.  If you apply it at a higher level, you will then need to do the analysis to determine subcontexts in which you can propose meaningful solution paths.  It is hard to propose a meaningful solution path for make employees in division 123 30%  more productive.  Any meaningful solution will require contextual knowledge of what those employees produce and how the produce it.

If my goal were posited in that way, I would create a context around every product output of division 123, and create a business capability requirement specific to each context.  Here is the catch, maybe they make 3 products, and one of them is 90% of production, but a different one takes 60% of all labor input.  If I wanted a net 30% increase in productivity, why wouldn't I make the big labor ticket 50% more productive.  This frees up 30% of my labor force to do whatever I want. This is the analysis that allows us to figure out what to do, business context. 

We talk alot about the scope of a project.  In this case we are talking about the scope of a requirement – in terms of the business context it lives in.  The way you write your requirement always guides your solution.  The business analysis to write the requirement – to frame the problem we are trying to solve is the key element. 

I have been working on an "Agile" product with our IT Project Standards and Governance group at work. When analyzing the values and principles that are espoused in our "gated" product, I realize that the difference between agile and traditional (waterfall) project methodologies is singular. There is all kinds of hyperbole around why agile solves problems that waterfall doesn't, but that is really not on the mark. As Glen Alleman of Herding Cats says "Bad project management is simply that", meaning that the problem is less with the methodology than the execution. What is different between agile and waterfall is really a small number of preferences, and ones that may only apply well in the software development domain.

The main difference is which of the primary project constraints the methodologies have a bias towards, or prefer not to vary:

Waterfall prefers to vary time and budget whereas agile prefers to vary scope. If this sounds incredibly oversimplified, think through it. By stacking all the analysis up front, the cost of varying scope in a waterfall project continues to increase over time, while the benefit of varying scope decreases. This is necessarily true, because all the analysis and design work is done "up front", before we really know how much effort is in the plan, and then when we make the decision, that work is "sunk cost" that usually must be redone if things change later. The theoretical benefit of this approach is that we can optimize the development sequence to minimize cost of re-work. This assumes that we know how to perform this optimization, and that other factors (like emerging requirements and budget and time constraints ) don't cause us to compromise this benefit.

On the other hand, Agile has a preference for a static team (it's hard to be predictable using agile metrics while your team is a moving target), and therefore a fixed burn rate, and uses typically time boxes to manage duration. But agile prefers a sequence that has implies less waste when changing scope, because rather than doing analysis and design "up front" it has a "just in time" approach – meaning within a time box. Thus the cost of changing the scope of the next time box is nothing or just the cost of re-planning, because little pre-work has been done. The risk resulting from this that causes concern is that since we don't know "everything" up front, we will learn things that cause us to go back and re-do something that has already been developed.

In theory, as analysis and design activities of a software development life cycle are completed, knowledge of the work required increases, and the risk of unknown is understood, and risk of rework correlates to the unknown. None of this really helps deal with the risk of business driven change (market change), or constraint change (reduction in time or budget). The traditional lifecycle creates waste out of the analysis and design work that was completed for capabilities that are abandoned when these events occur. The agile lifecycle reduces the waste resulting from "change". while dealing with waste (in rework) resulting from risk of unknown by allowing the stakeholders to trade lower value capabilities for higher in order to align with budget and time constraints.

Because the agile lifecycle allows the delivery of incremental value to the end user earlier (it does require everything to be done to release), the business gets value sooner, while the risk of spending without any return on investment when a project is abruptly cancelled or funding is abruptly cut is much lower. Furthermore, the agile lifecycle expects shorter feedback loops on smaller scope value targets, which creates greater focus both in the stakeholder community and on the delivery team.

So which is better? It depends on where your risk comes from. If your risk comes from the unknown, and there is little risk of the goals or funding changing in the middle of the the project, or if there is limited value in delivering part of the product early in the lifecycle, then a traditional lifecycle may work well. If your delivery in a more volatile environment, where business needs changes very frequently, where funding is driven by short horizon events, or where delivering partial solutions as early as possible is valuable – then an agile lifecycle offers some distinct advantage.

As stated in Business Capability Requirements, software capability requirements are correlated with a business capability requirement that answers the key questions why and how much. Systems designers, architects, and developers are better equipped to propose solutions, when they are aware of the benefits or value that a requester is expecting for their investment. They are much more likely to propose effective solutions when they understand the expectations of effectiveness (i.e. how much) from the requester as well. If we want the best solutions or designs, we should be able to provide the best guidance, to those doing the solutioning.

One of my favorite anecdotes from my early career is from a user named Bob. Bob was the director of a for-profit business, operating in a non-profit healthcare organization, selling services to doctor’s offices. Bob was very entreprenurial, and was always looking for more capabilities from any solution that we provided him. Bob’s favorite request was “Can’t you just make a button?”. When I was first confronted with this question, I really had no clue what he was asking for. “A Button to do what?” Initially, this question infuriated me, because it appeared to oversimplify the software development process (which we all know is very complicated). Over time I learned that this question was Bob’s way of asking for a direct and simple solution. I learned to ask him the following question, innocently, “What do you envision will happen when you push the button, Bob?” Which could be followed by questions about why and how much. I was never able to train Bob to speak initially in terms of business capability requirements, but I did learn how to hold a conversation with him to extract these, without getting aggravated.

 

• Software capability requirements also are devoid of assumptions about “location” of the capability. Location implies that there is already a system, product, or application that will be “extended” to provide this capability.

Users of a product, especially a product that is their primary day-to-day application assume that every new capability will be added to this application. This is true, even when the capability is functionally separate from the core mission of this system, or when the cost of implementing the capability on that system is many times what it would cost to implement on another system. Somewhere in the system design, and more detailed requirements, we need to weigh the convenience of a single system vs. the apparent complexity of having a user use multiple systems, the cost and time to market of each option, and the support staffing model to determine what is the best fit.

 

• Software capability requirements are devoid of assumptions about the “structure” of the capability. Structure implies that we already know what it looks like and how it works. Structure is the highest level of “how” information about a capability.

Once I was responsible for implementing a vended software product that was replacing an existing software product. I had one user insist that we develop a custom report on the new system to the exact specificiations of a report that existed in the legacy system. She insisted that her entire workflow was based around that report, and to change it would be to make her department less efficient. I tried for a while to analyze how her department used the report, and how the workflow was done, but she kept insisting that I should stop wasting her time and that all she needed was this report, and in the end, I acquiesed. I converted the existing report into detailed specifications, and asked the user to acknowledge that they were correct. Six weeks later the vendor delivered the report on time, and it was accepted. A couple months after that, we were ready to start testing the system with a workflow validation. About 30 minutes into the test, this same user came running to me, in a panic. “Where is the data entry screen that goes with this report?”, she cried. It was hard not to laugh. In specifying the structure of the capability, she had inadvertently miscommunicated. By simply calling it a report and not correlating it with a business capability requirement, she missed key information and ended up being somewhat dissatisfied. In the end, she and her staff quickly figured out that the vendor’s core capability was actually more flexible and intuitive than the legacy system, and by messing up the requirement, we actually gained some efficiency in the department. But that is not an outcome that can be relied on. And her boss was not happy to pay for a custom report that was never used. The danger of assuming structure in a software capability requirement is that it limits the solution, and those limits can impact the cost and/or the value of the solution in harmful ways.

 

• Software capability requirements should tell you what the system should do:
  • Display information
  • Accept and validate input
  • Calculate values
  • Summarize data
  • Process transactions
  • Search for something
  • Export data
  • Format data

By expressing the “What” the software should do, without positing expectations of “How” it should be done, the software capability requirement allows business process to evolve to take advantage of every capability of a system, rather than perpetuating existing workflows intact.  And most of the time, aren’t we expecting that our new system will provide better workflows…

When evaluating a software product, one of the most important things to understand is the core metaphors around which the software is built. Why do I use the term metaphor, rather than entity or concept? Because a metaphor is a substitute, a proxy, and in software, the core concepts are proxies for real concepts in the business process that is to be supported.

Example:

If the real business process requires a contract between your organization and the customer, what system metaphor represents that contract? If there are different types of contracts, how do the system metaphors represent different properties and behaviors of those contract types? The degree to which the software metaphor for contracts reflect the real attributes or properties of the contract (term, effective date, rights, etc.) will determine what aspects of your business can be automated.

There are certain concepts that apply to system metaphors that help you determine its applicability to your business model. Here are questions to ask to determine how a software metaphor correlates to the real entities in your business model:

• How generalized is this metaphor?

For example: Does the software provide a single contract metaphor or is there a different metaphor for every kind of contract that is supported?

• How does the metaphor support variations in business process?

    For example: Does the system assume that every contract has the same properties and behaviors, or is there some way to define different contracts that have different properties and behaviors?

• How is the metaphor structured?

    For example: Can your customer be a person, a business, and if a business, can it represent a business hierarchy (subsidiaries) so that you can report (p&l) by
    subsidiary or at the holding company level?

• How does this metaphor relate to other metaphors in your business model?

    For example: If your contracts are leases, does the lease metaphor relate to an asset or property metaphor, so that a validation could be built such that a
    property or asset can only be related to one lease at the moment, but could be related to multiple leases that are not for concurrent periods? Is the lease or contract metaphor related to both the property and the customer metaphor so that I could easily determine which properties are currently leased to which customer?

• How do the attributes of the metaphor support my business process?
• For example: If you have a process that determines which leases are going to expire in the next period, and proactively contacts the customer to plan to renew or amend – do the system metaphors support a convenient way to support this process?

Example:

If your business generates leases for different types of assets or properties, that vary dramatically in properties and behaviors, and the competitive business model is to continue to add variations to new leases, but a potential software solution does not adequately support variations in lease behavior. Purchasing this software will require the business to manually work around the deficiencies in the software solution, perhaps by capturing the variations in behavior as "comments" or "notes", and requiring staff to "remember" to review the comments and notes when processing the lease. Over time, these manual work-arounds build up into inefficiencies, and add risk (what happens when someone doesn't remember, customers are disappointed?) such that over time, you can reduce your profitability and customer satisfaction.

Conclusion:
In practice, a system that institutionalizes work-arounds because it does not represent information and behavior in reasonable alignment with your business model affects the ability to grow your business in two ways:

• It requires more staff because it provides less "leverage" to your employees. That is, each one can do less work in a given amount of time.
• It requires more capable staff, because it relies more on staff knowledge, diligence, and intelligence to implement all of the processes that cannot be done through the agency of the system.

What can be done?

Document your business model, especially focusing on the key metaphors, how the behaviors of those metaphors engage the ability to grow or sustain your business model, or how you would like those metaphors to change your business model to become more scalable or competitive. Understand this deeply, so that you can compare each vendor and software product to see how they "enable" growth, sustainability, or desired change.

Understand the business capabilities that you want to maintain, improve, or develop in terms of the metaphors. These are your business goals. Use this list to evaluate vendors and software products to see how their software (with it's metaphors) will enable you to achieve the goals that you have established. Recognize that no one product is likely to perfectly match your goals, and that compromises will have to be made.

Make sure that all participants in the selection or evaluation process deeply understand the business goals. Focusing any IT project on the business goals, and never letting your goals out of site, is a way to ensure success. Your criteria for software selection should eminate from that products ability to enable goal achievement.

When evaluauting a software product, one of the most important things to understand is the core metaphors around which the software is built. Why do I use the term metaphor, rather than entity or concept? Because a metaphor is a substitute, a proxy, and in software, the core concepts are proxies for real concepts in the business process that is to be supported.

Example:

If the real business process requires a contract between your organization and the customer, what system metaphor represents that contract? If there are different types of contracts, how do the system metaphors represent different properties and behaviors of those contract types? The degree to which the software metaphor for contracts reflect the real attributes or properties of the contract (term, effective date, rights, etc.) will determine what aspects of your business can be automated.

There are certain concepts that apply to system metaphors that help you determine its applicability to your business model. Here are questions to ask to determine how a software metaphor correlates to the real entities in your business model:

• How generalized is this metaphor?

For example: Does the software provide a single contract metaphor or is there a different metaphor for every kind of contract that is supported?

• How does the metaphor support variations in business process?

    For example: Does the system assume that every contract has the same properties and behaviors, or is there some way to define different contracts that have different properties and behaviors?

• How is the metaphor structured?

    For example: Can your customer be a person, a business, and if a business, can it represent a business hierarchy (subsidiaries) so that you can report (p&l) by
    subsidiary or at the holding company level?

• How does this metaphor relate to other metaphors in your business model?

    For example: If your contracts are leases, does the lease metaphor relate to an asset or property metaphor, so that a validation could be built such that a
    property or asset can only be related to one lease at the moment, but could be related to multiple leases that are not for concurrent periods? Is the lease or contract metaphor related to both the property and the customer metaphor so that I could easily determine which properties are currently leased to which customer?

• How do the attributes of the metaphor support my business process?
• For example: If you have a process that determines which leases are going to expire in the next period, and proactively contacts the customer to plan to renew or amend – do the system metaphors support a convenient way to support this process?

Example:

If your business generates leases for different types of assets or properties, that vary dramatically in properties and behaviors, and the competitive business model is to continue to add variations to new leases, but a potential software solution does not adequately support variations in lease behavior. Purchasing this software will require the business to manually work around the deficiencies in the software solution, perhaps by capturing the variations in behavior as "comments" or "notes", and requiring staff to "remember" to review the comments and notes when processing the lease. Over time, these manual work-arounds build up into inefficiencies, and add risk (what happens when someone doesn't remember, customers are disappointed?) such that over time, you can reduce your profitability and customer satisfaction.

Conclusion:
In practice, a system that institutionalizes work-arounds because it does not represent information and behavior in reasonable alignment with your business model affects the ability to grow your business in two ways:

• It requires more staff because it provides less "leverage" to your employees. That is, each one can do less work in a given amount of time.
• It requires more capable staff, because it relies more on staff knowledge, diligence, and intelligence to implement all of the processes that cannot be done through the agency of the system.

What can be done?

Document your business model, especially focusing on the key metaphors, how the behaviors of those metaphors engage the ability to grow or sustain your business model, or how you would like those metaphors to change your business model to become more scalable or competitive. Understand this deeply, so that you can compare each vendor and software product to see how they "enable" growth, sustainability, or desired change.

Understand the business capabilities that you want to maintain, improve, or develop in terms of the metaphors. These are your business goals. Use this list to evaluate vendors and software products to see how their softare (with it's metaphors) will enable you to acheive the goals that you have established. Recognize that no one product is likely to perfectly match your goals, and that compromises will have to be made.

Make sure that all participants in the selection or evaluation process deeply understand the business goals. Focusing any IT project on the business goals, and never letting your goals out of site, is a way to ensure success. Your criteria for software selection should eminate from that products ability to enable goal acheivement.

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"?