4.1: 4 Understanding and Meeting Client Expectations -- Project Management for Instructional Designers

4 Understanding and Meeting Client Expectations

4.0 Overview

Visit Audio Recordings for the audio version of this section.
This chapter aligns with the beginning of Chapter 3 of the PMBOK where stakeholders are addressed and 11% of the CAPM questions come from this knowledge area. The content connects to the Initiation and Planning category of the PMP questions.

Project management, especially within instructional design, revolves around understanding and meeting client expectations. Even the most efficiently completed project will not count as a success if the client and other important stakeholders are unhappy with the results. Accordingly, every successful project will necessarily have a plan or strategy of some sort in place for making the client happy. Depending on the complexity level of the project, this strategy to meet the client’s expectations can range from having a general discussion with the project leadership team to developing a formal plan that is tracked during the life of the project. Since project stakeholders can often exert considerable influence over the success of the project with expertise, political influence, and additional resources, an essential element of such a plan will be on how to motivate the client to contribute to the team’s success throughout the life of the project.

Designers Share Their Experiences

Dr. Andy Gibbons – Instructional Psychology and Technology – BYU

Miscommunication did happen on this project. We were working with people who were trained in how to operate helicopters, how to fly them and how to operate the electronic equipment in the back of the helicopter. We found that, well first of all, the first communication challenge that we came up against was the communication of the content itself. I wasn’t trained in helicopter piloting. I had no idea what a sensor operator was until I shook hands with one. I had no idea how the technical worked. I had no idea how the strategic part of this, how you actually play the chess game of finding a submarine that is under the water. And yet at the surface that’s what these people were trained to do. So the first communication problem that we had was the subject matter. The second was the simple day-to-day communications with people who, in some cases, were highly motivated towards our project, and in some cases weren’t. Learning to manage people’s motivations became a very important challenge for us. There were people who just wouldn’t show up for work when they were scheduled to work. Not on my staff but on the Navy’s staff. Because they would have a check-ride in a simulator or they’d be doing something else, and we were low priority for them. Probably the biggest miscommunication problem that we had—had to do with an entire section of the subject matter. We mistook that what we were trying, what we were supposed to do was train people how to fly this helicopter and how to operate the sensors in the back of the helicopter. It turns out that, and we did our task analysis, a very thorough task analysis, reams of paper, showing all the things that needed to be trained and these resulted in instructional goals, however there was kind of a meta-performance that these people were engaged in. It was not just flying the helicopter, and not just operating the sensor equipment in the back. It was using the combination of pilot and sensor operator skills as a team to fly across the top of the water, looking for, first of all to detect a submarine and once you had detected it finding a way to keep track of it and to keep tracking. Of course the submarine is trying to escape. So there is this whole strategic, or what they call the tactical section of the training, and we found out about two-thirds of the way through the project that the subject matter expert team had not told us about this part of it, and we had not noticed it, it was kind of a stupid mistake on our part. So I looked at the subject matter, the head subject matter expert and said, we need to do a little bit more task analysis and add some things to the curriculum. Of course, by then, the budget had been set on a certain number of things to be created. And so, when I said to him that means we’re probably going to have to create some more instructional pieces. He said, well no, and he started finding excuses not to do that part of the course. Well once again the people on the East coast, because they had clear water, were much more expert it turns out. And when the training hit the East coast training site, the first thing they did was they opened up the box, and they took out the training. And they looked for this part on these tactical exercises. And it wasn’t in the course. And so they immediately packed up the box and sent it back and said this course is useless for us. We need the tactical part. And what happened, the long and the short of it was, the U.S. Navy had to make another contract, and design more training. And the subject matter expert turned out to be wrong. He should have said, yeah we’re going to develop more training. And so, that’s how that worked out.

Heather Bryce – Independent Studies – BYU

Well, we did have some miscommunication. The instructional designer was brand new, and so, wasn’t as familiar with our processes as other instructional designers. So when we originally meet, we have all the supervisors meet together for collaborative meetings. Which, these types of meetings can be very expensive when you have a lot of full-time people meeting together. The instructional designer continued to have meetings, but normally what we would do is, we would have meetings with perhaps the student employee who is actually doing the work and not everybody who is involved at the supervisor level. So we had a lot of meetings with people that didn’t necessarily need to be there that were probably extra meetings, and that of course made the project become quite expensive in meeting time. So that was a miscommunication on my part in communicating with the instructional designer that all those meetings weren’t necessary. So the cost on this course grew quite quickly, but at the same time it was also good because there was a lot of collaboration, more than we would have on a normal course within the department. So, it was not a good thing as far as the course expense, but the course ended up being a really amazing project. The final product was amazing and actually won an award.

Dr. Larry Seawright – Center for Teaching and Learning – BYU

Oh gee, where do I start. In the Learning Suite project, where we are building such a large and complex system that interacts with faculty and students, it accesses University databases that are password protected, that are roll protected. One of the key issues is communication of those requirements to our IT organization. Early on, one of the miscommunications that we had concerned some of the services we needed built, and it just never got done. So here we are progressing right along with the development, and so then we call up this person and say, “Is the service ready?” “What service?” Well, we actually never told them which service it was. So you know, it was a miscommunication on our part, but it was, you know, we didn’t tell them exactly what to build, and they have a completely different process. We’re not a professional in IT organization that normally builds gigantic applications like this. We’re the Center for Teaching and Learning, so we’re a bunch of PhDs who specialize in design and development of instruction materials and we just kind of happen to fall into building this Learning Suite because we made something called the Syllabus. That is the biggest part of the problem, is we’re not IT folks. So I am the associate director and the project director. Kind of, well it’s not two hats, its multiple hats that I’m wearing because I do other things. I’m also the Center’s evaluator. Etc. Etc. So you see, you know, with a smaller organization we do a lot of things. In big centralized IT organizations where they have not just one, but multiple project managers, that greatly facilitates project management on a scale where you could develop Microsoft Project plans and enterprise wide project plans in lots of detail, spreadsheets, etc. etc. We have a whiteboard where we track things. So the miscommunication happened because of our limited resources. You know, we do what we can, we try to be as professional as we can, but sometimes we fail to communicate in the way that the other party expects. So that was the primary difficulty. So you always want to try to verify that what you ask for got communicated. It got through the request process in a way that they could hear it.