Printer Friendly

Working with technology and technical staffs in research administration. (Shop Talk).

Introduction

In today's research administration environment, we must work more closely than ever with our information technology (IT) staffs. Whether we have our own in-house staffs or work with a central IT office, we cannot afford to ignore the importance of technology in doing our jobs. Electronic searches for funding, proposal submission, and grant management are increasingly commonplace. Technology, once considered more of a behind-the-scenes task, is now part of our overall business strategy and part of the services we offer to our researchers. We are no longer just dependent upon our technology personnel to support us when we have word processing or spreadsheet problems.

To ensure that our researchers have the capabilities to be successful in obtaining and managing external funding, we need to be savvy, not just of technology but also in managing and working with technical personnel. We also need to know how to manage technology projects, whether we are implementing sponsor systems in our organizations or designing and implementing our own systems.

In some instances, we have direct supervisory responsibility over the technical personnel involved in others we must work with people who do not report to us. Some-times the teams we work on will be carefully planned, and at other times we may need to assemble a cross-functional team at a moments s notice to resolve a business problem. Setting some guidelines for the collaboration of different groups who may have never worked together in the past is essential for success. We do not want our technical personnel to merely cooperate with us; we want them to collaborate with us. By providing an environment where technical and administrative staffs truly collaborate to solve a business need, we can achieve better IT solutions.

Communicating with Technical Personnel

Martha K. Heyman (2001), in an article that addresses the importance of librarians working with technical staff, states that "no one would argue that the first step in getting people to hear you is to at least speak their language." Learning basic IT terminology and acquiring knowledge of the tools and techniques that fill the toolbox of the technical person will allow you to clarify your (and your researchers') business needs and contribute more fully to finding the best IT solution. We can then be role models, encouraging the technical staff to develop knowledge of our jobs, as Heyman (2001) notes. This, of course, will also aid in the development of better solutions.

We should also encourage technical personnel to gain a basic understanding of our business environment. Whether it involves sending them to research administration conferences and workshops, or providing more background and training at home, the investment will be worth the effort when technical solutions better meet our needs. In fact, just as research administrators should have basic technical skills, many technical people are now hired and evaluated based in part on their knowledge of business. Consequently, it is becoming increasingly more important for technical staff to have basic business knowledge prior to being hired.

Creating a Team Environment

Given the complexity of designing and implementing technical solutions for research administration, assembling a team is the best way to ensure that all stakeholder needs are considered. The team should consist of technical and non-technical people who will use or be affected by the technology. It should be made clear that each member adds value to the team, and that the team owes its strength to its diverse membership. Great technology that doesn't solve the business needs of the organization has little value. Similarly, simply automating the existing process does not take advantage of the benefits technology can add. A system that works for the administration may not meet the needs of the researcher. As a result, the team needs to have members who will consider the needs to be met as well as how to best harness technology to meet those needs.

Each team should have an identified leader. In most situations, that leader should be someone who knows the business side of the project, in this case, the research administrator. This makes sense since the goal is to achieve the best possible business practice, not just the best possible technology.

Assembling the right team to work on an IT project can mean the difference between failure and success. Harvard University learned this when implementing a new financial system. In the project's early stages, they "had technical teams separated from functional teams, so the right hand and the left hand were not coordinated." (Mora, 2001, p.16) Their next team was integrated, and although it proved more difficult to manage, it was more successful in getting the work done.

At the University of Notre Dame, implementation of MIT's Coeus system involved a team of research administrators, staff, Office of Research technical staff, and central IT staff. There was also faculty input, although we acknowledge that more faculty input would have improved the process and we hope to include more faculty as we begin implementing parts of the system that will impact them.

Sharing Responsibility

It should be clear from the beginning that each member of the team bears responsibility for the outcome of the project. When IT projects fail, there is often a tendency to blame the technical staff. In reality, however, many projects fail because the technical staff was not given enough information, or users of the technology were not given adequate input into the process and/or did not buy into its implementation.

Sharing the responsibility can also help to foster collaboration. When everyone has a stake in the outcome, it becomes more critical to share information. We expect IT staff to take our business needs and provide us with the best technical solution, but if we do not take responsibility for explaining our requirements and uses, we will most likely be disappointed with the final product.

Defining the Purpose

Once the team has been created, it is essential to clearly establish the goals and objectives of the work at the beginning of the collaboration. The purpose must be defined in terms that all parties understand and it should be restated and mutually agreed upon. As discussed above, this is certainly true when administrators and technical staff interact because administrators often do not fully understand the language of the technical staff and our technical staff may have limited knowledge of the business to be conducted.

Both groups must constantly remember that the final goal is to provide our researchers with the tools necessary to seek, obtain, and manage external funding for their research. We should always keep in mind that the processing and analysis of our information should be done by machine to the extent possible, freeing the people to solve other business problems. The business processes and technology employed to meet these goals are not ends in themselves but simply tools that allow us to add value in achieving the missions of our organizations.

Reviewing the Current Business Process

Having agreed upon the goals for the IT project, the team should then carefully examine the current ways of doing business, starting with the assumption that there is probably a better way of doing things. At this stage, we should not even think about the technology we will use, but should focus on the business needs and then examine potential technical solutions.

Many of the things we do have evolved over time and may no longer be efficient or even necessary, especially given the technological change that has taken place since they were first implemented. Sleight (2000) offers some thoughts to consider when reviewing the business process.

A process is not necessarily effective just because it has always been done this way.

A business process is liable to become static and inflexible, while business needs can change rapidly.

IT issues must not be considered until the best scenario for the business process has been devised.

Top-performing [colleagues] should be benchmarked. (p. 44)

The first two items are simply reminders to look for the best way to do things. Technology will allow us to do more than ever before, and it allows us to be both more effective and efficient in doing our jobs. We should especially focus on being effective--on doing the right things to achieve our current business needs.

In our efforts to determine the best business practices, we should also consider the processes of other organizations to avoid reinventing the wheel. We can certainly learn from those who have learned before us, and research administrators are typically very willing to share the knowledge they have gained. If we are designing our own systems, we can learn from the mistakes and successes of others and if we are implementing an existing system, we can better determine if the proposed system will meet our needs.

Even when implementing a sponsor's system m our organization, we should always think of ways that the system can be used to accomplish our own needs. For example, at Notre Dame, we are taking advantage of proposals already available in PDF-format through NSF's FastLane system. As we work towards our target of limiting paper in the office, we see an opportunity to use FastLane to complement our current process of scanning and other electronic filing of documents. The PDF-file is easily saved and filed electronically, which also ensures that we have the final, submitted version of the proposal on file. Although the NSF system was imposed upon us, we are using it to achieve our goals as well. Coordination with our technical staff has been instrumental in implementing this process, from obtaining more server space to overcoming the technical glitches caused by upgrades to the operating system on our personal computers. Physical filing space limitations and sharing files have helped to drive our goal of creating e lectronic files. We have examined a business need and utilized a sponsor's technology to help us meet that need.

Once we have determined our business needs, it is time for the technical staff to suggest alternatives for achieving our objectives. Ideally, the technology and our business needs would be a perfect fit. More commonly, however, there will be some compromises required, but the compromises will be fewer if we use a team approach, consider the business needs first, and then determine the best IT solution to meet those needs.

Conclusion

Technology is a powerful tool that can enable us to better manage our daily business activities. In order to use technology to its fullest potential, we need to first consider what our business needs are, what information we need to meet those needs, and how we use the information. Only after the business needs are carefully determined should we consider the types of technology that will aid us in achieving those goals.

The best way to ensure that the needs of the users are met and that the best possible system for meeting those needs is successfully implemented is to utilize the talents of both administrators and technology staff in planning and implementing systems, whether they are our own systems or those required by sponsors. Input from other users of the system is also important to successful implementation.

In addition, having research administrators with fundamental technical skills and training technical staff in the fundamental activities of research administration will allow both parties to communicate more effectively and determine the best technology available to do the desired work.

References

Heyman, M. K. (2001). Building successful relationships with IT professionals. Information Outlook 5.4: 34, 12. Retrieve at http://www.sla.org/pubs/serial/io/2001/April01

Mora, E. (2001) Financial systems implementation: Harvard's odyssey to oracle and beyond. NCURA Newsletter XXXIII. 3:16-17. Retrieve at http://www.ncura.edu

Sleight, S. (2000) Information technology. Essential managers. New York: Dorling Kindersley.

Pamela A. Krauser, MBA is the Director of Electronic Research Administration in the Office of Research at the University of Notre Dame, IN. Her primary responsibilities are pre-award administration and electronic research administration. Currently Ms. Krauser serves as chair of the SRA membership committee and on the Midwest Section Executive Committee.

This article was developed from a Contributed Paper presented at the October 2001 Annual Meeting of the Society of Research Administrators International, Vancouver, CN. Address Correspondence to Pamela A. Krauser, Director, Electronic Research Administration, Office of Research, University of Notre Dame, 511 Main Building Notre Dame IN 46556. E-mail: Pkrauser@nd.edu
COPYRIGHT 2002 Society of Research Administrators, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2002, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Krauser, Pamela A.
Publication:Journal of Research Administration
Geographic Code:1USA
Date:Apr 1, 2002
Words:2059
Previous Article:Benchmarking in sponsored programs administration: using the web to analyze nationwide data collection results. (Shop Talk).
Next Article:Learning adobe tips.
Topics:


Related Articles
Telemining pioneer seeks position as university chair.
Considering the Human Element of Electronic Research Administration.
In this issue.
Market research sans budget. (Marketing).
Short supply: most shops have lost technical muscle, a gap that the shrewd supplier will fill.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters