This post is triggered by Sumeet Moghe’s My Take on the “Typical E-learning Projects”. You have to see his post first...
Why what happens happens the way it does?
The customer is typically in a hurry to have the project delivered. Timeline is always crunched.
a. The key reasons are:
1. Rapid change of content around which the training is being designed
2. Need for the training to be in place before the product/service/whatever is rolled out to all
3. Realization that a training is needed at all comes a little late in the day
4. Realization that the traditional method of training may not work comes even later
b. What ensues?
A training-solutions designer is engaged and asked to deliver a training program. The timeline for delivery is mentioned as a very crucial factor, which it is.
c. What gets sacrificed?
Often, in a bid to meet the timeline and begin with the delivery, the Analysis Phase is either shortened or completed summarily. Still, the analysis report may look good enough to begin work with.
d. What happens next?
Based on this report, an implementation plan/project plan is drawn up with all the subsequent delivery milestones. Still good.
e. The resultant confusion:
The loopholes in the report begin to show up when put to the test—that is, when the solution is actually developed and presented to the customer.
Branching 1.1
The scope of salvaging the situation: Rapid Prototyping
If the designer happens to follow the Iterative/Agile methodology and believes in rapid prototyping, then everything is not lost. The customer gets to see the prototype and while their BP may shoot up, s/he would be glad once the purpose is explained, fixes done and the solution approximates the needs.
What should the smart designer do?
I am a believer of a good analysis. A good, well-defined analysis report can be the guiding document for quite some time. A smart designer would take some time and go back to the Analysis Report and update it. S/he would then create a design document that captures the approved solution and sit with the PM (if they are not one and the same) and work out a project plan.
Branching 1.2
What happens in a linear approach? (No Rapid Prototyping)
Remember Point e above? In the absence of a rapid prototype, there is no way of testing the analysis. If the delivery plan follows a linear process (Waterfall Methodology), the designer and team could end up with a very very disgruntled customer. Someone who looks like this:
With some good communication and smart thinking, we can of course have a customer looking like this:
Why what happens happens the way it does?
The customer is typically in a hurry to have the project delivered. Timeline is always crunched.
a. The key reasons are:
1. Rapid change of content around which the training is being designed
2. Need for the training to be in place before the product/service/whatever is rolled out to all
3. Realization that a training is needed at all comes a little late in the day
4. Realization that the traditional method of training may not work comes even later
b. What ensues?
A training-solutions designer is engaged and asked to deliver a training program. The timeline for delivery is mentioned as a very crucial factor, which it is.
c. What gets sacrificed?
Often, in a bid to meet the timeline and begin with the delivery, the Analysis Phase is either shortened or completed summarily. Still, the analysis report may look good enough to begin work with.
d. What happens next?
Based on this report, an implementation plan/project plan is drawn up with all the subsequent delivery milestones. Still good.
e. The resultant confusion:
The loopholes in the report begin to show up when put to the test—that is, when the solution is actually developed and presented to the customer.
Branching 1.1
The scope of salvaging the situation: Rapid Prototyping
If the designer happens to follow the Iterative/Agile methodology and believes in rapid prototyping, then everything is not lost. The customer gets to see the prototype and while their BP may shoot up, s/he would be glad once the purpose is explained, fixes done and the solution approximates the needs.
What should the smart designer do?
I am a believer of a good analysis. A good, well-defined analysis report can be the guiding document for quite some time. A smart designer would take some time and go back to the Analysis Report and update it. S/he would then create a design document that captures the approved solution and sit with the PM (if they are not one and the same) and work out a project plan.
Branching 1.2
What happens in a linear approach? (No Rapid Prototyping)
Remember Point e above? In the absence of a rapid prototype, there is no way of testing the analysis. If the delivery plan follows a linear process (Waterfall Methodology), the designer and team could end up with a very very disgruntled customer. Someone who looks like this:
With some good communication and smart thinking, we can of course have a customer looking like this:
No comments:
Post a Comment
Thank you for visiting my blog and for taking the time to post your thoughts.