All Posts in Leadership

|In: Leadership|Last Updated:

Thomas Kuhn published The Structure of Scientific Revolutions in 1962, redefining the dialog about how science progresses, changing it from a purely philosophical prescription to incorporate the sociology of how real scientists actually behave.

In it, to his everlasting damnation, he introduced the phrase “paradigm shift,” which has since been tortured to insanity by a generation of management consultants who never bothered to actually read Kuhn’s seminal work.

It’s a shame, because the underlying idea — that major advances entail a complete change of perspective and worldview — is quite valuable. A paradigm shift doesn’t disprove old ways of looking at things. It makes them irrelevant.

For example: IT is in the midst of a paradigm shift that makes the old idea of requirements irrelevant.

“Requirements” is a holdover from a time when functional managers and end-users asked IT for a system. IT, responsible for delivery of working software that did something useful, asked the logical question, “What are your requirements?” What we got in response were a series of attributes. Software that possessed those attributes “fulfilled the requirements.” Whether it did something useful for the business wasn’t IT’s problem.

That isn’t how things work anymore, for which we should be eternally grateful. IT and functional managers now share responsibility for making sure business change happens. With this new scope, IT and representatives of every affected part of the enterprise must collaboratively redesign the target business function.

Defining requirements is irrelevant to this process. Instead, we must create a high-level “functional design” that describes new business processes, employee roles, and the technology that will be used by employees in their new roles to implement the new processes.

“High level” is a vague term. In practice, it means allowing no more than seven boxes in any diagram and no more than seven bullets of text in any narrative. When necessary for clarity, you can elaborate each box or bullet with one more level.

Once everyone agrees that this new design will work, you can drill down to as many more levels as necessary to create a detailed specification from which developers can code, testers can test, and trainers can train employees in their new roles.

It might seem that the difference between requirements and design is simply word play. It isn’t: Requirements are attributes; designs describe how things will work. This is far more than a semantic distinction.

It’s a different paradigm.

Comments

|In: Industry Commentary|Last Updated:

“We can’t just let users install anything they want!” This, the mission statement of the Value Prevention Society (VPS), has, in a decade, evolved from controversial policy to unquestioned postulate.

The history of the personal computer belies it. PCs succeeded because they freed end-users from the constraints imposed by centralized IT, letting them select, install, and make innovative use of whatever capabilities they could program themselves or acquire through the purchase of inexpensive shrink-wrapped software.

“Nice theory, but,” I can hear VPS members respond, “supporting uncontrolled desktops would blow our IT budget.”

This strawman argument misses the point perfectly. VPS members live in a binary world — the only alternatives they recognize are complete lockdown and total free-for-all. The real world is more interesting. So in the interest of offering solutions instead of criticism, here are some elements of a more balanced desktop support policy:

  • Establish multiple levels of supported software. The stuff you install, support, and pay for out of the IT budget right now is one level — fully supported. Next comes software IT has tested and found reliable, but doesn’t pay for or install. Call it endorsed. Third is software IT hasn’t tested, but is well-known, comes from a reliable vendor, or otherwise is deserving of some trust. Call it acceptable. And finally, there’s that other stuff. Call it disallowed.
  • Establish multiple levels of support. Problems with fully supported software are first in queue. Next come problems with endorsed software. Problems with software rated acceptable rate the lowest priority, with no guarantees beyond restoration to a standard image.
  • Require management approval. As Ronald Reagan was fond of saying, “Trust but verify.” Trusting employees doesn’t mean trusting them blindly, so if an employee wants to install (for example) a personal information manager (PIM) other than the company standard, his/her manager must approve the purchase … and, of course, the PIM must rate “acceptable” or above.
  • When integration is vital, company standards rule. If you have no CRM software in place, for example, sales representatives should be able to buy and install whatever contact manager they want. If you have implemented a serious CRM suite that includes sales force automation, the standard overrides personal preferences.

What’s that you say? It’s easier to just lock ’em down?

Of course it’s easier. That’s often the nature of a bad decision.

Comments