Delivering the product to the client could consist of submitting it to a mobile application store or giving the client an installer. Whatever the delivery mechanism is, distributing the product itself, is not the last thing to be done. What comes after the team members have demonstrated the product works as intended to the customer? Of course, the client will have various audiences that have an interest that aligns to their specific role within the client’s organization. The team members are responsible to produce artifacts that answer each role’s questions. We will discuss how to transfer you or your team’s knowledge to the client stakeholders, technical staff and its users.
The client stakeholders are usually the top executives of the organization. If the product you are working on is using agile development, you get the items that executives and other top-level employees want to see for free. Most executive pay attention to the bottom line more that the functionality of a product. Now that does not mean the executives do not care about the product, they are just more concerned with the cost associated with the product. Most agile platforms, like Microsoft’s Team Foundation Server (TFS), employ a concept of dashboards. These dashboards are highly customizable. Team members must enter information in the TFS system every day about what they are working on. For example, team members must enter how much time it took to complete a user story. The TFS system can crunch all of the entered information and display pretty charts that executives can use to determine the state of a project without getting into the details. These dashboards should “include ROI calculations so the executives will know what they’ll get for their investment” (Gilbert, 2012).
Presenting pretty charts to the executives is the least of the work. Presenting your product to the technical workforce is the brunt of the work. Many large environments have a lot of departments that are responsible for different aspects of the product. You may need to develop different documents for each audience. For example, the group that is accountable for approving the architecture of the product may not be the same group that will be acceptance testing the product. Architecture and acceptance testing are completely different animals. You should be prepared to create separate documentation in order to target the technical staff appropriately.
In addition to the technical staff and executives the user need attention to. Remember, the executives and the technical workforce may also be the users, but the use of the product requires a different form of conveying the information. Normally, the information the users need is training on how to use the product. Training can be done in many ways. For example, a full in-class course could be developed, a PowerPoint presentation could be made available to the users or videos can be created. The choice of which way training is conducted usually lies in how much money the client is willing to pay for training. Obviously the most expensive is the in-class course. It would be the most effective though. The users have the opportunity to ask questions to a live person and the training could be tailored to the client specifically. In addition, the in-class training could also be recorded and made available to the users for later viewing. The point here is to have the users get a “basic understanding of the technology so they’re not going to be calling the help desk with silly questions they should be able to handle if they took the training” (Stackpole, 2008).
In conclusion, delivering the product itself is not the last thing to do before calling it quits on a product. The client needs to be disseminated the information on the product at various levels. Whether it be executives, technical staff or its users, the team has to remember that the client did not create the product. Each audience needs to be tailored to whether it be dashboards, documentation or on-line training. How would you like it if someone gave you a car without showing you how to drive it first?
Click here to view the Criterion Report
References
Gilbert, R. (2012, October 12). ASTD Magazine. Retrieved from Four Presentation Strategies for a C-Level Audience: http://www.astd.org/Publications/Magazines/TD/TD-Archive/2012/10/4-Presentation-Strategies-for-a-C-Level-Audience
Stackpole, B. (2008, March 13). CIO. Retrieved from Five Mistakes IT Groups Make When Training End-Users: http://www.cio.com/article/2436969/training/five-mistakes-it-groups-make-when-training-end-users.html
Dashboard Image – http://blogs.msdn.com/blogfiles/bharry/WindowsLiveWriter/TFS2010ProjectManagement_7A35/image_10.png
Audience Image – http://infospace.ischool.syr.edu/files/2014/09/Large-Audience.jpeg
I love how you incorporated the delivery and presentation so eloquently. Everything flowed together and each paragraph had targeted a different audience. I was very intrigued from the start and was curious after each one but the next. You examined the perspective and I thought that was beautiful. I didn’t see much personal experience through this, but your ending was phenomenal. It makes you think about those different concepts of how each presentation is different from the next even though that are on the same concept.