It’s amazing how many enterprises don’t have the basics agreed to, even after all these years.
Take your basic insurance company. It doesn’t matter what kind, as long as it’s customer facing. Let’s take property and casualty.
What’s good customer service from the underwriting portion of the firm’s point of view? Writing as much business as possible, within risk parameters. People will be up-sold and cross-sold if possible. As few as possible would be turned away (all risk has a price).
What’s good customer service from the claims portion of the firm’s point of view? Closing claims quickly: get the settlement file out of the system as fast as possible. By doing so, there’s always the hope that expanded claims won’t enter the picture, too.
What’s good, though, from the investment portion of the firm? Underwriting only those people who won’t make a claim! That way, the premium revenues can be invested, and positions don’t ever have to be unwound prematurely to pay out anything.
Now, let’s add another factor to the equation. “Who is the customer?”
Is the the insured — or the insurance broker? Is it the claimant — or the service provider that provides repairs? Is it the policy-holder — or the real estate trust, broker or other financial service provider who handles the investments?
Is it any wonder (as you think this through for your own setting) that organizations have so much trouble getting simple data elements to agree?
This is fundamentally a governance problem. The business as a whole (not its parts: these aren’t requirements but a higher-order issue) has to sort out who it values as its customer and why.
Microsoft, years ago, worked this out: a customer was someone who sold lots of licences; you and I were licence-holders. You can argue with the decision, but it is clear.
Most enterprises haven’t. They allow the definitions in each of their operating units to define it for them. Then, when these collide, they patch around the problem with more technology rather than sort out the underlying issue.
One reason I have repeatedly talked about the value of a Governance Board is that it is the logical place to work these issues out — to bridge the “theory of the business” as it exists into univocal direction for technology investments.
Working that out would resolve the collision between engineering and project cultures — which tend to prefer an accounting and control environment that is project-centred and uses work breakdown schedule funding rather than cost centre funding models — and process oriented cultures — which prefer organizational budget centres that mimic the organization. Neither of these is “right”, but both are deeply rooted in the work being done.
When an organization was fundamentally one culture and has become another — say a power utility that spent years building dams, plants and transmission lines and then shifts into maintenance mode (all the sites are built, expansion is now tied to demographics and the pace has slowed) — all the assumptions underlying how we do things here should be put on the table and worked through (followed by rearchitecting the company and its systems around those decisions).
Again, the Governance Board is the place to handle this, not one project at a time.
Indeed, if you do, you’ll find the projects are much easier to handle: all of the grief that normally emerges in mid-stream will have been taken off the table in advance.