Comments from Judge Rob Foshay:

The team did a great job in identifying the systemic issues and solution strategies. However, as suggested in the provocateur questions, it' unlikely that management will accept the risk of wholesale systemic changes. Specifically, the suggested changes in team organization & management structure, and the implications for job definitions and compensation probably will be seen as too big a risk. In addition, the solutions which require allocation of production resources in large blocks probably are not acceptable while a project is under way.

The central issue for this team, therefore, is how to get from the global analysis and intervention strategy presented to a more incremental, lower-risk strategy. The logical way to do this is to use Tom Gilbert's concept of the Performance Improvement Point (PIP) to identify specific performances and target interventions to improve them. In particular, it seem probable that targeting the large number of takes is reasonable. It should be possible to look at the last project's history and contrast the shots with low number of takes with those with high number of takes. Whatever the reasons are for the differences become the targets for development of the interventions identified (EPSS/knowledge base, vendor support, mentoring, better output specification, etc.). It should be possible to get early success with a few of the biggest PIPs, thus demonstrating effectiveness for the approach and garnering management support for further work. The target, it will be recalled, is to show results in 9 months-not to implement in 9 months.

The team's rationale for feasibility of the interventions demonstrates that it can be done with available resources and the prioritization is resource-driven. The above approach would lead to a problem/need-driven solution strategy, instead.

One final risk on the EPSS/knowledge base development issue: the hardest part in this case will be indexing the knowledge for appropriate retrieval. The indexing/retrieval system cannot be exclusively verbal, since most of the knowledge is visual/graphic and verbal vocabulary tends to be ideosyncratic, example driven, and team-specific ("do the Rocket Boy head twist on that shot"). This will almost certainly defeat the programmers if they are left alone.

The team proposed reorganization of teams, but stopped short of proposing true cross-functional teams. This seems like a reasonable intervention.

On the positive side this was a textbook response to the situation hitting all or most of the issues. I was most impressed by their plan to incorporate a feedback mechanism during production. However, I was dismayed to see the level of overkill in the solution. There were so many new things being brought in to DAI, the solution might be worse than the problem, in terms of production. I tend to lose confidence whenever so many things are thrown at a problem or a question that I wonder if the presenter really has a vision of the solution or is just hopping one of the many ideas would work. I think a client would have great difficulty with the proposal.

Overall good job! Databases can be used very effectively in a lot of learning and knowledge management situations. I also liked the proposal to match vendor presentations with in-house needs, one indication that your team realizes the need for further assessment.

The proposal represents a good general picture of what is going on and how to address the issues and concerns. What was missing was specific level interventions such as process planning and also specific details within some of the interventions that were mentioned. For example while addressing the use of listservs I wondered "what if team's changed" or "does everyone need to see every message?" IT was evident in the proposal that the writers had a strong sense of the technologies available, but the interventions were a bit weaker on the best use of the technologies for identified problems.

It was nice to see the wide array of instructional and non-instructional recommendations you presented. I agree that DAI has many people currently employed who could help solve the problem without needing outside intervention, and your idea of identification of skills and expertise is a great first step.

I also liked your idea of co-mentoring in an apprenticeship role, especially with the difference in artists from both the old school and the newer, digital background. However, simply configuring the teams may not be enough to build lasting bonds. Providing a workshop or other intervention to strengthen team work and bonding might be needed to ease into this new format.

I also wonder if teams might be designed to contain people from multiple job responsibilities. This may help reduce the "40 or 50" times that drawings need to be sent back (which appears to be where a lot of the delay and costs overrun occur). I didn't feel this was as much a lack of skill as it was a lack of communication. By facilitating horizontal teams, each member would get a feel for the larger picture, develop more buy-in to the entire process, and help each other to catch errors before they left one section for the next.

Bringing in the vendors to assist in the training is sound, but only if, as you say, they will "match in-house training needs with vendor presentations." From the story line, this was overlooked in the current situation.

Your components for the EPSS have merit, although your arguments would have been strengthened if you had provided more detail as to how components such as the tip sheets will be organized, or when or how they will be built.

Recognizing multidimensional aspects of the problem facing DAI, Jason (this team) correctly focused his response on aspects related to the T&D Unit. Furthermore, his solution was tempered with the admonition that without addressing managerial issues at DAI, there was no certainty his proposal would lead to increased profits.

Addressing his specific task of providing *performance support* for the animators, Jason was careful to connect identified needs with specific positions within the Pipeline. His proposal for developing core competencies for each job may be overly ambitious as a short-term solution. Recognizing the need to further determine costs for employee testing and data collection is definitely an issue when cost effectiveness is under scrutiny.

Although vendors are identified as having potential for having a more positive impact, no mention was made of brining the end users into the vendor/software/hardware selection process.

Expanding the Intranet appears feasible, as does cross-training and co-mentoring as described *if* strategies are used to subsequently encourage employees to "push" and "pull" the technology and to assist employees in identifying with these new teams.

Managerial alternative solutions, particularly rewards, while promising, would appear beyond the power of the T&D Unit. Addressing a way to advocate for these solutions within DAI would strengthen the proposal (see Wunsch, 1992).

Specific Comments on the Rating Scale:
1--Identification of communal space as one possible contribution to the performance solution demonstrates consideration of multiple factors beyond training.
2--Administrative issues were more focused on what could be accomplished outside of the T&D Unit, rather than within.
4--Very effective
9--Jason's capabilities with EPSS weren't highlighted.
14 & 15--"Buy in" by employees needs to appear more overtly.

Good analysis and treatment of the problem. I have a few observations:

• I’m not sure I agree that pricing and forecast of expected costs falls outside the scope of training. Why wouldn’t an EPSS solution serve everyone from Kenny Moyers to Ellen Peterson? I think Ellen needs to understand as much about Kenny’s work than he does of her work, so why wouldn’t this solution be appropriate both of them? Don’t discount management’s need to understand what happens on the floor.

• Establishing core competencies is a great recommendation, but may be difficult to implement within artistic disciplines. The same is true for determining your baseline of skills. On the technical side, this may be easier to articulate but still with differences in software and hardware, this may be the slightest bit inefficient.

• You put a lot of assumptions in place. Among them,
  
  • Establishment of a database as a functional element should not require more than six weeks
    
  • Successful implementation of the listserve depends more on the desire by employees to use it rather than any technological or time-dependent obstacle
    
  • Bill’s constant attention would be required to resolve issues on the Intranet

  These are examples of things that either need to be more thought out, or their benefit to the company should be more clearly articulated. Just because Bill is a member of your training team, doesn’t mean he won’t need to have some sense of buy-in for these changes. I would suspect that Bill would have made the company Intranet extremely robust and useful if he had the time, inclination or motivation to make it so. Why would your proposal change these existing conditions?

• Training, in many ways, is a catalyst for change. Assertions such as "management mandates information collection" and "employee compliance is immediate," could rub some people the wrong way. Mandating certain things won’t always directly improve employee productivity. In many ways, people make that choice themselves, and usually do so through feeling some benefit to their participation.

• In your conclusion, the statement that "the support system is expected to enhance employee performance, improve production quality, and reduce the number is expensive revisions" is very well articulated. However, you may require more substantiation in that statement when management reviews your package. Be certain that you have backed up that statement with demonstrable examples of how that will in fact take place.