All Hands Team Building Exercise

At AOL, we seemed to thrive on doing team building events. I haven’t done any since I’ve been at my current company. My first team building event that doesn’t involve drinking at a bar is tomorrow at our all hands.

At our September All Hands meeting, we are going to spend most of the meeting reviewing the data and comments from the Customer Satisfaction Survey we did in August.

In addition to the normal project updates, and priorities, this one will involve a team building exercise. Here’s the instructions:

• Breakout the department into teams of five people who they normally don’t work with.
• Review the customer satisfaction survey results.
• Propose five recommendations to address low scores.
• Post their recommendations on our IT Ops Wiki page.
• Appoint a spokesperson and have them present the information back to the entire department.

They’ll have 20 minutes to perform the exercise. The goal is have people come out of their shells and meet other people in the department. A secondary and equally important goal is to give a real life example of how easy it is to post content that is available to everyone via a Sharepoint Wiki.

Sharepoint isn’t just for posting files in document libraries. It can be much more. Hopefully this team building exercise will leave an impression with the team that will help them think differently about how easy it is to collaborate.

I’ll post the recommendations once they are done. This should be fun.

Application Portfolio Management: An Overview

One of the challenges of introducing fancy terms is people will think that you are using a 25 cent word when a five cent word would do.

That was my initial concern when I brought the term Application Portfolio Management to my company. APM was a dream in November and December when I started with my current company so I just kept it on the shelf and hoped that one day we could get to it.

In March of this year, the daylight savings patch project hit. The first thing we had to do was work with the existing team to identify how many servers we had. We had no clue. The list of servers and locations created the first authoritative list of systems. We plowed through the DST project but a bigger accomplishment occurred. We now had a list of servers.

It would be easy to call the initiative “server consolidation” because technically we are reducing the number of servers we have. But server consolidation is a tactical, operations only focus on the real business problem that needs to be addressed. We don’t have a problem of too many servers, we have a problem of too many systems and applications that the business has asked us to support on their behalf.

APM forces IT to engage the business on agreeing to the right level of hosting necessary to support the business goals. APM looks not at servers and physical boxes rather it looks at the applications that run on them that are in service of some larger revenue or expense goal. If we are hosting an application, APM demands that the application have an owner in the business that has signed up for the value said application is delivering.

But the first step is to build a list. The second step is to pull together the list of systems and departments assigned to those devices. Once we have the business signed up for their servers, we can then help them rationalize the number of applications and systems it takes to run their business units.

Phase one of APM is gathering the list of devices and making the easy decisions regarding how many prod, dev, and stage servers we have and if any of them are candidates for decommissioning. For a small company that has grown rapidly, we have built a large list of candidates for decommissioning over the years.

The second phase is to gain finance support for allocating the cost back to each department. This is where we really gain traction on the APM initiative. We have real dollars that we are spending that can be saved through APM phase 2. Right now, IT eats that bill. The business is not incented to reduce the number of systems we have in our three environments. By presenting a hosting cost by business unit, it helps the company bring down its expenses by determining if systems and their applications are really worth the money we are spending to maintain them.

We’re on our way and with IT, Finance, and the business support, we’ll be able to lower our company’s operating expenses while improving IT’s responsiveness at the same time.

 

Common Characteristics of High Performing IT Organizations

• High service levels and availability
• High throughput of effective change
• Higher investment early in the IT lifecycle
• Early and consistent process integration between IT operations and IT security
• Posture of compliance
• Collaborative working relationships between functions
• Low amounts of unplanned work
• Server to system administrator ratio greater than 100:1

source: The Visible Ops Handbook, Implementing ITIL in 4 Practical and auditable Steps

Change Control Questions

“Who” Questions

•  Who will be affected by the change? Ensure that there is appropriate representation on the CAB to make decisions.
• Who could be affected by the change if it fails?
• Who from the potentially affected group(s) has signed off on the change?
• Who is performing the change (the “change builder”)?
• Who has reviewed the proposed change?
• Who is the project manager if this change involves more than one step?

“What” Questions

• What assets are the targets of the proposed change?
• What is the change timeline?
• What is the change review priority based on the associated risk and urgency?
  • Urgent
  • High
  • Medium
  • Low
• What assets or processes depend on the targeted assets?
• What will the successful change look like when implemented?
• What business processes need to be verified after making the change?
• What is the business or technical reason for the change?
• What will happen if the change is not made?

“When” Questions

• When will the change be performed?
• When will it be finished?
• When will the benefits of the change be realized?

“How” Questions

• How will the change be implemented (in waves, one at a time, etc.)?
• How will we verify success?
• How will issues be escalated?
• How successful were similar changes in the past?  (i.e. change success rate)

“What if” Questions

• What is the back out (rollback) plan if the change should fail for some reason?
• What is the worst possible outcome associated with this change?
• What will the worst case service outage be?

Ron’s IT Operations Golden Rules

1. Protecting the production environment is our number one job.
2. The first part of protecting the environment is protecting the data. Backups are critical. Everything can be interrupted to ensure we get a clean backup.
3. The most important part of your change control is the back-out plan. If it all goes to heck in a handbasket, you can quickly get back to a good state if you have already planned your recovery in advance.
4. There is no such thing as minor change.
5. Nobody is indispensable…but all of the DBAs are forbidden to cross the street at the same time.
6. It’s only money. Don’t let that get in the way of doing what’s right.
7. A policy without compliance and auditing is a wish. As in “I wish they would do what I said.”
8. What gets measured gets improved.
9. You don’t understand the problem until you can express it mathematically.
10. Never say no to a user - just put a price tag on yes.

11 Traits of a True IT Leader

1. Fluency in both technology and the business
2. Ability to work at tactical and strategic levels simultaneously
3. Foresight to connect disparate pieces into cohesive solutions
4. Flexibility
5. Commitment to lifelong learning, with a readiness to stretch beyond core competencies
6. Marketing competence
7. Consummate communication skills
8. Ability to find and manage top talent
9. Vendor management expertise
10. Project management excellence
11. Willingness to delegate

Source: “Ones to Watch”, CIO Magazine, 7/15/2005

Help for the Help Desk

Describe your level of statisfaction with your company’s IT help desk in the following areas?

1. Courtesy
2. Availability
3. Expertise of the help desk
4. Timeliness of updates regarding your issue
5. Availability to resolve requests in a timely manner
6. Availability to resolve requests the first time around

Source: “Help for the Help Desk” , CIO Magazine, 7/15/2005

The Toolkit methodology

Step One: Hunt & Gather

• Interview business customers and stakeholders
• Interview staff. Conduct 1:1s and meet and greets with your organization.
• Interview your boss.

Step Two: Synthesize

• From what you have learned, identify top 5 frequent themes from interviews.
• Communicate themes back in the form of top objectives for your department for consensus.
• Communicate themes to your boss for consensus and alignment.

Step Three: Communicate the Vision

• Use the top 5 themes as your organizational strategies for the department.
• Use the four perspectives of the balanced scorecard to ensure you are covering financial, customer, internal process and people in your strategy.
• Create metrics that would be leading or lagging indicators of how well your department is achieving it’s goals for each of the five strategies. Ensure they are in a BSC perspective so you can look for balance in your scorecard.

Step Four: Operationalizing the Strategy

• Use predefined templates to create a clear understanding of what the definition is of each metric along with it’s actual baseline if known.
• Agree internally within IT first on a end of year target. Use this as a starting point for discussions with stakeholders.
• Produce bi-weekly or monthly scorecard. Ensure each metric has an owner who is responsible for improving performance.
• Approve projects and initiatives that directly support improving the metrics. How will this initiative help us reach our target for the year?
• Allocate resources to projects based on impact to the metrics not based on organizational politics and alignment. Do the right thing not the easy thing!
• Hold Monthly System Quality Meetings with your direct reports to let them know that you are overseeing the progress.

Never trust your company to keep organizational secrets

I was reminded last week that no matter how confidential you try to keep a job search, someone inside the company will let the information leak. The best strategy is always to tell your team that you are sourcing for a new position in the department before you actually extend an offer to a candidate. In the long run, it’s better to just tell people that a search is going on and manage the message instead of them hearing through the “HR grapevine” that a candidate accepted an offer.

One of my favorite books is “Good to Great” by Jim Colins. I forget to implement his cardinal rule for change management which is “tell the brutal honest truth.” If I had done that earlier, I wouldn’t have had a team walking around wasting productivity wondering who the new guy is and if they are a) losing their jobs, or b) being pushed down the org chart.

IT is like pulling babies out of the water

I had a mentor once that described life in IT in the following manner. I think it’s a great story about the difference between being a tactical thinker and a strategic thinker.

A man was sitting by the edge of the stream one day and noticed a baby floating helplessly down the stream. He dropped the book he was reading and immediately jumped in the water, swam out, and got the baby and brought it safely back to the shore. As he put the baby on his blanket, he noticed that another baby was also floating down the stream. He jumped back in the water and swam out and saved this baby also. As he placed the second child safely on his blanket, he noticed a third baby in the water. Tired and exhausted the man jumped in the water and struggled, but successfully pulled the child out. As he turned around and saw the fourth baby in the water, he took several steps, clutched his heart, and fell dead on the side of the stream.

Sadly, the man never journeyed the 100 yards to the top of the stream, where he would have found the person who was putting the babies in the water and stopped him.

What does this have to do with IT?

Like the man who was too busy doing his job, IT leaders don’t stop long enough to look at what independent variables are causing the workload to grow within their organizations. We are constantly trying to be the heroes who save projects, write applications, and deploy systems when it is killing our teams. Instead of going the 100 yards upsteam to stop or at least retard the demand on IT services, we stay in the water waiting for the next baby to come down the stream. We’ve been in the water so long that it seems a normal way to behave.

What can you do about it?

Unfettered demand for IT resources is not sustainable. The costs are measured in sick time, attrition, and recruiting costs. To retain your staff, your leadership team, and your sanity, you need to inject a governance process into your organization. One thing you can implement quickly is a “Plan of Record.” A plan of record is the authoritative list of IT projects that have business sponsors. This list is critical because it lists, at a minimum, the name of the project, the expected completion date, the business owner, and a rough estimate of hours and dollars.

Once you have a PoR, you can now engage your business units in a discussion of their projects and their competiting demands on your resources. When you sit down with your business owner, you can have a fact based discussion like the following, “Jim, I am workingon four projects for your division, this new one is going to use the same resources as the other four. Can you help me prioritize which ones I should be working on first?”

As IT leaders we can take control of how many babies are being put in the water by going upstream and solving the problem on the front end. Using a Plan of Record as a tool for face to face meetings with your business partners help everyone reduce the frustration and sense of being a hero pulling projects out of the water.