Sunday, January 23, 2011

The Costs of Doing Without Proper Documentation and Technical Writers

I haven't given it as much thought as I need to, but I really need to go through my experiences with my last employer and try to find ways to learn from what happened there.

There are so many "liability" reasons not to write about a previous employer. I don't wish to trip any ethical wires, I don't want to hurt my former employer in any way, and I certainly don't want to be sued. I will change the names of the guilty and the innocent, several times, if necessary. I will do my utmost to make this instructive.

Some background. The company I was with, previously, was in the midst of a transformation from older systems to newer systems. The way that it did business was, increasingly, through the web and through sharing files with clients. This is nothing new, or exclusive, but the company had a hard time walking away from those legacy systems. The older employees weren't a problem; they were simply trying to get through each week and keep the information flowing. The need to get information to the customer was paramount with this company. It was sacrosanct.

As the newer system, which was Oracle-based, and I probably don't have to say PeopleSoft, but I will, came online, there were issues. It wasn't flexible enough. It didn't do what the clients wanted. And it was heavily customized.

The end result of the heavy customization? It didn't work and no one knew what had been done.

Now, let's be fair to the company--it was focused on delivering products to customers. It was focused on the here and now. It was delivering information to clients as per the contracts it had signed and it was giving them great service and a great product. The drag on all of this was the inability of the people trying to transform the business to get past the defects in the software package it was trying to roll out and to stand up these new systems.

It doesn't take a rocket scientist. You have a legacy system. It has to go. You replace it, then you test and re-test the replacement, and then you give that replacement a real-world, small-sample test with the clients. Then you preview it for all. Once you have everyone on board, THEN and only then do you retire your legacy system.

What held up this process at my old company was not the people--the people were great. The software wasn't the problem because the software was fine. It could, when set up, deliver what it promised.

No, the problem was centered around documentation. Not enough people knew what had been done previously by contractors and temps that had been brought in to fix key issues. Without a single document that brought together all of the components under one cover, no one knew what the entirety of the system was. No one knew, for example, what was in a certain kind of table in the PeopleSoft configuration. And, in layman's terms, when you don't know what's in a table, you don't know how it modifies or affects other tables when key processes are run.

Technical Writing, in other words, was there, but not at the holistic, comprehensive, or top level of the project. There was documentation, yes. But it wasn't comprehensive. There were plenty of orphaned Word files floating around on shared drives, but no one really owned them. And, there were directories of documents in Microsoft Project, but spread across different releases, different pages, and different project pages.

I believe that every project needs a technical writer who owns the documentation, updates it, and works closely with the developers, managers, planners, coders, and users. Without that, you have a mess.

No comments:

Post a Comment