I Have a Suggestion, “No more Suggestions!”

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.

“I Spy for the CIO”

I recently came across two interesting articles that got me thinking about the validity of my own work with Agile Project Management (APM).

“Open-Source Spying,” by Clive Thompson, published in the December 3, 2006 of the New York Times Magazine.

“The Political Brain: A recent brain-imaging study shows that our political predilections are a product of unconscious confirmation bias,” by Michael Shermer, publisher of Skeptic Magazine and contributer to Scientific American.

APM’s two tenets are collaboration (community development) and evidence-based (just-in-time) decision-making. For any meaningful collaboration to occur, and to reap the benefits from peer review, all stakeholders must be aware of any and all activity underway regarding the project. Eric S. Raymond, declared “Linus’ Law” as “given enough eyeballs, all bugs are shallow,” or more formally, “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” While this has traditionally been applied in software development, I see the same principle extremely valuable to project management in general: Aren’t your faculty, staff and students beta-testers and your facilities, finance and student life departments, co-developers? Sharing everyones issues (bugs) will not only expose them to more brains, brains that might help resolve those issues, but also help to assess their priority (insignificant to show-stopper).

Is it in IT?

There seems to be a lot of talk about who “owns” various, previously considered IT, services and systems.

I recently attended the SUNY Teaching and Learning with Technology Conference and there was an interesting discussion specifically regarding the place of on-line and distance education within the campus’ organizational structure, particularly one like SUNY with 64 distinctive campuses. (This discussion was really lead by the SUNY DOODLE group)

This same discussion, again specific to on-line education, also took place at another recent SUNY event, the SUNY Council of CIO’s. There I noted that while many campus CIO’s have direct reports responsible for their institution’s on-line/distance learning programs (like I do), many other campuses house their programs under Chief Academic Officers/Provosts, Continuing Education, Business and Finance, etc.

With today’s diverse technology landscape many campuses are struggling with how to organize technology services and systems within the institution. While Information Technology departments have traditionally been responsible for development and support of everything from the projectors in smart classrooms to the the applications they project, other campus service providers (Facilities, Registrar, etc.), and in the case of teaching and learning even faculty, are striving to make more services/systems available to achieve their own specific missions. The result is often tension between the technical staff who must maintain a service or system and the end users who rely on its functionality.

Documentation is like sex…

…when it is good, it is very, very good; and when it is bad, it is better than nothing.
- Dick Brandon

I believe the best way to measure the health of an organization—particularly one devoted to technology—is by how fast someone new can come up to speed with the who, how and why of institutional operations. It’s probably safe to say that, despite the efforts of both parties in the interview process, new members in an organization will not have too much institutional background or operational knowledge. I remember starting at UCLA in the Center for Health Sciences. The corny joke delivered to all new employees during orientation was, “you could run a marathon in the building” because there are over 26 miles of corridor. I couldn’t even find my way through the building to the PACS offices from the Oral Radiology Department , let alone determine the operations and procedures of, and between, the two departments, or the expectations for my role with each (which in the future of my employment actually became quite significant). Obviously this is a pretty common issue and everyone coming into a new role should expect a learning curve. So the specific question is, what resources are available to help those who are new to increase their learning rate? But the larger question is, how can these same materials measure the health of the organization as a whole?