Projects: perception, scope, and goal
I’m not suggesting a cage match, or even that one group is right, and the other is wrong. I just want to shine a light on a few differences and see if we can resolve to develop a process that will make project development a more enjoyable process for all.
I find that IT staff prefer to segment out their portion of the work involved in a project. As soon as non IT staff have come to a decision about how something should look or operate and are at the implementation stage they should draft a document that explicitly states how project X should operate, and maybe even sketch out what it should look like. At the end of IT development they would hand the project back to non-IT who would check a box that says complete.
The problem with this scenario is that more often than not non-IT staff submit a portion of the problem without explaining all of the pertinent details. IT staff develop something and hand it back only to discover that it doesn’t meet the needs of the project. They are asked to make a few changes etc…. The root cause of the problem I believe is that IT and non-IT live in different worlds of vocabulary/concepts and often communication is lost in translation.
I believe the problem might be in how library staff are trained to explain things, and IT staff are trained to figure things out. So, not only is there a different knowledge base, and skill set involved. There is also a group of individuals who are more experienced discussing problems with library users, many of whom are undergraduates, trying to discuss problems with a group of users more experienced talking to peers and discovering solutions to technical problems. When projects are discussed there is often a background surrounding the problem that could become quite tangled and involved if library staff choose to completely explain everything involved.
IT staff just need to know the variables involved and what the process is to be, but in its entirety. Unfortunately the line between not enough background information and too many details is hard to find, but once crossed can glaze the eyeballs of even the most seasoned library oriented IT individual.
IT and non-IT library staff should have sufficient discussions that revolve around materials directly relevant to a project before submitting the project to IT for development.
Item 2: On the other hand: library staff can be very explicit and state their needs, get a result back from IT only to discover they had overlooked something they needed. No amount of explaining the subject to IT would have enabled them to know enough to suggest an inspiration that only comes to library staff upon seeing a completed process. This kind of ‘back and forth’ is necessary and healthy and is called the iterative process.
It comes at a price when a project splinters into several distinct but related enterprises that vary slightly.
An IT ticketing system can be very useful when tracking the development of a project, but it can add to the confusion when a project splinters and different subprojects aren’t appropriately subdivided. There aren’t too many project tracking systems that can handle this kind of sub project division, so IT and library staff make the best of what they have to keep track of revisions and modifications.
I believe that there should be clear and frank discussion between IT and non-IT staff. Neither side should be afraid to speak up and declare that the meeting has gone off topic or too far past the scope of the project. Staff on either side of the table should be clear about their understanding of crucial details that are involved. This might mean that IT staff should request a training session to learn more about certain aspects of library related materials, or that library staff should request a technically oriented training session before they meet again.