Responsibility for customer technical documentation 2

[foxbat1979]

Hi,

I've been working in project management for major oil & gas solution providers for about two years now.
As things turn out, my manager has recently decided to take on the responsibility for having his people create part of the technical documentation in stead of having the engineers do that.

Since my colleagues and me are firmly opposed to this decision, we have not kept silent about this and for me things got slightly out of hand recently when I got into a heated converstation with my manager about the sheer basic point of project management creating/writing technical documentation.

As far as I'm concerned technical documentation should be created and supplied by engineering because:
- They are the desiginers/engineers and have all the applicable technical knowledge
- Project managers are supposed to expedite client project documents in stead of writing them

Also I've calculated that this will require 300-400 extra working hours for me on a yearly basis.
Upon telling my boss he said: Ok, we'll need extra resources then....

Within the company we have received significant support for our point of view, but the problem is that things have turned quite political since my manager actually hired a guy for coordination of templates, basic texts etc....

Since he's now pushing things by formalizing responsibilities in a working procedure, I've got the feeling this is not going the right way.
One bonus is that we've received support from an important management figure who has to sign off on this change in responsibility.

How do you guys feel about this? Is it me just nagging, is my point of view regarding technical documentation responsiblity going a bit too far?

But most of all: Any tips on turning the tide?

Any opinions highly appreciated.



Project Manager oil & gas equipment

 

[PeterStock]

Your job responibility is to do what you boss tells you to the best of your ability. If you do not feel you can do the job, let him know that. If it is somethink that makes it a problem to do your other tasks, have him tell you what you should delegate to someone else or what does not have to be done. If your company needs to write that much documentation, maybe you should hire a tech writer.

Peter Stockhausen
Senior Design Analyst (Checker)
Infotech Aerospace Services

 

[SomptingGuy]

I suppose it depends on whether end user documentation should be written by those who know how a product works or those who have exerience in using it (and working with customers who use it).

I would have thought that a tech writer would fall between the stools: doesn't know how the product works; never needs to use it in anger.

- Steve

 

[ctopher]

I strongly feel that documentation should stay with those that create the designs.
Go with your manager's decision, eventually it will come back to you. A lot of manager's do not have the abilities to keep track of engineering documentation.

Chris
SolidWorks 09, CATIA V5
ctopher's home
SolidWorks Legion

 

[foxbat1979]

Thanks for all the replies & opinions!

@ctopher
Going along right now and let it come back to me: I just don't think that will happen once things have been settled. The reason for this is that I work at one of the largest corporations in the world and these things don't just turn around in a matter of months, rather years.

@SomptingGuy
The guy he hired for all the basic texts, templates etc. is indeed a tech writer. He has no in-depth knowledge of our systems whatsoever.

@PeterStock
I think just doing what the boss tells me to do is not what is expected from a people who manage multi-million Euro projects. I don't think that's the correct attitude when you're in project management. I just can't sit back and watch things go wrong. Because when things do go wrong, they end up on my desk......
No pun intended, it's just the way I see things

I do think, that I will have little choice but to keep involved in the process and aim for "damage control", especially if other senior management people also go along with it.

Project Manager oil & gas equipment

 

[KENAT]

What do you mean by "technical documentation"?

Do you mean drawings and design calculations/reports?

Or do you mean user manuals or the like.

Or something else specific to your industry?

On the first I find it hard to believe that anyone but the engineers (perhaps with drafters or similar) should be doing it.

If the latter 2, which it sounds like is the case, then there may be a case for someone else doing it. So long as they get the required information. Either way, dedicated project managers wouldn't be my first choice to be writing true technical documenation.

On the issue with disagreeing with your boss, sometimes no matter how 'right' you are, if they don't want to hear it they wont. So you either buckle down and do your best to make it work - damage control as you call it. Or you quit. There is the option of staying and deliberately undermining them but I doubt anyone here would seriously recomend that.

KENAT,

Have you reminded yourself of faq731-376 recently, or taken a look at posting policies:

http://eng-tips.com/market.cfm?

What is Engineering anyway: faq1088-1484

 

[macmet]

I've had this sort of argument before. I got stuck doing an O&M manual for a project I wasn't involved with. I knew it was a unique project so I couldn't base the manual on one I typically write for my projects. So, I fought and fought and finally gave up and agreed to write the manaul with the understanding that the project manager (aka my boss) would look it over. After all, I wasn't included in any portion of the project leading up to it so I knew nothing about the project. Not to mention, I had my own projects on the go.

So - hopefully this doesn't get too long - I wrote it up based on what I knew and how our typical projects work. I put it on his desk and asked him to proof read it. A few weeks later we got a call from customer saying they wanted their F*$&!($ manuals and I was asked to make electronic copies. I was told that as long as I used a typical system as a template it would be fine.

So I made up the disks, grabbed the manuals, sent them to site. Then I leave for my project and get an email from my boss saying the manuals are all wrong and blah blah blah. Well apparently the customer got them and realized that half the information didn't apply and yada yada yada they weren't happy.

Moral of the story, IMO the documentation should always be done by the project manager or the lead engineer. If my boss didn't try to dump his work on me and he spent the time on it the customer would have been much happier and it would have saved everyone a lot of time.

I also feel that five years down the road the only documentation of our system that will be looked at is the manual. I think it's important to have it look professional and should not be taken as a part of the project that can be done by just anyone.

 

[ScottyUK]

Looking from the O&M side, the manual and supporting documentation is often the only thing the customer will have to assist him after a little time has passed. During that period companies may have merged, folded, or changed business direction, all of which leave the customer with a problem. A good manual is a lifeline: it may be only resource the customer has, and if it is well written it is priceless. A bad manual is a waste of space and resources.

I don't necessarily think that the engineer should write the manual in all cases, but he absolutely should determine the contents initially and then proof-read it. In the case of really detailed technical manuals then likely the engineer is the only one with the level of knowledge to write it, although benefit may be found in having a tech writer tidy up the grammar and generally make it readable afterwards.


----------------------------------

If we learn from our mistakes I'm getting a great education!

 

[graybeach]

I work on the engineering side at a utility. We regularly get run roughshod over by Project Management in the name of expediency. At times critical technical details get glossed over with real consequences. On the other hand, the engineers are often too detailed and too conservative to really be effective. In general, I think the two groups just need to be more cooperative with each other.

The engineers might know the technical details, but there are many who lack proper writing and organizing skills. Many of the specs and documentation produced by our group contain serious ambiguities. It just gets crazy. For example, a number of engineers here list every possible code and standard under the sun at the beginning of each technical specification. They see it as covering all possible situations, but what it really does is weaken and muddy the requirements. The best project managers here really look at this stuff and call the engineers on it.

Maybe you have a similar situation with the technical documentation at your company. You can be a true project manager who gathers the information from the technical sources and, with the help of your technical writer, organizes it in a clear and logical manner. Finally, you have engineering and the end users review to make sure all is clear and correct. That's what I would do in your place anyway.

 

[cranky108]

Just do like some of our suppliers, Print all kinds of sales pamplets, and no real technical information. (maybe that why we try to avoid them).

Or provide only technical information, and very few sales pamplets. (Maybe that's why the managers din't like them).

Or just have great sales people to take the managers to lunch, and provide no technical or sales pamplets. (maybe why they get all the big projects).

 

[KENAT]

I've typically seen 2 ways of 'technical publications' being done.

The first is that the tech pubs person has some technical aptitude, is shown how to operate the 'system' or works it out from drawings or similar and then documents it. Where relevant this should still be reviewed by the 'technical experts' for accuracy. However, for really complex systems this approach isn't always realisic. The best tech pubs guy I ever worked with did it in this way, in fact he virtually refused to write a manual for anything he hadn't actually done himself.

The other way is that the relevant engineer(s) put together a set of instructions, and the tech pubs guys basically format it/make it look pretty with the company header etc. For complex operations this may be the only way to approach it, and allows down skilling of the tech pubs person but obviously requires more of the engineers time. The temptation with this is also to use a secretary or typist (or modern equivalents) to do the formatting, but this doesn't always get as good a result.

Third option is obviously just for the engineers to do it all but I can't help but think this tends to waste more of their time is justified and may not end up as easy to read etc. as might be desired.

In none of the above would I expect a dedicated project manager to be doing it. However, places I've worked the project manager often has some technical or similar input as well so might be suited. Certainly if relying on the tech pubs guy just to format it, the project manager would be involved in accumulating the material.

KENAT,

Have you reminded yourself of faq731-376 recently, or taken a look at posting policies:

http://eng-tips.com/market.cfm?

What is Engineering anyway: faq1088-1484

 

[foxbat1979]

Apologies for my long absence in my own thread but I was travelling abroad without internet connection.

@Kenat

The "technical documentation" I am referring to is installation & commissioning documentation of some serious pieces (multi-million Dollar) of rotating equipment for oil&gas applications.

Now as far as mechanical installation goes, I really know my bit even though I don't have the hands-on experience.

But when it comes to commissioning such equipment, I'm feeling seriously out of my depth when having to make commissioning manuals with the regular technical documentation that is available in a project.

I agree with it that no matter how right you are, if the boss ain't listening you're done. Luckily things are far from over in my situation so I'm not buckling down yet......

Project Manager oil & gas equipment

 

[NomLaser]

I agree with Peter. If you aren't willing to do what is asked, I know a bunch of people out of work that would be willing to put up with your boss for a paycheck.

 

[plasgears]

This smells like the boss is not an engineer. Project engineers organize engineering work - not specify technical details. Sorry.

 

[SNORGY]

My opinion is that if the Mechanical Engineer (or "Project Engineer" on smaller jobs) sits in on all the P&ID / SD Key Reviews, then with input from the Controls group, the Mechanical Engineer is probably in the best position to write the Commissioning / Start-up / O&M Manuals. (Unfortunately for me...). Where I work, that's ussually what ends up happening.

It's tedious, unpleasant work, but it's remarkable how much you pick up from it. Especially in an EPC office, it can typically be said that a whole bunch of P&IDs and Line Lists and SD Keys exist but nobody really knows how everything works. (That's a scary truth...). The person (or people) who know how everything works is the person (or people) who can figure out how to start it up and get it running when the only thing in the pipe and equipment is air at ambient pressure.

I also agree that you can't make it entirely generic. Each system needs individual treatment, at least in areas where it is different from the one before it.

Regards,

SNORGY.