IET
Decrease font size
Increase font size
Topic Title: Technical documentation in all its forms
Topic Summary: The importance of technical documentation, create and share it. Your views and experiences required
Created On: 02 December 2011 10:51 AM
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 02 December 2011 10:51 AM
User is offline View Users Profile Print this message


Avatar for broweriie                                         .
broweriie

Posts: 24
Joined: 25 July 2008

I am asking for your views and experiences over your lifetimes as engineers and scientists, at all levels, on the subject of technical documentation. My motives for this forum are that I want to make a case for more time and resources to be put into technical communication and knowledge sharing within my organisation. Much technical information is spread around an establishment, often in hand written form, you may be familiar with the phrase 'on the back of a fag packet'. My view is that often this information is lost when people leave, are promoted and in some cases held back. With companies making a big issue of the value of knowledge, it's often hard to find the relevant piece of technical data. This is not a new discussion and I am sure you have come across the subject before. It is becoming more topical so can I ask you three questions without giving me any confidential details;

Is sufficient time and energy spent on knowledge sharing and is this culture amongst engineers/scientists a high priority?

What value do you put on technical documentation, in whatever form, and how does impact on your organization?

What is your experience of documentation within your organization, has it changed over time and how would you improve it further in terms of structure and management?
 02 December 2011 02:17 PM
User is offline View Users Profile Print this message


Avatar for DavidParr.
DavidParr

Posts: 242
Joined: 19 April 2002

I have personally encouraged the engineering community to keep technical data by making it easy and valuable to do so. Our processes are built around an interactive system that provides the electronic equivalent of fag packets - somewhere to scribble something (everything) down, as well as providing places for the necessary more formal documentation!

Documentation is everything! If it isn't written down it never happened.

To answer your questions based on my current role:

1. Yes and Yes
2. Very high. Without it we cannot ship a single item to our customers.
3. We have a good system which is subject to contiuous improvement as demanded by regulatory and Federal bodies.

Regards,

-------------------------
David Parr BSc.CEng MIET
PRA
 02 December 2011 03:21 PM
User is offline View Users Profile Print this message


Avatar for hamishbell.
hamishbell

Posts: 288
Joined: 11 September 2001

David can you share the details of the "interactive system"? I no longer have responsibility for others in this area so cannot complete the questionnaire. However, as a consultant, I have installed a Wiki based system at a client which proved useful for catching the notebook aspects rather than formal documentation.

I whole hearted agree that devising and maintaining documentation is absolutely vital. The background provided by people's embedded knowledge also needs to be captured.

Regards
Hamish

-------------------------
Hamish V Bell, BSc, CEng, FIET, FCQI, CQP
2013 - 2016 Elected Council Member
2007 - 2010, Vice President and Trustee
 02 December 2011 03:38 PM
User is offline View Users Profile Print this message



ArthurHall

Posts: 737
Joined: 25 July 2008

I totaly agree with the importance of documentation. I think one of the reasons records are not kept is because management dont allow time for Engineers to make records, mark up drawngs etc.

It is important to consider the media that is used for storing the data, paper is timeless but has its own drawbacks, electronic systems are short lived. I have been on jobs where all the oppererating instructions and settings were on 51/2" floppys, How do you read one of them these days? Even 31/4" drives are hard to find.
 02 December 2011 04:47 PM
User is offline View Users Profile Print this message


Avatar for DavidParr.
DavidParr

Posts: 242
Joined: 19 April 2002

Hamish, I have sent you a PM with some details.

-------------------------
David Parr BSc.CEng MIET
PRA
 05 December 2011 01:36 PM
User is offline View Users Profile Print this message


Avatar for broweriie                                         .
broweriie

Posts: 24
Joined: 25 July 2008

Thank you for your feedback gentlemen. I am encouraged and hope others will add comments to this exciting discussion.

Hamish you said 'people's embedded knowledge also needs to be captured'. I have to say that this may be a big issue. I have discussed this particular matter with many staff. Some view their knowledge as personal to them, not a company asset. This needs to be changed from the top down. Not having a specific methodology for knowledge transfer needs to be addresses.

David said 'Documentation is everything! If it isn't written down it never happened' ...Oh how I agree.

Arthur, you mentioned storage media and this too is an area that needs to be addresses. We do have a Wiki system but many people prefer paper. The younger engineers do however like the Wiki approach. I like books, A1 systems diagrams which I can hold up in from of the equipment.
Please keep talking everyone. Thanks
Julian Brower BSc (Hons) CEng FIET
Section Leader ISIS Accelerator Performance Improvement

Edited: 01 March 2013 at 12:45 PM by broweriie
 05 December 2011 03:15 PM
User is offline View Users Profile Print this message


Avatar for hamishbell.
hamishbell

Posts: 288
Joined: 11 September 2001

Julian, (and others),
Embedded knowledge is the inceasing knowledge of the individual added to their work for the company. In this respect, it must be considered as company property. After all, the knowledge was acquired during time that the company was paying the individual to carry out its defined work.. The individual is, in effect, given a perpetual licence to use or re-use that knowledge in other employments. If the knowledge forms part of a Patent, then the use of that knowledge is limited and is no longer useable other than by the company.

So what happens when a person leaves? Formal records such as work books or other technical notebooks should be retained by the company. (Howls of horror! How often does THAT happen?) Informal embedded knowledge, which often contains clues relating to difficult fault-finding or blind alleys in development, often leaves with the individual.

Capturing it may not be too difficult, if that culture can be grown in the company; finding the information later may prove more difficult. That is where a searchable unstructured recording system is needed. Unstructured because you don't know in advance what you might want to record and it is unwise to limit your chances of keeping innocuous information that proves to be vital at a later date. I'm a great believer in recording what DOESN'T work, as well as what does. Technology changes rapidly and what is impossible one year becomes possible in later years. If apparent deadends are known then they can be easily retried when newer faster technology becomes available.

I'm privileged to have seen David Parr's prize-winning system which is comprehensive, extensive, and excellently implemented. It provides facilities for both formal and informal records. It looks to have needed a significant personal contribution from him beyond company allocated time. However I presume it is "company property" and may not be available to a wider user base.

Corporate memory is important as a reference, but it musn't be allowed to stifle new ideas. I used to respond to "We've tried that before and it didn't work" by suggesting that now was a different era and that most Victorian patents that seemed far-fetched at the time could be implemented with a change of technology. Whoever would have thought that Babbage's failed ideas of mechanical calculation would be overcome by the transistor?

Regards
Hamish

-------------------------
Hamish V Bell, BSc, CEng, FIET, FCQI, CQP
2013 - 2016 Elected Council Member
2007 - 2010, Vice President and Trustee
 07 December 2011 08:19 AM
User is offline View Users Profile Print this message


Avatar for DavidParr.
DavidParr

Posts: 242
Joined: 19 April 2002

Hamish I blush!

Integral to my system are our own company-specific processes, however the general concept could be extended to any process within any field. The process as mapped must accurately reflect what the engineering community actually do, so there is minimal extra overhead or effort required to "capture" the documentation - this is a key element in my opinion.

-------------------------
David Parr BSc.CEng MIET
PRA
 19 December 2011 09:26 PM
User is offline View Users Profile Print this message



deleted_1_pwherritt

Posts: 17
Joined: 02 March 2002

David

I too am looking at how to implement a "corporate memory" and "lessons learned". As Hamish rightly says it is important to know what didn't work and why as well as the reasons behind the ones that did work. If there is anything you are able to share that might help with this I'd be very interested to see it.

Regards
Peter Wherritt CEng FIET
Currently on IET Council

-------------------------
pwherritt
 19 December 2011 11:19 PM
User is offline View Users Profile Print this message



deleted_1_pwherritt

Posts: 17
Joined: 02 March 2002

Alan

This is already done on an individual project basis - what I am looking for is something that works across projects so that lessons learned by one team can be reviewed by another. As Hamish says it is ideally unstructured as you don't know what you might be looking for in the future.

BTW I can't see the IEE document you refer to in this thread, is it somewhere else ?

Peter

-------------------------
pwherritt
 20 December 2011 01:02 PM
User is offline View Users Profile Print this message


Avatar for broweriie                                         .
broweriie

Posts: 24
Joined: 25 July 2008

Thank you all so far with your input to this forum. I would be interested in who runs the overall documentation within your organisations? Do you have a dedicated person or is it ad hoc? I am looking to create a post and see it more far reaching than just documentation. For an engineer to understand complex electrical/electronic systems, to produce systems diagrams, fault finding flow charts, train staff on how to use them via familiarity with equipment. Are you able to input some job title ideas for such a role?
 20 December 2011 03:08 PM
User is offline View Users Profile Print this message



amillar

Posts: 1918
Joined: 28 May 2002

Interesting discussion...

To give a slightly different perspective on this, our engineering team has an average length of service with the company of 15 years, and our turnover is tiny (one resigned and one retired in the last 10 years*), so it may seem that this is less of an issue for us. In fact, I think quite the opposite has happened: it has highlighted to the team the importance of good record keeping. Once you've been asked a few times "do you remember why you made this design decision in 1995?" you realise how easily we all forget, and in fact most of us find 6 months is a long time to remember anything!

(* Redundancies not included, as the company has to work out how to do a memory dump in that case!!!)

We used to run a traditional engineers' log book system, and, yes, they are still archived safely. However the standard of record keeping varied widely between different personalities, and, more critically, actually finding specific information could bear next to impossible.

We now run two parallel systems:
1. Format design specifications, where engineers are encouraged to explain not just how a design works but (almost more importantly) why it was designed that way. (Although called "design specs" we keep them live so that they can include retrospective information.) This is particularly important when design changes are required in future - there can be very subtle reasons why a particular component or circuit configuration was chosen which may not be obvious to future engineers or even remembered by the same engineer.
2. Design notes, which are completely free-form (could be scanned in sketches, lumps of text or complete Matlab files) but are referenced from a database so they can be easily found in the future. The key here is to ensure that adding them to the database is easy so that even the most harrassed engineer actually does it.

I'd strongly agree that the correct culture is vital: there needs to be a strong atmosphere of "if it's not written down, and it's not saved so that someone else can find it, it WILL get forgotten". I'm as guilty as anyone, in fact worse than many!

On another thought: re Hamish's comment
Corporate memory is important as a reference, but it musn't be allowed to stifle new ideas. I used to respond to "We've tried that before and it didn't work" by suggesting that now was a different era and that most Victorian patents that seemed far-fetched at the time could be implemented with a change of technology.

My belief is that you always need to listen to experience, but that doesn't mean you shouldn't question it. And it works both ways, when I hear "we've always done it that way and it seemed to work" it can also send shivers down my spine. It's all about taking the time to understand why and how things didn't (or did) work in the past - but I think everyone on this thread knows that

-------------------------
Andy Millar CEng MIET CMgr MCMI

http://www.linkedin.com/in/millarandy

"The aim of argument, or of discussion, should not be victory, but progress." Joseph Joubert
 20 December 2011 03:15 PM
User is offline View Users Profile Print this message



amillar

Posts: 1918
Joined: 28 May 2002

Originally posted by: broweriie
I would be interested in who runs the overall documentation within your organisations? Do you have a dedicated person or is it ad hoc? I am looking to create a post and see it more far reaching than just documentation. For an engineer to understand complex electrical/electronic systems, to produce systems diagrams, fault finding flow charts, train staff on how to use them via familiarity with equipment. Are you able to input some job title ideas for such a role?

In our case, I suppose I do! But I don't write much of it, just have ownership of the processes. Producing the documentation is part of each engineer's role, so whilst I might produce a requirement specification they will produce the design specifications, test plans, test reports, and design notes for their designs. And working in the field we do that is a LOT of documentation, but I don't think anyone else could do it effectively. Our colleagues in another part of our organisation do have full time document controllers or even technical authors, but for a team of 20 engineers a) we can't justify it and b) personally I don't think it helps the standard of documentation.

It will be interesting to see other views...

-------------------------
Andy Millar CEng MIET CMgr MCMI

http://www.linkedin.com/in/millarandy

"The aim of argument, or of discussion, should not be victory, but progress." Joseph Joubert
 19 January 2012 08:20 AM
User is offline View Users Profile Print this message


Avatar for broweriie                                         .
broweriie

Posts: 24
Joined: 25 July 2008

'Our colleagues in another part of our organisation do have full time document controllers'
Andy, sorry to take so long to get back to you. Christmas, new year and turning 50 in the same two weeks!!

I would be most interested to speak to some of these document controllers associates. I wondered if you could make an introduction via email or whatever. I am trying to adopt some best practice with this potential post and want to meet/speak to others in this field. Julian
 01 March 2013 12:55 PM
User is offline View Users Profile Print this message


Avatar for broweriie                                         .
broweriie

Posts: 24
Joined: 25 July 2008

Hamish, somewhat later than hoped, I have just read your comments

'I'm privileged to have seen David Parr's prize-winning system which is comprehensive, extensive, and excellently implemented'

Can you expand on that system?

Julian
Statistics

See Also:



FuseTalk Standard Edition v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.