Thursday, April 4, 2013

Please freeze the design!

How often have you worked on ID projects where the design is still not frozen (or per one of the final reviewers, the design seems ok; however, review from another reviewer is still awaited) and the management waves a green flag to the content development team? Trust me, I have, more often than not. It typically happens when an organization outsources its training needs to another organization that is good/professional at developing, designing, and delivering training.

Management at the training team side wants to optimize the time that team members are billing on the project and it also intends to impress the client by delivering development pieces ahead of the training timeline. On the other hand, client reviewers, whose key responsibilities are different than training development, park performing reviews for a later, rather relaxed time. Situation: Content team creates design that is ready for review; however, (full) review does not come through per the timeline. Implication: Management gives a go ahead for content development since the design timeline has passed. The development starts in full flow, unsure of the validity of the design on which it is to be based. Complication: Complete design review is received a couple of days, sometimes weeks (yes, that happens), later and it indicates some major changes to topical outline, objectives, and even learning strategy, of the training. Result: Rework. The development team gets defensive and feels demotivated. However, this is the situation (not the best one, agreed) wherein a training team can learn a lot about the client, their preferences, reasons for their preferences, and their thought process for selecting an approach over another, in addition to sharing their own reasons for designing the training approach as they did---many a times clients also learn a thing or two about training by interacting with the training development team. By being defensive, most of the teams lose on the opportunity to interact with client to understand their requirements at this stage. Often, the development team works towards merely fixing the review comments just for the sake of it. My suggestion: Utilize this scenario/time to (a) understand what the client review essentially shares---what is good/not so good about the design, what the client desires, why does the client need what it is asking it does---and, if need be, (b) negotiate---may be timelines, budget, resources, etc. (Given that the design review arrived later than the timeline, depending on how late it came through, it will have timeline/monetary implications.) And to avoid running into situations like these, have a good dialogue with client at the beginning of the project, emphasizing the importance of having one key work product frozen/signed off before working on the next, dependent work product(s); e.g., a frozen design before starting to work on training development; frozen development templates before beginning to script content in them, and so on. In addition, consider developing (if absolutely necessary) only the parts of training for which you are sure that the design will not change.

No comments: