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.
No Comments