Articles from May 2011

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.