How to start project when source Word docs keep changing

[ccardimon]

The catch here is I have multiple Word files that are updated versions of one another.

As soon I get one Word doc imported and begin editing it, I get an updated version of the same file. It will be larger and have many changes.

Is there a way to have Flare perform a "diff" on the two (or more) Word files, and then import only the new stuff?

How do you folks deal with projects where you import a Word doc to start the project, and then another Word doc comes along that supercedes the previous doc?

Is there a way to preserve the work you've already done?

Comments, hints, suggestions are welcome. I'm ready for a dirty martini and a cigar.

[KevinDAmery]

I haven't worked with it much, but you can re-import the file. I'm pretty sure that you would have to make sure that the names are the same, which may mean that you have to do some file management to make sure that the file you import gets recognized by Flare. The downside is, if you've done any post-processing in Flare alot of it may be over-written when you reimport.

As said, I haven't done this much myself (one of the benefits of being the guy who maintains the documents is I can decide where the master lives - oddly, I choose to have it live in Flare not Word ) so if you need more detail than that I'm afraid I can't help much.

[ccardimon]

The downside is, if you've done any post-processing in Flare alot of it may be over-written when you reimport.

That's the problem. You think you're ahead of the game, but then your post-import processing gets overwritten and you're back at Square One. Sigh. This has happened three times so far, with the promise of more to come.

[RamonS]

That is why smart companies like MadCap invented systems that are capable of single-sourcing. And that is why smart writers should use such a system rather than Word, which IMHO is capable for producing meeting notes and the casual office flier (even Microsoft says it is intended for light to medium office correspondence, which doesn't include that tech or manuals).

Now, here is how I would do it if someone forces me to touch a Word document: I'd make sure that I have a version of all docs that I can expect. Then I import those and do the tasks as if this is the final version. I write down the steps and note how much time this takes from start to finish. Then I'd double that time and count back from my delivery date, which gets me the date until I will accept any changes. The versions on that day will be what is in the final version I will deliver. No exceptions! Of course, I'd tell my boss exactly the same thing and if she or he is a good boss it won't be an issue.
Otherwise changing the engines on an A380 in mid-air is a more promising task.

[ccardimon]

That is why smart companies like MadCap invented systems that are capable of single-sourcing. And that is why smart writers should use such a system rather than Word, which IMHO is capable for producing meeting notes and the casual office flier (even Microsoft says it is intended for light to medium office correspondence, which doesn't include that tech or manuals).

Now, here is how I would do it if someone forces me to touch a Word document: I'd make sure that I have a version of all docs that I can expect. Then I import those and do the tasks as if this is the final version. I write down the steps and note how much time this takes from start to finish. Then I'd double that time and count back from my delivery date, which gets me the date until I will accept any changes. The versions on that day will be what is in the final version I will deliver. No exceptions! Of course, I'd tell my boss exactly the same thing and if she or he is a good boss it won't be an issue.
Otherwise changing the engines on an A380 in mid-air is a more promising task.

Our processes are a wee bit more chaotic than than. Everything is in Word. Unless it is in PDF. I get to import it into Flare and do the best I can with it. I accept any and all possible changes to any and all docs and any time, including the day I'm supposed to publish. Such is life.

[NorthEast]

I guess the key thing here is to minimise your post-import editing to the absolute minimum.
What kind of editing do you need to do?

For changes to the text or styles used, you could make them in the Word document before you import it into Flare. You could then give the Word document back to the people who produce it, so at least they're using your edited version as a basis for their next set of changes to the document.

[ccardimon]

I guess the key thing here is to minimise your post-import editing to the absolute minimum.
What kind of editing do you need to do?

I'm getting my docs from someone who knows the application quite well, but whose command of the written word could stand improvement. Lots of sentence fragments. Many inconsistencies. Stuff that needs to be hammered into readable material.

LOTS of post-import editing that I will let slide should the deadline demand it.

[RamonS]

I guess the key thing here is to minimise your post-import editing to the absolute minimum.
What kind of editing do you need to do?

I'm getting my docs from someone who knows the application quite well, but whose command of the written word could stand improvement. Lots of sentence fragments. Many inconsistencies. Stuff that needs to be hammered into readable material.

LOTS of post-import editing that I will let slide should the deadline demand it.

Well, this seems to be the common misunderstanding that management or process problems can be fixed by technology. Does anyone reasonably expect to get high quality docs when on the day of release changes are still coming in? Anything short of copying and pasting followed by a click on build target is asking way too much.
Does the software change until the day of release as well? Or is it just that the SMEs change their minds last minute? You may deal with this for the time being, but an approach like this is unsustainable. I am convinced that software development doesn't do such - sorry for the harsh word - monkey business. This is plain insane and probably the reason why you asked the question in the first place.
Flare projects aside, I recommend talking to your manager about this. There has to be some process in place and some hard deadlines for the SMEs to submit their docs. The only scenario where this continuous change may work is when all that gets published is hosted web help where you can update content at free will without having the users do anything. And even then, keeping it in constant flux may confuse the users more than somewhat outdated content.

Maybe this might work: have the SMEs submit docs by date A, then compile the output in the format needed as well as a Word doc. The Word doc goes back to the SMEs for review and annotation. These reviews have to be submitted by date B (which should be chosen reasonably depending on what the SMEs do besides writing docs, my guess is they are consultants, trainers, supporters, ...). You can have more than one revision cycle, but I wouldn't go for more than two or three. If they cannot get it straight after one initial submission and three reviews they probably shouldn't write those docs. The final review is then early enough due so that you can work out some kick-butt help / manual that is of high quality.
This may not work out too well depending on how the SMEs receive their information. Does it come from functional requirements? Peer reviews? Other sources? I don't know anything about the process in your company, but my experience is that the tech writer benefits dramatically from being involved in the development / QA meetings that cover new or changed functionality. You may still rely on the SMEs to craft the docs, but I am sure that fixing the linguistic flaws and prettifying the whole thing is much easier for you when you have an ever better understanding of what it is all about (and you know a lot about the product already).
I always had the luxury to be a tech writer as part of the development team doing testing and level 3 support as well. That made me the SME and writing help was a heckuvalot easier that way. My guess is that the apps you are documenting are too large to have one person know everything. Even then, knowing more and keeping the SME-TW link a two-way street will insert a fair process and produce better output with less stress.
That said, these are the experiences I made and they may not work in your situation. So take from it what seems useful and ignore the rest.

[ccardimon]

Maybe this might work: have the SMEs submit docs by date A, then compile the output in the format needed as well as a Word doc. The Word doc goes back to the SMEs for review and annotation. These reviews have to be submitted by date B

In a perfect world, sure. This is what happens here. I get what I get when I get it. I "fix" it, asking for clarification if necessary. There isn't any formal review and annotation process. Annotation?! HA! What's that? When I am finished doing what I need to do, I ask the SME if they want to look at it. They never have the time. I go live with it, in PDF and WebHelp formats, copying my manager and the SMEs and the rest of that product's team. I ask to be notified should anyone spot an error. And that's the way it is.

[RamonS]

Well, as mentioned before, talk to your manager. If the company wants to keep you around for a long time they need to fix the process.