"It's as if we're more concerned with limiting our liability rather than providing a service," one of us said.
It's an old split in the IT world, a split that reflects the industrial origins of whoever is promoting the position.
Businesses rely on technology to automate processes and provide a competitive advantage. Things have to work, or the business won't make money.
On the one hand, any sane service provider (which is what IT is) is going to be very careful about setting expectations. On the other hand, If you don't provide services, you aren't (arguably) creating value.
The split can also be described as the difference between being a plumber vs. being an architect, or a technician vs. an engineer.
So, which is it? It depends on whether or not you're trying to grow your domain. Or rather, how you're growing your domain. In our case, there are some responsibilities we've inherited, which we do not need to compete for. There are other responsibilities which we are pushed to take on, but are reluctant to, because the scope is not fully defined.
The result is that we spend a lot of time talking about the things we can do for internal business units, but when they have a specific request, we backpedal. Or, worse, we commit, then find out that a process we were relying on is not supported for our needs, and we fail.
The end result, which is bad for the company at large, is that no one wants to approach us for help, because we either say now, or we fail. So, no one changes how they do things. No one reports problems, nothing gets fixed, and we hobble along; we muddle through and get by.
