It was wonderful to read Gary Morrison's [30 Sep 96] account of his project from 1976. It was sobering to see that we can still make the same mistakes.
The responses I have received to date have ranged over a number of issues. In fact, as the day runs out and I need to post something, I find there are too many to respond to at one time.
I have categorized the issues to date as: Communication, Process, User Expectations, Roles, and Commitment. The user expectations one was new to me. In this post, I will only respond to human communication issues, and I will follow up on others subsequently. Don't despair if your contribution hasn't been referred to here. It may be referred to in a subsequent response on another issue.
[quoting McKenna, 30 Sep 96] There is no doubt that the development of IMM requires a multi-skilled team approach. But, as in all projects, the lines of communication and areas of responsibility must be very clear and agreed upon from the beginning. I think working in teams can be very difficult even if everyone is focused on the same outcome and has the same amount invested in the project. Organizational psychologists don't seem to like to dwell on it but the play of different personalities are so very important to the harmony of a team.
Well put. I will reinforce some of this below.
What concerned me most in the case study presented by Rob was the blame apportioned to the Project Leader who had the audacity to go on maternity leave! I have found that communication problems crop up early in any project and it is the responsibility of ALL team members to find a solution together--quickly.
Actually the blame was apportioned BY the project leader (who wrote the comments). More importantly, the team thought the project was finished and running when the problems cropped up. Although there may have been good communication pathways during the development, there was no provision for this after installation of the software. Too many development people think: "The project is finished, so it is not my responsibility anymore." But somebody has to carry the can.
[quoting Anonymous, 1 Oct 96] Communication at the "concept" stage is most important. Be sure to convey to the "end user" what you understand it is that they want.
I agree. More on this in a later post.
Do not get defensive about your own part. Always give people enough space to see the errors of their ways.
Be creatively assertive, but take your personality out of it when reviewing and evaluating design decisions (if you can).
[quoting Fyte, 30 Sep 96] I agree with the notion that although collaboration is essential to get projects finished, trialed, and implemented in a reasonable timeframe, it is also not always a comfortable experience. I know from my own work in teams which developed the Osmosis Program, and Sarcomotion, as an academic I am used to working alone, used to directly translating the pictures in my head into flow diagrams or metaphorical examples. I had a lot of trouble trying to translate ideas to programmers and graphic designers who lacked the background knowledge of the content.
Yes. This is a very important point. Educational IMM cuts across so many discipline areas, each with different ways of communication. Let's generalize a bit.
Many people in many areas communicate and collaborate with colleagues all the time. Many even do it successfully! However, the collaboration is often with colleagues in the same discipline. For example, Georgina works with academics and students in Biomedical Science. They share a common language (all that Latin stuff) and a way of using that language. Any communication with colleagues involves a range of assumptions (e.g., what a cell is) which are not even thought about because there is a shared understanding of them. This is not the case with an IMM team. What is a graphic designer's concept of a cell? Does it matter that those big Latin names are spelt correctly?
As Georgina said, you have to stretch your brain to communicate in an IMM team. Also, at least one person in the team needs to be able to "translate" one's meaning to a shared understanding.
[quoting Gibson, 30 Sep 96] How do you help a professor, who has very successfully taught his/her course alone, see themselves as the subject matter expert in a project and accept that successful multimedia development is a team process?
[quoting Fyfe, 30 Sep 96] It was also personally challenging. I was defensive when the way I had taught a particular part of the course for years was questioned as educationally unsound. No-one usually cares one way or another what happens in the classroom let alone asks you to justify it. However, that alone was of value, and I strongly believe it made a final product which pushed the limits of the content provider.
Academics do tend to work alone and have to look after themselves. Relinquishing their autonomy over a project can be difficult and stressful. However, it is essential for the success of a project. It is intellectually arrogant to think that you as an individual can successfully fill all of the roles needed to create effective IMM. Leonardo DaVinci may have been able to, but who else?
[quoting Morrison, 30 Sep 96] I am now older and much wiser and would not want to subject myself to so much stress. However, if my memory should slip, I would start with a very lengthy design phase with just myself and the subject matter expert(s). After completing the design phase, I would bring in the rest of the team.
The lengthy design phase is crucial. However, following on from the point above, I want to disagree with Gary on the team composition. I firmly believe all members of the team should be involved in the design. They each have knowledge and experience from their specialty and from previous projects which can enhance a project. It also leads to a more cohesive team later. A programmer may be able to suggest a more efficient type of navigation that the "educational" team members had overlooked. One of our graphic designers almost never says anything in design and planning meetings. However, she absorbs it all, goes away, and comes up with the most wonderful designs very quickly. If she hadn't been in on the design, she couldn't have done this.
[quoting Bixler, 30 Sep 96] Most bugs are in the glitches category. From a design standpoint, SCORE is the most solid product I've ever developed. I attribute this to teamwork, up-front planning, and no sudden shifts in direction from anyone involved in the development. All team members got along fairly well, though there was some finger-pointing that occurred when problems arose. Fortunately we had a person who was able to smooth out these difficulties--a very important role.
Yes. I have found that a key part of project management in these sort of projects is to be a diplomat. It's much more important than Gantt charts!
[quoting Morrison, 30 Sep 96] The vice-president, in his wisdom, decided to pay the subject matter expert and video producer more than the instructional designer to cause "creative tension" to stimulate the team. There was as much disagreement between team members as there was between the team and management.
The football coach management mentality.
That will have to do for today. I will be back tomorrow with some more.