Should I Model My Entire Business?

All too often, business or system development is tactical in nature. Although this may work in the short term, over time, you will end up with functions that do not interact well or multiple systems that are partially or fully redundant. They may serve their tactical purpose, but together they do not serve the needs of the business or the customer.

So theoretically and academically, you should model your entire business. Wouldn't it be great to have such a complete, comprehensive model prior to embarking on any development project? However, in practice, this is one of the most difficult things to accomplish, for reasons both technical and political. Nonetheless, there are situations where taking on this challenge is worth the effort, such as the following:

• If you have an overarching objective that will transform most or all of your business

• If you have a project or set of interrelated projects that will take years to implement

• If you are adding a unique or unprecedented business function

• If you are changing part of your business that has many complex relationships with other parts of your business or with external businesses

In other words, if what you are planning is big, complex, ground-breaking, or long-lived, a full business model is worth the investment. The benefits are many:

• You develop a correct and common understanding of your business (making this knowledge explicit is critical to avoiding costly missteps).

• You can manage complexity more effectively (remember that complexity increases geometrically as the number of interrelationships between business functions [or systems] increases).

• You know your starting point for change. (Have you ever used an online map service to ask for directions to a destination? Does it work if you don't tell it where your are starting from?)

• You have a stable foundation for managing large or multiple projects (now you have the map and you can tell where you are on your journey).

• You can establish ownership and funding responsibilities. (Who is responsible for this part of the business and what business unit is paying for the changes?)

From the Real World—Sssssshhhhh. Don't Move. I was working on a project that was intended to bring a new and valuable service to customers, that was leading-edge in the marketplace, and that affected multiple divisions of the business. I was assigned to the project near the end of the design phase. Unlike many development projects, the business people were involved regularly in this project—partly because it affected their divisions, but mostly because it was a high-profile project. A successful project would translate into direct success in their careers. At the end of design, the consulting firm that was going to perform the implementation presented us with the expected cost to finish the project—$1.2 million. The project had already cost $0.75 million. This was big money at this mid-sized company. A meeting was held to discuss whether to go forward. In discussing the cost, one brave soul asked the critical question, ”Who owns this project?” Silence. Not a single VP or department head moved a muscle, as if a hooded cobra had just been dropped on the table. The prolonged silence was finally broken by that brave soul who pressed the question. Immediately, a verbal tennis match broke out with each department making the case that the project belonged to another department. Understand that there were also technical reasons not to proceed to implementation yet. But those weren't enough to delay implementation—after all, careers would be made on this project. But when the ownership and funding issues became explicit, it was not long before the project was cancelled.

Lessons Learned A model of your business and the planned changes will make ownership and responsibility issues clear, before it's too late. Technical professionals must understand that non-technical issues may be more powerful deciding factors than technical issues (e.g., politics, ego, and careers).