A colleague was discussing with me a scenario related to managing expectation levels with business units. Essentially, a business unit requested a change which, to them, seems like a simple change. However, to the developers it is a pretty significant change. The reason is that the change is applied to an enterprise domain entity. As such, the change has significant ripple-style impacts throughout the organization.
A domain entity is some thing in your software system that represents the business domain under which the software executes. An enterprise domain entity is the same thing except that the business domain is the entire organization. Entities at your organization (and mine) that might fall into this category are: clients, contact information, employees, and so on.
The Problem
The development team's estimate (on the order of weeks) is FAR greater than the business unit's estimate (on the order of hours...maybe days). Thus the challenge. The business unit seems to think that the development team is unrealistic in their estimation. Perhaps they are concerned that gold-plating is occurring. Or perhaps they are worried that the development team is trying to implement multiple changes under a single umbrella. Regardless of the reason, the business unit simply does not understand why such a seemingly simple change takes so much effort.
"Seemingly simple" is a key phrase in this discussion. The development team understands, from a technology perspective, the scope of the change. The business unit does not (nor is it their job to). I reminded my friend that the business unit is likely not aware of all of the requirements. "All of the requirements?" he asked.
One Cause of the Problem
We tend to focus a lot on the functional requirements and non-functional requirements related specifically to the current business domain when we deal with projects and changes. We might even document some domain-inspecific requirements (must use SQL Server, must use .NET). However, we tend to forget the requirements of the Enterprise Architecture and it's "-ilities" (props to Craig Larman).
While the functional changes required in the above scenario might be simple, the development team is aware of the enterprise architecture requirements. After the change is applied the system must be maintainable, scalable, perform well, etc. etc. (and I'm being intentionally vague here - you will no doubt have specific, quantitative requirements for performance and such). The change must not adversely impact other systems tied to it. Remember that this is an "enterprise"-wide change. Therefore, if other systems use those domain entities they, too, need to be tested, etc.
The Solution
So how can you deal with this? Well since the IT Director / CIO / CTO has approved the enterprise architecture; and since the enterprise architecture defines the supplemental requirements ("-ilities"); and since the business unit is having the hard time with it; THEN the IT Director / CIO / CTO should probably have a little chat with the head of the business unit in question. Not a bad nasty chat. Just a chat to explain the other obligations on the CIO's shoulders.
Remember these points:
- IT's service scope is typically broader than other business units. Therefore, IT has to consider the impact of changes, projects, etc. on the whole organization and not just on a single unit.
- It's not about the IT department, or about business unit A, or the HR department, or accounting, or whatever. It's about the business as a whole. What do we do here? We make money (revenue, man-hours, etc.). How do we do that? (you have to answer this one). So while unit A may not be getting what they want from IT...maybe it's because IT is doing what's best for the organization.
- Having project and product roadmaps, which are in turn linked to the strategic technology plan, which is in turn aligned with the strategic business plan, is an invaluable tool for IT Director's / CIO's / CTO's who have to manage the expectations of business units within their organizations.