Ed Ahead Becomes First to Opt In


Ed Ahead proved their namesake on Friday.

Ed Ahead a.k.a., Academy Adventures Midtown, proved “ahead” of the curve in Arizona on Friday by becoming the first LEA to opt-in to the state’s student information system. SSIS, or the Statewide Student Information System, was created by the Arizona Department of Education to allow all LEAs the opportunity to enjoy a state-of-the-art student information system for a low cost.

This system was really designed to assist the smaller LEAs throughout the state, who are currently paying more than 10 times per student costs than larger districts. All LEAs that opt-in pay the same low rate of $10 a student for the first year and $6.50 a student per year thereafter.

In addition, by having technical support readily available through ADE, a small LEA has less of a need for a technology staff. However, those LEAs now have equal access to critical technology, uniform licensing fees and a secure hosted environment.

Check out http://www.azed.gov/aelas/ssis/ to learn more.

CIO Corner: “Fixed” is in the eye of the beholder

The following post is courtesy of ADE CIO Mark Masterson.

I read a lot of publications and sometimes I come across something that actually makes sense. The following article by Paul Glen, co-author of The Geek Leader’s Handbook, emphasizes one of my core values—customer service.

Two little words that destroy your credibility
by Paul Glen
First published by Computerworld on September 24, 2014
We techies have a hard time building and maintaining credibility with our stakeholders. High expectations are hard to manage. Bugs happen. And we get blamed unfairly for all sorts of things that are out of our control.

But we also have a habit of making things worse, undermining our credibility inadvertently and unnecessarily. Probably the most common of these unforced errors comes in the form of two simple words.

“It’s fixed.”

Stakeholders have a variety of emotional responses to hearing us utter these words, none of them productive.

Some respond with excitement and gratitude. “Thank goodness! I’m saved!” If you’re dealing with issues that have no explicit definitions of “fixed,” such as performance problems, their imaginations run wild. They conjure fantasies of systems that work as they wish they would, faster, easier and more reliably than they really do. But these raised expectations rarely survive contact with reality, and when stakeholders’ dreams are crushed, we lose credibility. It wasn’t really “fixed” after all. They feel foolish for having had optimism and blame us for making them feel bad. Even if the problem is clear cut, like an error message, sometimes “fixed” isn’t really “fixed.” They still get the error message, or a new one. And they feel disappointed.

Others roll their eyes in skeptical disdain. “Yeah, I’ve heard that a million times before.” Having been let down too many times, they protect themselves from the pain of disappointment by crushing any hints of optimism. And they judge us as responsible for their negative reactions.

It doesn’t help that we usually tell them, “It’s fixed!” with infectious enthusiasm and pride. We’re problem-solvers by nature and love the feeling of having solved a puzzle. We feel that we’re helping our stakeholders. We feel competent and powerful. And our excitement intensifies their reactions, raising their expectations or triggering suspicion and cynicism.

IT technician answering phone with "Hello, IT, have you tried turning it off and on again?"

Contrary to popular belief, The IT Crowd does not provide the best example of IT customer service skills.

To avoid triggering these negative responses, you just have to remember one simple principle:

It’s their job to declare something fixed, not yours.

If they declared that something was broken, then it’s their job to declare that it is no longer so. Your job is to invite them to decide. You may have to influence the criteria they use to decide, helping set their expectations about what is possible, and how “fixed” something can be. But you don’t get to make that call. They do.

Instead of declaring something fixed, do three things:

  1. Tell them what you did in language that they can understand. “We found two places where we tried to speed up database queries.” “We changed one of the system configuration variables.”
  2. Describe your observations. “It seems much faster now.” “We don’t get the error in the test environment.”
  3. Ask them to try it out. “Can you test it out and see if it looks better to you?”

By asking them to decide, you avoid all the emotional damage wrought by those two seemingly innocuous words. It’s hard enough to build credibility with stakeholders. You don’t need to make it any harder.