tag:blogger.com,1999:blog-1513616792028141844.post406097349946559188..comments2023-04-14T06:11:34.177-04:00Comments on Connecting 2 the World: Formulating the new work literacy frameworkV Yonkershttp://www.blogger.com/profile/11910904367068063554noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1513616792028141844.post-92108394021144205882008-08-09T09:05:00.000-04:002008-08-09T09:05:00.000-04:00Tēnā koe Virginia!I have been employed by two majo...Tēnā koe Virginia!<BR/><BR/>I have been employed by two major companies in the last 20 years. In the first I was a computer trainer. I worked closely with other employees who had the skills that your husband has. I wrote training manuals and sourced the knowledge from the organisation to write those. The reason I had to leave that job was because training was restructured out of the organisation - something that was happening almost globally at that time.<BR/><BR/>In the second I've been a teacher, team leader and elearning teacher. I have had little to do with computer training but have observed it happening (or not) over the years.<BR/><BR/>I agree with what you say about it being no longer clear where the knowledge is. The changes in information management in both organisations that I worked in over that 20 years were similar and not unlike the changes that have happened with instructional information associated with software and the function of electronic devices. It can be summarised in one sentence that was said to me over a decade ago when I asked for a computer manual - "No one uses a computer manual!" There were two reasons for this. One was that some people couldn't be bothered reading instructions (what's new?) The other is that there aren't any manuals any more (a generalisation).<BR/><BR/>Enough said.<BR/><BR/>Ka kiteBlogger In Middle-earthhttps://www.blogger.com/profile/08722634477041121797noreply@blogger.comtag:blogger.com,1999:blog-1513616792028141844.post-66767849549885053762008-08-06T08:39:00.000-04:002008-08-06T08:39:00.000-04:00Ken,Interestingly enough, the process you describe...Ken,<BR/><BR/>Interestingly enough, the process you described as no longer being existent is exactly what my husband does! He is a programmer by title, but he really is the person that identifies user needs, creates the specs for "canned" programs consultants create, and develops user and programmer documentation (online format).<BR/><BR/>I think the process you outlined was changed at the end of the last decade because of the outsourcing of work. It is not that the process has changed as much as the locus of knowledge has switched from the creators and users to the project managers. It is no longer clear where the knowledge is (thus the amount of knowledge management research out there).<BR/><BR/>I agree with you that we have gone through this process before. I think as new frameworks are required, there should be a systematic analysis of what the impact of systemic changes will have on stakeholders.V Yonkershttps://www.blogger.com/profile/11910904367068063554noreply@blogger.comtag:blogger.com,1999:blog-1513616792028141844.post-17654201423231733762008-08-06T02:22:00.000-04:002008-08-06T02:22:00.000-04:00Kia ora Virginia!This is going to be one of my lon...Kia ora Virginia!<BR/><BR/>This is going to be one of my long comments.<BR/><BR/>I wonder if we have not already been through times when what we’re looking for here was already well defined. The ‘check list’ that you mentioned Virginia, correct me if I’m wrong, seems to match what used to be contained in specifications to do with the workplace. In the 80’s, for instance, it was not uncommon around an office to find specifications that defined various actions and expectations about anything from what a computer application was expected to do, to the tasks expected of the employees.<BR/><BR/>In developing a new piece of office software, such as a database interface for instance, there would be the business spec, the user requirements spec and the system spec. The system spec defined, among other things, the requirements of the system as presented to the user as well as system procedures documentation and functionality etc. The business spec essentially defined the tasks as well as knowledge of business procedures. Essentially the system spec reflected the business specification in its functionality. User requirements were a pre-defined set functions required to be performed by the system in order that, once built, it would be useful.<BR/><BR/>Training manuals that were created for the office software would incorporate elements of the business specs and the system specs within their training sections. Sometimes the training manuals incorporated the user specs. In essence, they contained what was considered the basics of what the user had to know to be able to perform the business. Manuals of that description are rarely provided in the workplace now.<BR/><BR/>There were many ways training manuals as such could be written, and in those days they were printed texts. Depending on the budget available, the author had to be able to assess what ‘pitch’ to take when it came to writing the text. It was always easy to test a manual to see if it was useful, part of the job as a trainer. On visiting the office where I’d completed the delivery of training and the business was well underway (implementation complete) I would ask to see one of the training manuals. Invariably I’d be given a well-thumbed dog-eared ring-bound manual that delivered a pile of loose pages at my feet when opened. <BR/><BR/>Manuals that were useless were returned in pristine condition. Fortunately this didn’t happen much, but manuals that met this criterion were usually written on limited budgets as overviews, outlining only a brief functionality of the software with perfunctory instruction to the user. In short, they didn’t really cover what we might now refer to as the elements of workplace literacy associated with the particular application. Users found such manuals virtually useless.<BR/><BR/>All the dog-eared well-thumbed manuals were regarded as gold when they went out of print. They would be explicit in defining the step by step needs of the user as well as the skills required – not unlike the instructions found on Sue Waters’ helpful blog-posts. Why were these books regarded as so valuable? I believe it was because they contained so much pertinent, useful and usable information. Now I’m not advocating a return to these days. Workplace budgets would not permit that anyway. But on reflecting on the sort of skills that were outlined in the books, and they were many and diverse, they gave a very clear pitch on what was required knowledge and a summary of the skills required by the user.<BR/><BR/>One of the reasons these days have gone is the ever changing requirements for new software and new business procedures in the workplace. The cost of training and the documentation that went with it became a substantial part of the implementation budget of most business projects. What happened was that training was kept to a minimum or simply not provided at all. This all happened around the last decade of last century. What went with it were the procedures for defining what was required of the user in the workplace and the awareness of the need for these to be well defined and documented.<BR/><BR/>Ka kiteBlogger In Middle-earthhttps://www.blogger.com/profile/08722634477041121797noreply@blogger.com