BPM Voices: How IT can discuss business agility with the business
What IT can offer in designing for business agility
It's common knowledge, for both business and IT alike, that business agility is critical to modern enterprises. Obviously for IT-centric industries, agile delivery of quality IT solutions is a prerequisite for business agility. But is that all IT can do; deliver solutions on time and according to specifications? Many would routinely say yes and let it stay at that, but I'll argue that there are at least two other important value propositions that an engineering mindset can bring to a business that desires higher business agility. IT can:
- Improve the quality of business requirements in general
- Teach the business how to think about business agility in a structured fashion
Let's consider each in more detail.
Improving the quality of business requirements
Nothing can slow down IT delivery more than bad requirements. Numerous studies have documented that the most costly defects are requirements defects and that a significant portion of time on most projects is spent fixing requirements defects, time that includes the post launch addition of features that were somehow missed in the first version of the product. Whatever the reason for poor requirements quality, the inevitable consequence is confusion, inefficiency and ultimately mistakes that lead to rework.
The important question to ask is this: Whose responsibility is it to improve the quality of requirements and ensure the precision, context and understanding that is necessary for professional delivery of robust solutions? The easy answer is that it is the business's problem (and fault), but in truth that's making the business a scapegoat for a deficiency in the IT engineering processes. Proper requirements development is a process that IT must take ownership of. If a requirement is imprecise, then questions should be asked until it is not. If the business context if unclear, then it needs to be clarified before a solution design can be finalized. It takes an engineering mindset to effectively decompose complex business problems into actionable requirements, a mindset for which the IT organization is much better equipped than the business organization. In other words, requirements engineering is as important to IT as any software engineering task.
Teaching the business how to think about business agility in a structured fashion
Not only will IT taking responsibility for requirements engineering improve the quality of business requirements, it will also fundamentally change the relationship between business and IT in the direction of a mutual partnership -- a partnership that IT can leverage to introduce a proper language for discussing business agility needs. At the heart of business agility is, in most cases, the ability to detect in a timely fashion situations requiring action, decide which action to take and execute the processes related to the action decided upon.
By introducing the formal notion of situations, decisions and processes into the requirements discussion between business and IT, those discussions are compelled to address key aspects of business agility as an integral and natural part of the conversation -- and in a much more practical fashion than just discussing the vision statement “I want to be more agile.” Agreeing that higher business agility is needed is easy; taking practical action to reach the objective is hard. It's no coincidence that the IT industry increasingly focuses on the combination of Operational Decision Management and Business Process Management as the way to address business operational challenges. IT needs to take the next natural step and inject the principles behind those disciplines in the way requirements in general, and business agility in particular, are being discussed with their business partners.
Discussing business agility with the business has to be based on solid engineering principles in order to convert desired objectives into actionable design. Yet the context for the discussion needs to remain business operations rather than IT solutions. This seeming dichotomy can be resolved by adopting a formalized approach to discussing and implementing operational designs in terms of situations, decisions and processes. This will require a cultural change within the IT organization. In particular, it will require the IT organization to accept intrinsic responsibility for the quality of business requirements and design, as well as the resulting need for business domain knowledge within the IT organization itself. Yet when all is said and done, the effort is well worth it due to accelerated delivery of high-quality, agile business solutions.