My fundamental assumption: Our university family is a mix of senior and junior learners where senior learners assist junior learners as they prepare for a productive career. A well prepared junior learner know what he/she does not know and also is a skilled problem solver.

Within university communities, I see no reason to distinguish between students, patients, faculty and staff. Problem solving is facilitated when resources are within reach of wherever you are. Said another way, data/knowledge transport enables the end uers to do their job, be it learning, processing a requisition, treating a patient, solving a research problem or repairing a motor. If I am successful in facilitating the transport of data to a member of our university family thereby enabling the end user with all the resources required to solve a problem, then I'm pleased.

The IT Lab was my response to our IT outsource contractor at MUSC. My experience is that outsource contractors are often driven by what was convenient which can lead to a rather disabling IT infrastructure. For example, when I arrived at MUSC, here was no supported off campus access to the MUSC network, databases were inaccessible and there was a rather rampant ignorance of what the Internet in general and specifically internet-accessible web resources brought to the learner's table (whether researcher, junior or senior learner). The rational for not supporting off campus access was that there were insufficient support staff. While a dial-up service was available, the outsource contractor perceived that without an adequate staff to support off campus computers, it was better not to provide the service. There was no measure of "adequate" staff and apparently, our outsource experts felt that off campus access to MUSC was so different than off campus access to any commercial service that it could not be supported.

The IT Lab and its activities were my tools for building enabling IT resources that were accessible by all members of the MUSC family. The IT Lab provided and alternative to our outsourced contractor and provided proofs of concept that displayed to the university community that many "perceived" obstacles to enabling the MUSC IT infrastructure were just that - perceptions that were not supported by data acquired through proof-of-concept experiments.

We were driven by issues raised by the Provost and other leaders within the Provost's office. The success of the IT Lab was a result of not only a group of very talented individuals, but the chemistry of our work environment and our avoidance of hierarchical management. Many of the items below were obvious after they were articulated - but articulating them was a challenge.

Core themes

• All our effort must be directed toward building a univerity (MUSC) that was greater than 6 colleges + hospital
• Our infrastructure must be enabling, not disabling
• Our infrastructure must amplify the innovative potential of students, faculty and staff. (see Shifting Innovation with Toolkits)
• We must facilitate learning, not teaching
• We must facilitate patient care, not diagnosis and treatment
• We are problem solvers, not workers. This means that there is no boundary between learning and doing. Learning is an integral part of problem solving. Thus, continuous learning happens because of the way we view our job; that of solving problems (and enabling others).
• We must partition each problem into two components: a data transport/data management component and a process (business, learning etc) process. We strive to resolve the transport/management component within a few days, realizing that enabling the process requires longer because of collaboration between the IT transport specialist and the staff, student, faculty specialists. Solving the process part of the task is facilitated by the immediate availability of a rapid prototype that displays the required information.
• We must reach out to the community and enable them as affiliate members of our family. I am involved with Frierson Elementary School and exploring how to ignite the curiosity of young learners.
• We must craft our web pages to facilitate learning. We have struggled to achieve this goal with the IT Lab web site . Rather than a web site of links to our resources, we want our site to be a place where one can learn about our ideas and how we develop them with prototypes. I have explored different strategies for sharing insights and igniting curiosity via my web site with varying degrees of success.
• We must publish both documents and abstractions via RSS. Why? RSS provides automatic notification of web site changes, saves clicks and avoids your having to remember URLs of linked stories.
• Automatic harvesting web resources followed by display of consolidated information saves clicks and avoids remembering URLs. In other words - you can retarget brain energy from clicking and remembering to thinking and problem solving. Our Atlantic and Pacific Weather pages provide one stop shopping for approaching hurricanes and cyclones.

  Operational themes

• We are problem-driven, not tool-driven. We focus on clear articulation of our colearner's problem. Specifically we want to understand whether resolving this problem will lead to an action. Problem solutions that do not lead to an action are less useful than solutions that lead to action. If the problem does lead to an action, then we push to understand the input to the problem, the output and the action. Sometimes the solution will result in reengineering an existing process (and possibly not an IT issue, but we must accept the role of messenger) - other times the solution will identify the need for a new process. At all times, we do not expect the learner to articulate an IT solution. Rather we want to understand enough of what the learner is trying to do so that we can craft an acceptable solution that meets the need.
• We harvest resources from internet-accessible locations. Whether software tools or domain-specfic information, the idea is to either manually or automatically harvest what is available and build on a foundation of harvested products.
• With our knowledge transport tools, we strive to demonstrate to the end user the data/knowledge transport component of a problem within a few hours or at max, a few days. With a web accessible prototype that displays the requisite data, we put our student, staff or faculty colleague in the driver's seat and enable them to identify the process issues. Together we activate the process. This strategy achieves two important goals: The end user becomes the rate limiting step in solving a problem, so IT schedules are, for the most part, unnecessary. Because the end user is in the driver's seat, identifying the process issues and assisting in evolving the prototype to a finished product, there is no need for training. Training occurs as part of the development process.
• We must build our activities around data repositories created by our institutional systems systems (finance, hr, patient care). We must construct our solutions with compositions of tools, and minimize building new systems wrapped around core systems.
• We must base actions on data, not speculation
• Experiments are ok - they produce data. Committee discussions are often of marginal utility - and can produce speculation and fantasies
• We must accept 80% solutions - simply because there are no 100% solutions. Why? Because we cannot predict tomorrow with 100% certainty.
• We must grow our infrastructure - not roll it out . MUSC will not remain stationary while we prepare what we roll out.
• We strive to craft a prototype solution within a few hours or days after understanding the problem. Typically we start our project with one IT labber and a single member of the MUSC family. This prevents scope creep and facilitates rapidly engaging the user. Because we are tool based and problem driven, our solutions are suitable for changes in the problem description as the user gains experience with our prototype. Typically, we seek to avoid problem specification with a large (> 4) people simply because it makes the prototype impossible to develop. Similarly, its much more difficult to engage 4 users in the prototype than to engage a single user.
• Our IT infrastructure is standards based and provides core web-accessible services including email, shared storage, web services and calendar services
• Our infrastructure must facilitate exchange of knowledge among local and distant learners by email, voice, video and data.
• Our infrastructure must facilitate transport of knowledge from resources to your desktop
• We must enable students, faculty and staff (here I'm referring to the traditional characterization of any university) to manipulate knowledge we transport so that they can produce the documents they prefer
• We must take ownership of our problems - not implicitly or explicitly assign them to a nebulous third party "they".
• Our infrastructure must serve the role of coordinating distributed activities
• We must have a group of energized, creative and out-of-the-box thinkers and prototypers that can outline the direction for tomorrow's production work. Within the IT lab - I am the senior learner and I have 7 serious junior learners. The junior learners are free to provide me with their best insights and can make no mistakes. If non-IT labbers consider that we made a mistake - then its because I directed the effort and therefore its my error . This results in a group of hyper-productive and self-directed individuals - as the results below indicate. Our deadlines are continuous because we are growing solutions to meet someone's need. The best growth occurs when both the IT labber and the needer are actively engaged.

  Themes Driven by Compliance and Security

• We must realize that we are increasingly compliance driven (FERPA, HIPAA, FDA good laboratory practices, medical reimbursement, IRB, Risk Management) and our infrastructure must support rapid development and deployment of compliance-related sensors and centralized monitoring of these sensors. Federal regulations from on high
• Unfortunately, people misbehave and violate our implied trust. Thus we must evolve a risk management strategy with respect to the security and integrity of our network infrastructure and associated information repositories that does not seriouly impede getting the day's work done.
• Then there is malware (viruses, worms etc) that are released into the Internet wild. We must aggressively scan for vulnerabilities and educate students, faculty and staff about the risk of infection and the resulting loss of network integrity. We must view our policies as similar to public health policies. A child will not be admitted to the public school without proof of vaccination. Similarly, vulnerable computers will be disallowed on our network if vaccination is not immediate.

  Our responsibilities

• We must engage all members of our family to accept more responibility:
  1. Curiosity is rewarded - if you don't understand something, the chances are very good no one else understands it either
  2. Committees generally produce consensus results - that often lack originality and creativity. Individuals often produce original and creative solutions to critical problems. Committees operate on a time scale dictated by the slowest member of the group. Individuals work at a much faster rate by avoiding the consensus process. Committees diffuse responsibility and ownership of problems and solutions to the point where often, no one can fail and no one can receive credit for a success. Clearly, I accept that group processes have their place - but we seem to opt for group processes over individual processes
  3. We must accept the culture shift required to realize a transition away from dependence on our IT infrastructure to prepare reports and documents to our preparing our own reports and documents. In a business sense, depending on IT for report generation (except for routine stuff) is a cost shift from ourselves to the IT group. It really does not make sense to place report generation in the hands of a $100k programmer instead of a $30k junior learner. We take our enabling role very seriously.
  4. Information available from our infrastructure is confidential
  5. Information entrusted to me, on my desktop, laptop or PDA is my responsibility
  6. Learning is continuous. Asking google.com before you ask a colleague facilitates continuous learning
  7. Share your knowledge with others
  8. Internet memory is more reliable than our biological memory. We must focus on developing tools that facilitate access to specialty knowledge. Google is a good example of enabling a junior learner to access facts and concepts from the world. Differentiating quality information from trash requires an internal absurdity detector - a new skill essential for internet-centric living. As an infrastructure component, we must facilitate learners in our institution with separating good stuff from junk.

Our action plan for migrating to our Internet-centric paradigm

• Our major obstacle to change is cultural, not technical. Every trick we identify that helps us overcome cultural obstacles must to be shared with others. Someone probably should keep a list of specific cultural obstacles we encounter. The IT Lab Wiki is the latest step in sharing ideas and insights. Our wiki supports collaborative writing by many members of the MUSC family.
• We shall use repetition to help others understand what we are doing. For example, we are rebuilding the MUSC web site. The central theme of uniformity will be achieved by using either the internal or external hat that will facilitate navigation across MUSC resources.
• Lead by example: A major challenge is to figure out how to change a report-expectant group of users to shift to a do-more-for-yourself perspective. Since we don't know how to do this,we must take ownership of each user's individual needs and figure out how to shift the needs from report-driven needs to knowledge transport needs. My notion is that after we work with 10 or 20 early adopters, we'll begin to see general trends that will lead to how tos, tutorials and perhaps instant messaging-like help resources. I believe that the majority of our solutions will involve report generation using Excel or something like Crystal Reports, driven by data transported by our tools from a database to your desktop. Thus we need to accumulate examples of "how I generated this document or how I generated this report"
• We'll start with early adopters. This means that our initial efforts will be focused on helping the Finance division realize their goals. Lessons learned within Finance will be made available to the hospital and academic groups.
• Our transition will be incremental, with a minimum of formal training and a maximum of co-learning. IT-enabled folks will be the senior learners, and our non-IT colleagues will be the junior learners
• Succeeding with a few early adopters will encourage others to follow (by example). We need to find a way to reward early adopters and early followers.
• We need to help our co-learners to understand thinking, learning, analysis, and doing in an internet-centric setting. We are all learning as we go along. Learning to effectively use google.com appears to be a new essential skill for an internet-centric workplace.
• Implementation schedule: At this point, we are using our early interactions with the Finance division to guage the time required to overcome cultural obstacles and shift our activities to internet-centric workflows. I think 2-3 weeks/application is a good initial guess. Our progress depends on the number of senior learners we can dedicate to the conversion. The more senior learners we can invest in the transition, the more parallelism we can generate in our conversion and the faster we will become internet-centric.
• more later - because this is new territory for me

Our results to date

• I established the IT Laboratory as a forward thinking group of innovators that are charged with developing internet-centric, browser-accessible tools that enable our students faculty and staff to transparently transport knowledge units from a variety of resources to their desktop. This transportation function is the key to our transition to an internet-centric university.
• IT Infrastructure Policy Richard has a number of works in progress
• Computer Use Policy An agreement signed when a network account is established
• Richard's survey of wireless infrastructure issues
• Our MUSC web site for external folks Collaboration led by Brian and Brian. The navigational hat will appear on all primary MUSC web pages - its what tells someone from the outside that they are dealing with a university not 6 colleges and a hospital. The left side-bar is for department, division, center, lab, or personal site navigation
• Our MUSC Portal - customizable for individual needs Brian has at least one good idea each week. This was his best. An internal navigational hat that will appear on MUSC sites that are predominantly for internal use. Our portal provides a platform independent way of accessing institutional resources from anywhere. Moreover, it provides a way for individuals to adapt the content box offerings to their specific need
• Tools to check spelling, check status of Purchase Orders and Requisions, access the paging system, track contents of open source repositories, security alerts, etc: see myMUSC content blocks
• We are building libraries of tutorials to facilitate learning technical skills. Our information location and transport tool Each website reflects a web interface to either a legacy or current database. The search engine permits asking simple questions - our 80% solution. More complex questions can be asked via a GET pointed at the search engine. Data transport is available as either HTML, text, Excel format or with XML tags. Brian translated my ideas into reality with the trick of changing the mime type (another good idea) to facilitate tranport of data to an Excel spreadsheet.
• A web accessible IMAP mail tool from Matthew, who is always a step ahead of all of us and a minimal function (no folder management) IMAP email resource. When our primary mail server died - Matthew, OCIS and the IT lab had a backup operating within 12 hours
Josh, (an IT lab graduate) built our suite of tools for building web accessible interfaces to institutional data repositories.
• mySiteMaker: An overview of our data transportation project Josh crafted this as our workhorse web interface for database retrieval
• Our approach to workflow management Brian started this, Christopher picked up the ball and jabberized it - a major major tool for MUSC
• Automatic notification: enabled by combining RSS with workflow management
• with Jabber Christopher made this a reality and demonstrated how to facilitate communication among IT labbers and MUSC. Authentication is based on our authentication daemon
• A survey tool Matthew found this, pressed the development group and became a developer
• What do I do? I'm the cheerleader!!!