No, this isn’t about an IT-based/centric/focused business, where IT or an IT system is the product. It is about when IT needs IT (or anyone, really) to do something. When Finance, Sales, etc. need IT to do something, we often refer to them as “the business” or “business users” (sometimes with an us-verses-them mentality that is very dangerous; remember: we are a family).

IT complains that The Business did not adequately define the requirements or provided a solution instead of a problem statement or used a lot of jargon and acronyms (jargon and acronyms is a whole subject on its own). Side tangent: Yes, the business needs to be more descriptive but also IT needs to help and guide. We are all humans.

Returning to the topic, sometimes we in IT need IT to do something. An example could be an admin needing help automating or streamlining provisioning. How do we describe it? Do we use lots of jargon and acronyms? Do we only provide a short description that effectively communicates, “you should be familiar with the process and what I want done”, and does not provide adequate detail? Do we define a solution but not actually define the problem?

Bonus rabbit trail: I think a lot of clunkiness in systems and things that need reworked are simply because things were implemented from a proposed solution without first understanding the problem. The development process should not be the business handing IT a solution that they then implement without question; it should be a conversation (we have knowledge and understanding and insights that they do not and vice versa).

Basically, if IT needs something, we need to apply the ideas and ideals that we want the business to apply with us. We also need to self examine and consider our own struggles with the process and how we might better guide and help the business when they come to us.