I worked with a company that created aviation training and my transition to software technical training was met with several challenges. For one thing initially I did NOT understand the products by just reading up ILT and documentation. We started with conversion courses that put me into the comfort zone. Converting ILT to WBT was the perfect thing for someone like me with no prior experience in the use of such technical and complicated software products.
The products were based on SOA and had concepts, (as deep as the Java language) to be understood in order to be used; finally there was the implementation part, the so-called production environment, where the customer implements the product in his organization, which the ID cannot see or imagine!
The next course we got into got us chewing up every bit of our left over nails and wondering where we could run and hide. This was a newly acquired company that had a great product but no available documentation or training! And that was just the beginning of another whole journey of a course development cycle, as our SME was in another country from a 3rd party company. The company that was acquired had outsourced all of the work to this company and most of their expert team within the company were laid off or had left! This is where I began to realize how product knowledge becomes critical to your success in a product company irrespective of the role you play. The company looks to make everyone product literate so that it helps do our tasks with greater insight.
The SME Reality
In time, I realized that being part of a software products company was one of the most challenging things for an ID. Contrary to common belief that since I was part of the same company that creates the products, I should have greater access to SMEs, the reality was exactly the opposite. The product teams are so deeply involved in their project schedules that they would never commit to providing us with a single person as a SME! Moreover, the product was so big and complex that it would take more than one individual performing a specific role to be able to give you all the information about features and facets to the product. Whew!
Dealing with the situation
Over time I learned to deal with a situation like this and following here you will find only solutions, so I can conclude this post on a positive note! Let's start with what are all the things we need to do in order to be able to plan and execute such complex courses successfully. In this post, I will only focus on the gathering of information and their sources. I plan to write more posts on how to analyze and segment this information to be able to produce effective courses for such products.
Accessing information types
The first thing you need to do is to identify and get access to all the available types of information within such a setup. Here is a high-level list of such information.
Documented Information- You need to have written information in the form of blogs, wikis, documentation, feature design documents, course/ILT material to start learning stuff.
Product Trainings - Look out for and get enrolled to any relevant product trainings that get scheduled. Do check on whether it is a high-level functional training, giving the benefits of the product and its features, which will be useful to your job, or a deep dive session, which will be mostly irrelevant to you.
Hands-on Product experience - You need to install the product or get access to an environment and be able to implement and use the features of the product from a task point of view, over just playing around with the features casually. Learn the product with a specific goal in mind like create a process to take a purchase order using the product, and get it running. This will not be easy and you will need to get guidance from someone here.
Implementation information - You need to have scenarios/use cases of how the product is used in the customer's setup or the so-called production environment. You have to be able to visualize the setup at a production environment and how the customer will use the product.
Value added information - You need to have information about the real-time problems faced by the customers while implementing the products (remember all software products are never bug free and their real-time performance can only be assessed in production)
That looks like a short list with just few high-level points, but believe me getting all this to get your course out is undoubtedly a herculean task, given that you also need to do your usual ID work, of audience analysis, task analysis (which I will cover in later posts) over and above all this. That's one of the reasons I decided to start blogging as it helps me to get thinking on a way to work these things out.
Identifying your sources of information
Given the challenges to getting these different information types, you need to identify the sources of such information. Well who else but multiple persons playing different roles on the product within the organization can provide such information? Let's identify the roles:
The Software Engineer/Developer
A great source of technical information to understand the product features and how to work with them. Ask them all you want to know about the product architecture, how components work with each other, where to find certain options/features etc. They also understand conceptual information a great deal, so leverage on it!
Words of caution
- They usually always know 'how' to do things but not necessarily 'why' you do things 'that' way and not any other way.
- Sometimes due to the way the team is organized and time constraints, certain developers would only know some of the features/aspects and not all. So you need to find the right persons for your course.
- They also may have no/limited knowledge on how the product is used in the real-time or in production.
- They have little or no knowledge about how important a product/feature is to the audience and a particular role.
The Quality Assurance engineer
A great resource to ask about how the product installs, what environment it uses, what are the bugs/problems with the product currently. Ask them questions about concepts, test cases, what works what doesn't and why. They are also a good source of conceptual information and would be familiar with the product architecture and how it integrates with different components.
Word of caution - Similar limitations to the development/engineering teams.
Both Dev and QA folks are usually high on technical product knowledge and the workings of the internals of the product, rather than the implementation and functional perspective.
Product Managers
They are great resources for customer information, customer profiles, product positioning, correct terms to use in your courses and documentation, and how to present the product to the audience. Remember that product companies often use training and documentation as a means to subtly market the product and make it look more attractive.
These are the people you should be asking the ‘why’ questions. For example: Why do we need this feature? How else can this task be accomplished or is this the only way?
They can also point you to the right resources, collaterals, product demos to customers, etc. They have a good understanding of the functional working of the products and their integration with other products.
You can ask them about how a customer uses the product, what features they use more often, use cases/scenarios, common problems etc. so that you can prioritize your content and improve relevance of the material.
Word of caution- Do not expect them to know the internals and the workings of the product features to the same level of Dev/QA folks. The Dev/QA guys are the techies and only they can get you such information.
Consultants and Professional Services
These folks are usually the implementation guys who go to the customer and help them install and implement the product. They also have a subtle marketing role associated to their portfolio. Their role is a post marketing strategy that serves as a benefit to the customer for implementing the product successfully, but also comes at a price.
Though consultants and Professional Services vary in terms of the level of their expertise on the product, Professional Services being quite superior, these people are the right ones to give you implementation related information, best practices, do's and don't, tips and tricks etc. They usually know and understand all facets of the product related to the implementation. They may also be able to give you a greater insight into the workings of the product with other products/third-part software/plug-ins etc. These are also the right people to ask the ‘why’ question to.
Word of caution- They may not know the product internals but understand the functional and implementation perspectives very well. Another downside is that you almost never get access to these guys, as they would always be onsite! You may try connecting to them through email.
Product Support
These guys take the calls for the customers who have paid for support on the product and help them resolve issues post implementation. This can be compared to a maintenance support role, where the customer using your product may have problems issues, questions, complaints, etc. The kind of information these guys would be able to give would be product bugs, common problems faced, troubleshooting information.
Word of caution- Same as consulting/professional services.
Note that Consulting/Professional Services and Support roles may not be distinct in all organizations as their structure may vary. You may need to identify folks by the roles they play and decide which category they fall into in my list above.
Experienced Technical Writers/Trainers/Instructors
These people are good resources because they learn the product as a result of their job and experience. They also often have hands on knowledge of working on the products. They are good people to consult on prioritizing the information you have, segmenting it, organizing and structuring it. There you go you have more help!
Word of caution- Do not treat these peoples knowledge on the product as final. Use the previous resources for that.
Wrapping up
I just realize how huge this post has become, given that i don't get enough time to blog more often, I tried to package a lot into one blog post here.
So to conclude on the above,
- Gathering information in software product setups usually comes from multiple sources and never from a single SME.
- People give you information based on their exposure to the product and their experiences. You need to filter out the right information by studying your audience and the tasks they will do using the product.
- The above information types and sources may vary depending on company organization and their way of functioning. Several times, due to policies etc you may or may not have access to certain kinds of information.
It is also important to ask the right people the right questions based on their roles, else it would seem like harassing them to give information on a domain that is not part of their key job role. So respect that and choose the right way to do this. Finally, make an effort to work your way through by making the right contacts, building a rapport with the right people and getting what you need. A good and professional personal rapport can add a whole new dimension to getting information! Remember good and effective communication can get you places…
The products were based on SOA and had concepts, (as deep as the Java language) to be understood in order to be used; finally there was the implementation part, the so-called production environment, where the customer implements the product in his organization, which the ID cannot see or imagine!
The next course we got into got us chewing up every bit of our left over nails and wondering where we could run and hide. This was a newly acquired company that had a great product but no available documentation or training! And that was just the beginning of another whole journey of a course development cycle, as our SME was in another country from a 3rd party company. The company that was acquired had outsourced all of the work to this company and most of their expert team within the company were laid off or had left! This is where I began to realize how product knowledge becomes critical to your success in a product company irrespective of the role you play. The company looks to make everyone product literate so that it helps do our tasks with greater insight.
The SME Reality
In time, I realized that being part of a software products company was one of the most challenging things for an ID. Contrary to common belief that since I was part of the same company that creates the products, I should have greater access to SMEs, the reality was exactly the opposite. The product teams are so deeply involved in their project schedules that they would never commit to providing us with a single person as a SME! Moreover, the product was so big and complex that it would take more than one individual performing a specific role to be able to give you all the information about features and facets to the product. Whew!
Dealing with the situation
Over time I learned to deal with a situation like this and following here you will find only solutions, so I can conclude this post on a positive note! Let's start with what are all the things we need to do in order to be able to plan and execute such complex courses successfully. In this post, I will only focus on the gathering of information and their sources. I plan to write more posts on how to analyze and segment this information to be able to produce effective courses for such products.
Accessing information types
The first thing you need to do is to identify and get access to all the available types of information within such a setup. Here is a high-level list of such information.
Documented Information- You need to have written information in the form of blogs, wikis, documentation, feature design documents, course/ILT material to start learning stuff.
Product Trainings - Look out for and get enrolled to any relevant product trainings that get scheduled. Do check on whether it is a high-level functional training, giving the benefits of the product and its features, which will be useful to your job, or a deep dive session, which will be mostly irrelevant to you.
Hands-on Product experience - You need to install the product or get access to an environment and be able to implement and use the features of the product from a task point of view, over just playing around with the features casually. Learn the product with a specific goal in mind like create a process to take a purchase order using the product, and get it running. This will not be easy and you will need to get guidance from someone here.
Implementation information - You need to have scenarios/use cases of how the product is used in the customer's setup or the so-called production environment. You have to be able to visualize the setup at a production environment and how the customer will use the product.
Value added information - You need to have information about the real-time problems faced by the customers while implementing the products (remember all software products are never bug free and their real-time performance can only be assessed in production)
That looks like a short list with just few high-level points, but believe me getting all this to get your course out is undoubtedly a herculean task, given that you also need to do your usual ID work, of audience analysis, task analysis (which I will cover in later posts) over and above all this. That's one of the reasons I decided to start blogging as it helps me to get thinking on a way to work these things out.
Identifying your sources of information
Given the challenges to getting these different information types, you need to identify the sources of such information. Well who else but multiple persons playing different roles on the product within the organization can provide such information? Let's identify the roles:
The Software Engineer/Developer
A great source of technical information to understand the product features and how to work with them. Ask them all you want to know about the product architecture, how components work with each other, where to find certain options/features etc. They also understand conceptual information a great deal, so leverage on it!
Words of caution
- They usually always know 'how' to do things but not necessarily 'why' you do things 'that' way and not any other way.
- Sometimes due to the way the team is organized and time constraints, certain developers would only know some of the features/aspects and not all. So you need to find the right persons for your course.
- They also may have no/limited knowledge on how the product is used in the real-time or in production.
- They have little or no knowledge about how important a product/feature is to the audience and a particular role.
The Quality Assurance engineer
A great resource to ask about how the product installs, what environment it uses, what are the bugs/problems with the product currently. Ask them questions about concepts, test cases, what works what doesn't and why. They are also a good source of conceptual information and would be familiar with the product architecture and how it integrates with different components.
Word of caution - Similar limitations to the development/engineering teams.
Both Dev and QA folks are usually high on technical product knowledge and the workings of the internals of the product, rather than the implementation and functional perspective.
Product Managers
They are great resources for customer information, customer profiles, product positioning, correct terms to use in your courses and documentation, and how to present the product to the audience. Remember that product companies often use training and documentation as a means to subtly market the product and make it look more attractive.
These are the people you should be asking the ‘why’ questions. For example: Why do we need this feature? How else can this task be accomplished or is this the only way?
They can also point you to the right resources, collaterals, product demos to customers, etc. They have a good understanding of the functional working of the products and their integration with other products.
You can ask them about how a customer uses the product, what features they use more often, use cases/scenarios, common problems etc. so that you can prioritize your content and improve relevance of the material.
Word of caution- Do not expect them to know the internals and the workings of the product features to the same level of Dev/QA folks. The Dev/QA guys are the techies and only they can get you such information.
Consultants and Professional Services
These folks are usually the implementation guys who go to the customer and help them install and implement the product. They also have a subtle marketing role associated to their portfolio. Their role is a post marketing strategy that serves as a benefit to the customer for implementing the product successfully, but also comes at a price.
Though consultants and Professional Services vary in terms of the level of their expertise on the product, Professional Services being quite superior, these people are the right ones to give you implementation related information, best practices, do's and don't, tips and tricks etc. They usually know and understand all facets of the product related to the implementation. They may also be able to give you a greater insight into the workings of the product with other products/third-part software/plug-ins etc. These are also the right people to ask the ‘why’ question to.
Word of caution- They may not know the product internals but understand the functional and implementation perspectives very well. Another downside is that you almost never get access to these guys, as they would always be onsite! You may try connecting to them through email.
Product Support
These guys take the calls for the customers who have paid for support on the product and help them resolve issues post implementation. This can be compared to a maintenance support role, where the customer using your product may have problems issues, questions, complaints, etc. The kind of information these guys would be able to give would be product bugs, common problems faced, troubleshooting information.
Word of caution- Same as consulting/professional services.
Note that Consulting/Professional Services and Support roles may not be distinct in all organizations as their structure may vary. You may need to identify folks by the roles they play and decide which category they fall into in my list above.
Experienced Technical Writers/Trainers/Instructors
These people are good resources because they learn the product as a result of their job and experience. They also often have hands on knowledge of working on the products. They are good people to consult on prioritizing the information you have, segmenting it, organizing and structuring it. There you go you have more help!
Word of caution- Do not treat these peoples knowledge on the product as final. Use the previous resources for that.
Wrapping up
I just realize how huge this post has become, given that i don't get enough time to blog more often, I tried to package a lot into one blog post here.
So to conclude on the above,
- Gathering information in software product setups usually comes from multiple sources and never from a single SME.
- People give you information based on their exposure to the product and their experiences. You need to filter out the right information by studying your audience and the tasks they will do using the product.
- The above information types and sources may vary depending on company organization and their way of functioning. Several times, due to policies etc you may or may not have access to certain kinds of information.
It is also important to ask the right people the right questions based on their roles, else it would seem like harassing them to give information on a domain that is not part of their key job role. So respect that and choose the right way to do this. Finally, make an effort to work your way through by making the right contacts, building a rapport with the right people and getting what you need. A good and professional personal rapport can add a whole new dimension to getting information! Remember good and effective communication can get you places…
Nicely written and a good summary of the previous experience :P
ReplyDelete"Todor" would be happy to read a bit of this, I am sure :-)
Hi Sreya
ReplyDeleteThis is a great post. Thanks for pointing me to this :)
i think you should write more and more. You have a great writing style and you give valuable information too.
I am bookmarking your blog link :)
And regarding this post of yours, as you rightly say getting a dedicated SME in software companies is impossible.
You or me as a technical writer needs to glean information from the programmers.
And of course learning and researching about the product is the most important thing to do before you start writing any kind of documentation. Therefore interaction with programmers and other people becomes a continuous affair.
You have hit at both these vital points beautifully :)
Good Luck!
Rupa
Hi Sreya,
ReplyDeleteThanks for your useful post. I have recently launched a Web site for e-learning professionals. Through one of the section titled ‘Planet’s Pick’, I select my favourite bloggers and blog posts on a weekly basis. Its my pleasure to select this post as my favourite blog post of the previous week. Please find additional details in the following URl:
http://elearningplanet.com/?page_id=11
Have a good day. Expecting more innovative and useful information in your blog…..
Regards,
E-Learning Tyro
http://elearningplanet.com
Good job capturing this. Thanks for the comment on my blog.
ReplyDelete