Opportunities to Produce Customer Documentation in the Application

Opportunities to Produce Customer Documentation in GR0-GR2

According to the Research Process description by Riihilahti (2004), the research process should yield a Project Plan and a Project Report. There is also mention of feasibility reports and a research report. Perhaps these two are part of the aforementioned project plan and project report. At any rate, it seems to me that these would contain descriptions of functionality, processes and benefits to the customer with which the participants in the process could begin forming technical documents with eventual customers in mind.

Perhaps there could be some sort of template into which the project team members could write e.g. the following:

ƒ What is the aim of the application product (or family of products) being researched?

ƒ Assuming the product is going to be sold one day, who will use it?

ƒ What will users use the product for? What goals will users have when using the program?

ƒ What must users do to meet their goals? In other words, how does the product work?

ƒ What all features or functions are provided? Which features and functions are primary and which are secondary?

Answers to these and other such questions could serve as a starting point when planning customer documentation in the Product Creation Process.

Opportunities to Produce Customer Documentation in G0-G5

Customer documentation is a vital, integral part of any product. Therefore, when a product is produced, the planning and production of customer documentation should be allotted equal attention and effort. In other words, the customer documentation process should be monitored throughout the gateways. I feel that if project members are aware of the necessity of allotting resources and attention to customer documentation from the very beginning, then there is a greater likelihood that it will be ready for delivery concurrently with the product.

At gateway meetings, project milestones are discussed, and project participants ensure that certain key milestones have been reached so that the next phase can

commence. I think it would be very essential to add user documentation-related items to this list. That way, project participants would have to ensure that the documentation is being produced along with the application. Ideally the documentation would be ready to deliver to the customer when the application product is delivered.

When human and monetary resources are discussed and a business plan is made, then human and monetary resources should be allotted for the customer documentation process. When a project plan is drawn up, project personnel should also plan for the customer documentation process. It should be integrated into the project plan, in which case resources would be allotted and the steps in the documentation process would be scheduled as well. If customer needs and wants are studied in this phase, then these

factors should indeed form the very core or foundation not only for the product under development, but for the customer documentation also.

The freezing of product specifications is an important juncture in time for the customer documentation process. It is the perfect opportunity to begin producing customer documentation, since it is likely that there will be only minor changes to specifications in the ensuing phases. If the product has been lab-tested, then information gained that way can also be incorporated into customer documentation.

When the product is tested and verified, then solid knowledge and experiential information on how the product functions can be collected. This in turn means that customer documentation preparation can proceed on sure footing. If there are drafts of the operator and tuning displays, then this means that explanations of these and relevant workflows can be added to customer documentation. It is very important that at least rudimentary documentation be completed before a customer pilot project is done. The final customer documentation can be updated and edited based on the experiences of the customer pilot project.

At one point in the product creation process, all product documentation, including manuals and installation guides, must be ready. The statement in process descriptions that the documentation must be ready at a certain point is, as far as I can tell, the first mention of manuals and installation guides in the sources I have used. It is very surprising to me that they were not mentioned previously, especially considering that most other facets of the product are taken into account in great detail at many phases of the project. In a project in which the goal is to produce something according to carefully predetermined specifications, using certain resources and according to a set schedule, how is customer documentation to come into existence if it is not mentioned until well into the process?

In my experience, a project is usually nearing its end before project participants begin talking about the need for a manual or the need to update a manual. This is too late. If there is a pilot project or a prototype of the project, then usually there is no documentation for it. This means people outside the project have no idea how the prototype or pilot product is supposed to work. The product documentation process, therefore, should begin before the project actually begins, because the prototype is actually used by customers in the customer setting. At a mill where project engineers e.g. must add the new application prototype to the automation system, it is obviously expected that the customers will use the prototype and judge its feasibility. Customers need user guides to be able to operate, tune and perform maintenance on the application prototype. Specifically, a technical manual for automation engineers and maintenance engineers and an operator manual for operators are needed.

There are many cases, however, in which no user manuals are provided, and customers thus have difficulties using prototypes. In fact, there have even been cases in which the mill management has forbidden mill personnel from using a prototype until they receive documentation on how the product works. This in turn means that project engineers must try to create some user documentation ad hoc. I think that such a document, produced under stress, on top of other work, and in a great hurry, would not necessarily be of the same quality as one that is planned and scheduled ahead of time.

Obviously the production of a prototype product involves planning of specifications and functions. Therefore it seems possible that with the proper recording and documenting of such details, a preliminary, rudimentary document could be produced with little extra effort. This would only require that this task be written into the project milestones. All the things that are necessarily recorded somewhere anyway could be a good starting point for a technical manual.

5.2 Steps to Achieve a Higher Information-Process Maturity