Agile overview
The last post in this series outlined an approach to creating meaningful documentation. It leveraged the Agile concept of maintaining working systems over comprehensive documentation, starting with identifying how an IT operations team would use the documentation to support its regular activities.
This week we’ll look at the third precept of the Agile Manifesto: Customer collaboration over contract negotiation.
Identifying the customer
IT operations organizations can support internal customers, external customers, or a combination. This article will focus on IT operations departments which support only internal customers.
When your customers are internal, identifying them can sometimes seem difficult. For example, IT operations teams often identify the CTO as their customer, while others point to their company’s development group. A simplified approach is to include as a customer anyone who comes to your team for any of the services your IT operations team provides.
Customer contact
Larger, more established companies typically create standard processes by which internal customers may approach the IT operations team for services, often filtered through the helpdesk. Smaller, less structured or startup-type companies generally have a more casual approach that relies on various types of shoulder tapping or other informal methods. Occasionally, companies will embed IT operations resources within project or product teams.
Whatever engagement model your organization uses, it’s important for the model to be clearly communicated both to your IT operations team and to your customers. Your team needs to know how customers should contact IT operations and exactly what services the team can provide them. This knowledge will support the team’s ability to track and prioritize requests.
Customer communication
Communication is the foundation of collaboration. When customers make request of the IT operations department, they want to know what’s going on with those requests, including:
- When will this be done?
- How can I track progress?
- Is there anything I can do to get my request completed quickly?
- If my request is rejected, do I have any recourse?
Create a transparent prioritization process. Customers will be less likely to become antagonistic when their requests aren’t acted on immediately if they understand why other requests took priority.
Contracts
IT service contracts are used extensively by consultants and 3rd-party service providers. They’re valuable for defining factors such as time, cost and scope, and they set expectations.
A contract is a legal binding between two independent and separate organizations that offers recourse should a disagreement occur. It can help two organizations define the roadmap of their relationship and provide details on the formalized components of the agreement.
Recently, I have seen a trend for organizations to establish IT service contracts between IT operations teams and their internal customers. A low-level type of internal contract is the Service Level Agreement (SLA). While I fully support the idea of establishing SLAs, since they can set expectations and provide a starting point for dialogue, following SLAs too closely or putting in place more elaborate contracts internally isn’t aligned with Agile tenets.
Contract drawbacks
Internal contracts aren’t Agile for a couple of reasons. First, they put up walls between IT operations and its customers. When one group within a company can stonewall another by refusing help because a service isn’t listed in a contract, it damages the customer (because of delays) and the relationship between IT operations and other parts of the business.
Second, a contract limits collaboration and the spirit of teams. When the disparate divisions in a company realize that there is only one team and we’re all part of it, the productivity of the organization can increase dramatically.
Additionally, internal contracts don’t align with Lean principles because they aren’t enforceable. If a breach of contract occurs, neither party can seek legal recourse. A process that lacks power is wasteful, particularly if the process also limits the work that can be done to support the customer. If an organization requires an internal contract to get work done, there are deeper issues that need to be identified and addressed.
Customer interaction
IT operations teams can use every customer interaction to improve its communication with and services offered to internal customers. Use both formal and informal feedback loops to understand what your customers want. Apply that understanding to close the gaps between the service your IT operations team offers and the support your customers need.
For example, most IT operations teams are familiar with people who always seem to be asking for something beyond the standard available, like a fancy laptop, rogue server, or unsupported software. These are often the same people who seek help outside the regular support process. Rather than dismissing such individuals as high-maintenance, use them as indicators for where gaps exist. What need might be driving the people to seek something outside the norm? Does this need exist more broadly across the organization?
Saying no
Of course, there are times that the IT operations team must say no. Processes and standards help reduce setup and maintenance work, keep our organizations within regulatory and security guidelines, and help us correctly prioritize work. How we say no to our customers is often the difference between putting up walls and collaborating with our customers.
Customer collaboration
True collaboration occurs when IT operations seeks input from its non-technical customers. Create opportunities for your customers to feel they have been heard. Make sure they feel that their needs matter. Let them be involved in decisions surrounding the hardware and software they will be using daily.
For example, you could offer new hires the choice between a desktop with two monitors and a laptop with one external monitor. Try setting up a panel that draws from cross-functional teams to offer feedback and recommendations on software choices, particularly when changing applications that are used by everyone in the company. You might even hold regular IT operations retrospectives in which you invite your customers’ input.
Looking Ahead
In part 4 of this series I will examine how the fourth precept of the Agile Manifesto, responding to change over following a plan, supports an IT operations environment.
Jen Stone Browne
@jenstonebrowne
No comments:
Post a Comment