I Have a Suggestion, “No more Suggestions!”
January 23, 2007 § 1 Comment
It seems like when organizations begin to explore “community” one of the first suggestions is to create a suggestion box. The idea is that end-users and stakeholders can contribute directly to the decision-making of the IT department by suggesting some of the hot topics they would like to see addressed. From these requests, the IT staff will not only learn of the important issues facing users, but also be able to use the information to help prioritize their project list. In theory it sounds great. This transparent process, it is hoped, will engage users, identify future projects and even define priorities.
While the overarching strategic goal—involving the community—should be the basis for IT decision-making and development, suggestion boxes and similar tactics (surveying, committees, etc.) that provide unqualified directions will, in the end, prove detrimental to the department’s operations and reputation.
Suggestions, while coming from the real-world (your users) do not necessarily reflect real-world needs and may not actually be aligned with the business processes, operations or objectives of the community who offers them. Suggestions are open-ended and essentially ask the question of your stakeholders, “If you could have anything, what would it be?” It’s not that the suggestions are ridiculous or impossible to provide, but they may not actually represent enhancements to the working environment. Pod-casting can be a valuable tool for teaching and learning and student recruitment, but does the person who made the suggestion understand the associated resources required to provide this service, from the technical (e.g. data storage and bandwidth) to the support staff (e.g. content and editing)? Do they understand their own obligations? Can they provide real life examples of, not only how it will be implemented, but how it will contribute to the vision, goals and objectives of the department?
Providing a 24/7 help desk sounds like a great way to increase support to end-users, but it may be impractical based on actual need: how many users are online Sunday night at 3:00 a.m.? Is there available staff? Is it a help desk service or training that is actually needed?
Do you really want to undertake projects that might be outside your scope of services or require expertise outside current staffing with unknown institutional return on investment? Are there mechanisms for assessing the risks of such projects?
In addition, many suggestions may be contradictory, “We should provide email to students to ensure communication,” “we should cut email services to students, they already have their own accounts,” or, “we should centralize web development,” vs. “we should allow departments to edit their own web pages,” or, “we should provide Jabber to all faculty and staff, just like email,” vs. “we should restrict IM use.” While both sides of the argument may have anecdotal (personal experience) or circumstantial (based on a personal agenda) evidence, is there any way to actually qualify a decision? Even those with apparently similar suggestion may expect different outcomes—is pod-casting for teaching and learning or student recruitment (if it’s both, have we doubled the scope of the project)? How do you ascertain the project goals in order to measure quality of service?
One might use a suggestion box as just a starting point, a way to get a sense of where users’ interests are. However no matter the appropriateness, scope, scale or practicality of the request, how do you manage expectations? The presumption might be, if I make this suggestion, it could happen. Are projects initiated based simply on volume? Or, are they based on the position of the person in the organization making the suggestion?
In a previous position, the organization had four different points of contact for collecting request/suggestions/issues online. Three different groups maintained individual lists. When I came I merged the list and found over three hundred individual suggestions—some six years old. I can just imagine “Fred” out there, “I’ll wait one more year, then they’ll implement my suggestion!”
Even more dangerous for the department (and you), if the suggestion is politically motivated, IT may be seen as an accomplice or obstacle.
Management of the suggestions, if you are really going to use this as part of your needs identification and analysis (i.e. collection, assessment and communication with those who submitted suggestions), will consume significant resources for questionable return. Even if you do find an interesting suggestion, how do you qualify it? Again how does it actually align with the strategic goals of the institution, organization, department or stakeholder?
As I read over the above, I wonder how far away “suggestions” are from “initiatives?” That is, my gripe with suggestions are that they come from left-field based on unknown reasoning (assumptions) and motivations. So, do the same arguments I voice above regarding suggestions apply to initiatives sponsored by the executive management? I better stop here!
So then what? How can you not only provide, but foster, community and collaboration for defining and prioritizing projects that align with departmental/institutional vision/objectives? I would suggest implementing an integrated service center. The Information Technology Infrastructure Library (ITIL) defines the service desk as “the single point of contact between users and IT Service Management. Tasks include handling incidents and requests, and providing an interface for other ITSM processes.” I am not a big fan of ITIL’s process-heavy approach, but I think the concept here is right on. Using a service desk, help desk, customer center, whatever you may want to call it, should be your sole (soul?) interface with the community.
Specifically regarding the identification and assessment of needs, the service center should be able to provide you and your stakeholders with the real-world needs based on the feedback of end-users. This evidence-based approach creates an environment where projects emerge based on issues reported.
As ITIL recommends, the service center collects all “incidents and requests.” As end-users call in to report problems, or ask for assistance, issues are recorded. These issues are then rolled up into monthly reports that will identify specifically what development should be undertaken. IT is then able to provide stakeholders with not only a list of projects, based on their current business critical functions, but priorities as well. If students are reporting difficulty applying online (23% of student contacts), connecting to the dorms’ wireless network (18% of student contacts), and problems remembering log-ins (12% of student contacts), we have just defined projects and priorities for the Office of Student Affairs.
The issues reported and resulting prioritized projects also provide a segue for the requirements gathering process. If you are using use cases (note: future blog topic) to define the functionality and features of your services and systems, the issues reported by end-users is a great starting point. Calls coming such as; “when I try to log-in in the dorms I can get online in my room, but not in the lounge,” or, “when I try and log-in in the lounge, I can only get onto the public domain, not ResNet,” etc., all can be used as the starting point for developing different wireless access use case scenarios.
In addition, the issues reported can also be used to measure success: accessibility in the dorms to the ResNet network. Each incident represents a real world target that can be achieved, not a concept or vision.
A service desk informs you of a problem: “I can’t connect to Resnet.” A suggestion defines a solution: install more wireless access points, install more Ethernet jacks, increase bandwidth, provide easier log-ins (SSO), implement a “forgot my password” function, implement in-line help, increase the help desk hours. Which one of these “solutions” will solve the “problem” regarding student access? All of them potentially, or none of them.
But, “I can’t connect to ResNet” isn’t good enough. Unlike a suggestion box, where the context for the suggestion may be ambiguous, information collected in a service center can be specific:
Suggestion Box Scenario:
Student can’t log into ResNet, screen states ” ‘invalid user”. Student goes to http://www.campus.edu/suggestions and enters, “Please provide a way to use one user name and password across campus.” IT staff interprets this as a single-sign-on suggestion, add one vote for SSO.
Service Center Scenario:
Student, “I can’t connect to ResNet.”
Analyst, “Can you see the ResNet log-in screen?”
Student, “Yes, but when I enter my user name and id, it says, ‘invalid user.’”
Analyst, “Can I have your campus log-in?”
Student, “Sure, its jsmith, 12345678”
Analyst, “Hmm, it looks like there is a hold on your registration fees, your access is on hold until you clear it with the campus police. Looks like some outstanding parking tickets.”
Student, “Ah, ok. Thanks.”
In this example, the real issue was one of Student Information Systems and notifications. If in your data collection (incidence reports) you find that the majority of connectivity issues are based on student holds, then no matter how you build up your network infrastructure, your “connectivity” issues will persist.
Using an evidence-based approach also lowers project risk. Because all off your projects emerge from the issues raised with your stakeholders regarding actual business operations—which constitutes your current services and systems—your department will already be staffed and resourced to take on development. The staff will already be familiar with the technologies that support the system, the role those technologies play in providing operations, the current functional expectations of stakeholders, current use and usability and any vendors, partners, contracts, licenses, etc. that provide additional support. From this perspective, projects are better labeled “tasks” or “enhancements.” Issues may be fixed, e.g. a bad digital projector in a classroom (a task), or services/systems can be enhanced, e.g. adding access points for more coverage in the dorms. The scope and scale of services still expand, but along familiar routes.
With initiative-driven development, IT departments have to connect the dots between new, and potentially disparate, services and systems. With evidence-based development new services branch from existing as demands change. Like the evolutionary tree, where environmental demands create unique species through incremental iterations, each new species based on a previous success, yet slightly different to better meet the new conditions, campus technology should also be an evolutionary process. Working from existing successes (i.e. implementations) and the known, must be a better process than taking on the unknown with limited experience.
Above: Feedback from users add functionality through time. The issues raised are based on real-world use of existing systems. Once the web page is up, users recognize the need for a uniform look and feel. Once more people are online, users need more than just content, they expect interactivity (forms). As more content and functionality comes online, users need content manaement. Administrative content leads to academic content management, and so on. Each enhancement is only an incrmental advancement in functionality and technology. The majority of staff, skills and infrastructure needed for the enhancement are already in place supporting the exisitng service/system.
Above: Suggestions or initiatives may not be rooted in existing services. Therefore their development may require staff, skills, or infrastructure not currently available within the IT department. This is a huge risk as there is no one who can accuratly assess the departments ability at successfully inplement the initiative. Interestingly, becuase the staff will need to learn and implment many of the critical technologies required to implment the initative, timeframes and total costs will be same as in the evolutionary approach. Again, however, because development will focus on discovery rather than application, it can be presumed that costs, time and overall, risk, will increace beyond the comfortability of senior management, end-users and your own department.
Implementing a service center is more than providing help desk services, if done correctly it can be the focal point for identifying not IT needs, but campus needs—an emergent process where the themes captured from user feedback presents future development. If you believe you and your IT department should facilitate and not mandate (if you’re tired of out-of-the-blue top-down initiatives), then providing your stakeholders with real-world user feedback for evidence-based decision-making will create the appreciative and collaborative community you are looking for. You can take control of project development based on needs and not wants. So please consider my suggestion and drop the suggestion box.