You'll Never Believe This

I have this crazy idea. I want to form a committee. I know… but I really do. I have this idea for a service that the University should have. (Notice I didn’t say who should provide it or even what “it” is.) I’m thinking this service has a transport component, so TNS should be involved, but I don’t want to make it a TNS committee. I’m also thinking that there will be an authentication component, so AIT should be involved, and of course there is a security component, so SOS should be involved, and yet I don’t want to make it an ITS committee. I’m thinking this will have a distributed IT component — you know that IT at Penn State is bigger than ITS, don’t you? But I don’t want to make it a Penn State IT committee, either. This service has a huge end user component. After all, what is the mission of IT at Penn State if not to support the University’s teaching, research, and service missions? And, what are those if not the embodiment of our faculty, staff, students, researchers, and so on — the users of our services.

You begin to see why I don’t want to narrow the focus of the committee too much. I have this crazy idea that a service should be formed with input from all of the stakeholders. It should address real users’ needs and wants, rather than the imagined ones of a middle manager on the IT staff (wherever he or she may be ). Certainly, they are stakeholders, as well, as I’ve already mentioned, but not the primary ones.

I’d go into the particular service, but it is not pertinent. You can see that this is a general problem. How do you get input from 107,000 people in any kind of useful, constructive way?

There are some things I’d like to accomplish in this committee:

• Convince the stakeholders that they have a stake in its success
• Identify how the group can work together
• Do an affinity analysis to help define the user needs
• Identify and define use cases
• Establish a desired future state
• Determine functional and non-functional requirements
• Identify and prioritize essential, desirable, and optional features
• Do a gap analysis

Out of this would come enough information for the appropriate people to go off and decide whether the service is feasible, and how to provide it. Of course, given a sufficient mandate, appropriate people would then go on to develop it in an agile way, providing early access to core functionality and features. Adding more features based on the original specification and feedback from users, administrators, and the committee.

So… Does anybody have any idea how to go about this? What has worked for you?

Share: Delicious | Facebook