« Bad Data Can Cost you Millions | Main | Transformation ─ the "T word" »

Always talking about standards? Here's when to stop.

I always seem to talking about standards, but I don't think I'm a standards fanatic. As a matter of fact, I usually find myself arguing the position that we have gone too far with standardization. So why do I keep coming back to this topic?

Standards are important and despite common belief, standardization does not have to be the enemy of innovation. Adoption of the right standards should enable your company to focus innovation on the things that can bring your company the most value.

Even with corporate policies and all the focus on the IT strategies, I still don't think we have the messaging right around the role of standards. So pardon me, I am going to try tackling this one more time.
Many companies have a culture of central policymaking, but distributed decision-making. It is obvious that before we set standards, we have to understand and align to business needs. Nevertheless, we often oversimplify those needs for the sake of efficiency and cost reduction. Saving a little bit of expense by limiting options can be a good or bad thing. Reducing options on a technology or service that only has limited utility value is a good thing. IT can help keep investments focused on the greatest value and clarify the utility foundation that more valuable solutions can be built upon. Some may get grumpy when someone is taking away their favorite way to do something, but they ultimately need to recognize the modest value of that choice and get on board.

So what happens when the IT function oversimplifies a critical work process? This is where IT may overstep its role.

Let's say we think the reservoir management suite of tools should be the same for a water flood project as a heavy oil steam flood, or that drilling a deep water complex sub-salt well is the same as drilling a shallow shale gas well. Does that mean that drillers own the information object of the well? What about the operations and maintenance roles, workovers and re-drills? In many business units, these small capital projects and sometime operation expense jobs are ran by operations, not drilling. Can you have an effective System of Record if no function will take ownership (or if more than one function claims ownership) of: defining data, managing data quality, driving the right user behavior and understanding how the data flow and lifecycle align with desired work process, technology refresh cycle, vendor alliance relationship or internal support?

If IT attempts to limit the applications suite for the sake of IT efficiency, you can end up providing an 80% solution to a valuable process and limiting your ability to create competitive advantage. Knowing when one standard is the right answer versus when a guideline of several solutions is the right answer, is an art and a critical balancing act for IT. You need industry knowledge to make many of those choices and answer these questions.

In setting standards, we also need to appreciate the maturity level of the organization. Some standards are more applicable when a group has reached a higher level of integration and design maturity. For example, a master data management solution is a critical role for an organization tackling cross-functional workflows. However, this could be an unnecessary complication for a function still working on domain specific applications and closely coupled data stores.

I guess in summary, the answer about standards is: it depends. Our important attempts to rationalize and simplify our application inventory are filled with important choices. While the goal is to reduce IT expense, it is also to provide a foundation that our business can leverage digital technology for competitive advantage. Some choices are obvious (older versions of the same software, applications that are no longer and weren't retired properly). Other choices are more complicated and require careful discussion with the user community considering the consequences of losing functionality. Other choices are just to leave some diversity alone when the requirements for specific tools create more opportunity than the rationalization brings savings. Other times standardization needs to wait until the community is ready for it.

Don't just give me a shorter list of standards. Give me a menu of the right number of solutions, well supported and integrated for all the value creating opportunities that you want to pursue. Then, and only then, can I stop writing about standards.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.