How IT should spur end-user innovation

Last week's Advice Line, on how Apple's App Store stands IT's traditional deny-by-default policy on its head, stirred its share of criticism. One comment in particular left me scratching my head, as it asked why I didn't provide concrete guidance on how IT should initiate the shift away from deny-by-default when it comes to the iPad and App Store.

I'm scratching my head because I don't see any barriers to getting started. All you have to do is to establish a new policy that includes the following:

[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

• Company acquisition of iPads is a matter of management discretion. IT approval is not needed.
• Company iPads must be configured with Passcode Lock set to On, and Auto-Lock set to 10 minutes or less.
• Employees may acquire any and all software from Apple's App Store they expect to be useful in the performance of their responsibilities or that they expect might enhance the functioning of the organization to which they report, subject to their manager's approval or delegated authority, with these exceptions:

1. Programs that place company data outside the corporate firewall
2. Programs that provide "remote control" access to their corporate PC
3. Programs, or any use, that store sensitive company data on the iPad in unencrypted form
4. Programs that are redundant to standard solutions already established by IT, such as providing connectivity to company email, calendar, and directory

• IT will provide secure facilities for this functionality on request. If for an exception is needed, employees should contact the head of Information Security to develop a solution.
• When this policy conflicts with external compliance requirements (PCI, HIPAA, Sarbanes/Oxley), our external compliance requirements supersede this policy.

More elaborate guidelines might be needed in particular circumstances, but chances are, the above outline will suffice.

There is one other minor matter needed to get started (so minor and obvious that I hesitate to even mention it): organizational change management. Yes, one of the most dreaded efforts known to anyone responsible for leading a commercial organization is part and parcel of the significant step IT leaders will need to take to bring their organization to the level necessary to drive innovation in the years ahead.

I say "organizational change management" for two reasons. The first (and most important to me) is that I recently published a book on the subject, making it the right answer no matter what question you might ask -- "How do we get started on the path to SOA?" "How do we get started on a process improvement initiative?" "How do we decide where to have lunch?" "How do biologists account for the existence of the platypus?"

The second and arguably more important reason (to you, at least) is that it's one-third of the answer to the raised objection. The other two-thirds? A design and a project plan. Those are, in fact, needed to achieve any business change.

Your design should be clear about the business objective of the organizational change (revenue, cost, or risk); any new business functions that will be necessary and how they will need to be executed; the existing functions that will have to be modified (and how); and any supporting alterations to your technology set, and to employee roles and skills, needed to achieve the objective.

For the shift we discussed last week, one that moves away from denial-by-default to embrace user initiative, the business objective is to increase revenue and decrease cost by encouraging innovation on the part of all employees.

As for the business functions, tools and technologies, and roles and skills? Beats me. It's your company. The generic answer, suited to the imaginary XYC Corporation beloved of all software developers, includes changes to how the leadership role is defined; how information security is practiced; and a new business function, possibly but not necessarily housed in IT, focused on educating employees on innovation, as well as in the use of development tools suitable for non-IT developers.

Organizational change management means:

• Understanding all stakeholders -- How they're likely to react to the proposed change, why, and, if they're likely to resist it, what you can do about it.
• Involvement planning -- Figuring out how to give as many stakeholders as possible a sense of ownership in the outcome by having the ability to influence the final result through participation in design and decision-making.
• Metrics -- Not necessarily numbers; "metrics" means knowing what success will look like when it happens.
• Structure redesign -- Looking at the organizational chart, physical facilities, business governance, compensation structure, and accounting systems, to determine where and how the way they're put together reinforces the old ways of doing things.
• Training planning -- Figuring out what employees need to learn so they'll be comfortable in their new roles; also what managers and executives need to know so they don't accidentally undercut your planned change.
• Designing culture changes -- Because the most important changes a company needs to make are often out of sync with the existing culture in some way. Fostering employee innovation? For most companies, this will be high on the list.
• Communication -- Listening, informing, and persuading employees; also facilitating their communication with each other. Without effective communication, the rest of organizational change management is nothing but unfulfilled intentions.

I really can't figure out why anyone would complain about last week's piece leaving anything important out. It was complete, except for the business design, project plan, and organizational change management plan needed to get the job done. These are minor matters, as I'm sure you'll agree, which is why all I've done this week is list the topics you have to cover. What you have to do to cover them would take a much longer epic.

Or you can take the easy way out. Here's what that looks like:

1. Write a new policy (see above).
2. Send out an email to all employees, emphasizing how important you think this is.
3. Get mad at everyone else when nothing productive happens.

When you come right down to it, this alternative is easily as good, because you get to take just as much credit for having a brilliant business vision, you don't have to work anywhere near as hard, and if anything goes wrong, you get to blame someone else.

This story, "How IT should spur end-user innovation," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.