This is because the human has difficulties projecting himself in time.

Use the time machine analogy. Your life is versionned. Every day you have a new version of your life: new things and lost things. Hopefully more assets, less debts,... but more fat, less hairs, ... hopefully more knowledge, less doubts, ....

Then you will have to explain branching ;) And there you hope they are fans of Fringe ;)

You can use the book analogy.

When you write a book, you first write a draft version. Then you read it, make some changes and reread it. Until you give it to somebody else to read. And of course they have remarks too.

Each change makes a new version. And although you normally use the latest version, sometimes, you regret a change and want to rollback. Possibly the whole book, possibly a single chapter. Versioning gives you this opportunity.

Then the subject of branching.

The book is almost finished, and it needs to be translated into French. So you make a copy of the book and send it to the translator. In the meantime, you make some changes to the original book. Some of them are added to the French translation and others never make it there.

Because, in the non-programming world, to change a competed product is very hard. Intentional changes, which are thought through, are not easy—take buildings, for example. And once the changes are made, it's hard to "revert" to previous version.

Contrary to that, changing software is very easy (easier than even other media products; say, a movie) , and "checkout an older version" is a common task in the software world.

Thus, the notion of versioning contradicts out everyday experience, which usually confirms that only one, current version of a thing exists (for software it's not true). That's why it's hard.

You mention that even simple document versioning is giving people difficulties, so maybe you're not explaining it well, or your team are not that bright.

Our developers use git on the commandline for versioning, and once they're up the learning curve, they all cope fine with it. I haven't bothered trying to explain git to non-technical staff because with them there is much less direct collaboration on individual documents - for this stuff we use DropBox, and I've not seen anyone struggle yet.

In my experience they catch on pretty quickly.

Version 1.0 - We sell for money.

Version 1.1 - Small enhancements for some customers: we sell for a smaller amount of money.

Version 2.0 - Big improvements. We sell for lots of money.

Version 2.1 - Small enhancements for some customers: we se... "Wait a minute" says PM/BA "Rename that to 2.5 and we'll charge 5x as much". No amount of discussion from engineering will convince them otherwise.

Version 2.2 3.0 etc...

They need to be aware of various 'doomsday' scenarios. Computer, server, hard drive, whatever, breaks, isn't it great to have a backup? If you can't get them to agree on this concept, you can't move on.

Now, what if they were asked to make a presentation, but on the third page, the client would like to see it with and without the graph. What would you do? Make a second copy with the changes. If they told you they didn't want the graph, would you throw away the 'version' with the graph? Probably not because you never know. If you can't get them to agree on this concept, you can't move on.

Have you ever sent a file for review only to have the person change it? Did you keep your version? Did you have to give the file you sent them a different name because you know when they make changes it is too difficult to tell the difference or save them in the same folder? And aren't these names getting long? If you can't get them to agree on this concept, you can't move on.

Wouldn't it be nice if we has something that would just keep track of all of this for us? No more sending email attachments. No more wondering which one did the Boss make that change on, but I made another change and now we can't get them together. No more long file names trying to explain which 'version' we are on. If you can't get them to agree on this concept, you'll just havce to move on.

I've found that engineers (elec/mech etc) don't start out understanding configuration management, but grow into it ( or drive everyone crazy.)

Software developers might understand versioning.

Non-technical people in general understand nothing from this space. It's technical.

It's part of engineering discipline that they've never had to learn.

An they can choose not to. So plenty of them will.

The only solution is to work somewhere that has management support for a disciplined process. CMMI level 2 compliance is 400% more productive in time and money but people avoid it.

Well, Alice writes a blah. Then Bob gets the blah and makes some edits, and Carol gets the blah and makes some edits. These are versions. Then Dan comes in and tells Alice to make a bunch of changes. This is another version. The next day, Dan comes back and says that everything he said yesterday was a lie, and that management wants Carols version of the blah from Tuesday. Having Carols version and being able to find it easily is called version control.

My guess is that most people have a number of things to care about, so versioning doesn't make it to the top of their list. It's like insurance, the payback is of low probability and it's not free.

For the project artifacts that you outline, if there is only one person involved (e.g. a BA's document describing a calculation), they may quite reasonably assess the payback of keeping old versions to be zero.

Requiring more careful versioning of these kinds of things may introduce a hostile element into a project's atmosphere, as the reasons for doing it may be kind of adversarial, i.e. people are expecting to have arguments about old vs. new versions, so they want the old versions to be available as proof.

Do you mean versioning or branching/merging?

I think it is pretty straightforward to understand versioning. "We saved the version from Tuesday. Then we did more work. Now it is Wednesday. We can go back to Tuesday's version."

Branching and merging is much harder to explain. "Well, Bob made changes in 1.1 that conflicted with Alice's view of 1.1 and submitted first, so 1.2 has Bob's changes, but 1.3 has Alice's changes too except some of Bob's got integrated later, so..."