Getting it right the first time

I came across an excerpted transcript of a podcast on HP's cloud management software, which included this statement by Robin Purohit, Vice President and General Manager of the Software Products Business Unit for HP Software & Solutions:

If you think of Agile and the pace at which now new application innovations are bring rolled out, it really means that you have to get things right the first time.

I was struck by this initially because "getting things right the first time" seems antithetical to Agile, which is based on a philosophy of rapid, incremental improvement.  At the same time, there's also the realization that once a policy or process is released, making changes to that policy or process is very difficult, and such change probably cannot keep up with the rate of change in technology.  This is especially true in the cloud, where providers constantly release new features and functionality, almost without warning.

Although the source article was ultimately about management software, this holds even more true when talking about upstream processes such as governance and standards definition.  Moving to the cloud means empowering end-users with a greater ability to shape his/her environment than in a traditional IT setting.  If there isn't at least a basic set of guiding principles to abide by, you can be sure that in a few months the company's account will contain much of the same clutter and inconsistency as is often found in areas like file shares and document management systems.

Defining standards of usage for cloud-based services should be similar to doing so for other services:

1.   Identify roles and responsibilities for governance
2.   Educate governance body on the service and its capabilities
3.   Draft usage standards and present to the governance body
4.   Establish a consensus on usage standards
5.   Communicate usage standards as part of the roll-out and ongoing support

What does change is the mind-set everyone involved should adopt when going into this process.  Rather than ask, "How can we control how the service is used?", the focus should be on "How can we best empower people to responsibly use and extend the service?"  Understanding how the service can and will be employed to share data, create mash-up applications, and otherwise fit into regular processes is key to creating a set of standards that people will want to adhere to.  Trying to exercise too much control will result in the workarounds and rogue setups that frustrate both end-users and IT.

Back to the beginning - "getting things right the first time."  Your governance structure and standards don't have to be perfect before deploying a service.  They should be based on pragmatic understanding of the service, meet the most critical needs to protect the company from legal action or financial vulnerability, and be straightforward enough for everyone to understand and comment on.  Feedback should be captured and used to help hone usage standards.  Ultimately, your organization should have a usable and fairly created set of standards that are internalized by end-users and will implicitly abide by, reducing efforts for maintenance  (such as data gardening and access auditing).

Getting to new and improved services

I've been spending a lot of time recently thinking about providing IT services effectively and efficiently and how to make improvements along both dimensions in any given situation.  To start, let's look at IT responsibilities in two major categories:

• New/improved services - business analysis, projects, research, development
• "Keeping the lights on" - break/fix, service requests, planned maintenance

The first category is where IT really adds value, as a team that can both understand the business' needs and provide robust and ever-improving solutions that increase the "top line" of performance.  Unfortunately, IT tends to spend only a fraction of its time here, largely due to the effort needed to satisfy the second category.

"Keeping the lights on" consist of a series of challenges that have largely been solved within the industry.  Quick searching for any facet, ranging from authentication/authorization to service desk management to configuration management, will yield results for processes, tools, and methods.  In fact, it's almost overwhelming to consider all of the available options.

The goal is to optimize the efficiency of this category.  No one gains a competitive advantage from "keeping the lights on", so we should spend the minimum in resources to achieve the organization's needs for support and maintenance.  Bear in mind, however, that doing so will be different for each organization - for instance, some organizations accept a remote call center approach for efficiency, while others demand a high-touch, in-person support experience.  When evaluating an environment for efficiency, you should consider the following factors:

• Variety of technology to support and ability/need to standardize
• Importance of support characteristics, including speed of response and resolution, interaction types (email, phone, in-person), and environment context
• Automation of common tasks

Ultimately, some balance of these factors are required, and not everyone is going to be happy with the outcome.  When considering such an evaluation and potential change, inclusion is critical - involve at minimum the following people:

• The people who actually fulfill these tasks, such as end-user support, systems/network administrators, and application support personnel
• Key end-users that require a significant portion of IT's effort for support
• Business leadership that can help articulate overall technology goals and objectives and provide context for technology strategy

Finally, be clear about the benefits of possible change.  Essentially, any time not spent on "keeping the lights on" can be used for new and improved services.  An end-user support person who isn't fixing an email problem for the umpteenth time can be researching and consulting on the value of mobile technology or finding out about new requirements ("wouldn't it be great if I could...").  A systems administrator who isn't manually patching servers can instead enable new features for existing services or identify new technologies based on customer feedback.  An environment that can spend time on real improvement is better for the end-users, better for the IT team, and better for the organization.