In last month’s issue of the CIDM e-newsletter, JoAnn Hackos wrote that in oblivious organizations, management does not yet recognize the need for standard publications and is not ready for content management. The following are responses to that article.
Working for an Oblivious Organisation
Technical Document Writer
The Organisation I Work For
I work for a public service organisation in Australia. The organisation provides an assortment of services to the community, mostly relating to the building of public facilities. I work as a technical writer in the Information Technology (IT) group. Our group provides computer, network, and help desk support (anything computer-related) to the organisation. There are about 80 of us, providing a range of services. (We do very little development.)
Why I Was Employed
I was employed a year ago. A previous manager of the IT group recognised the need for some sort of consistent “documentation” within the group. By documentation, he was meaning procedures, templates, and forms, I think. He was concerned that people couldn’t find previously written documents. He was also concerned that some processes were only known to the people who performed them and that, if those people left, the group would lose valuable knowledge.
For the 12 years prior to joining this organisation, I worked in an information-development group. I mostly wrote user and technical guides, online stuff, and other documents relating to the product being developed. I was also involved in writing pre-sales material–not quite marketing but still used in the marketing of a product or service.
I was attracted to my current job because it was a new position (so I could have some say in what was done) and I would be the only writer (so I would have some autonomy, at least for some time).
First Problem: Overload
As I look back over the year, I sometimes feel that I have achieved little. It is frustrating to see so many things that still need to be done.
I have had great difficulty deciding what tasks are the most important and will provide themost results. How do I choose which tasks to do when there is so much to do?
There is far too much writing for one writer but there is no point employing other writers to help me until I have some standards or a strategy in place.
In my first few months, I spent all my time investigating. I spoke to managers and their staff, working out what documentation they had already and what was missing. I started writing a document that summarised my findings.
I also got access to all the directories and basically hunted for documents—a sort of content audit. I produced a spreadsheet of what I found.
The problem was that the further I dug and the more people I spoke to the more documents I found, which was frustrating because I never seemed to be able to get a handle on the task.
Even now, I’m not sure I found all of the current documents or that I determined all the documents that still needed to be written.
Somewhere near the middle of the year, I began to think this exercise was becoming futile.
A few changes in upper management didn’t help. The person with the vision left. The group went through a period of upheaval where they made few decisions. A new person came in and it took a while for him to understand what needed to be done.
All in all in a group this size, working out priorities has been difficult.
Toward the end of the year, I decided to focus on the “external” documents that reach our “customers” (the rest of the organisation) because I could see tangible benefits in that task and because of the second problem I faced (see Second Problem: Reputation).
I also decided to focus on document control. I began to think that creating useful documents was of no use if people couldn’t find them. And I wanted to create an atmosphere where people would see that centrally accessed documents were collectively owned.
I also thought that templates were important. If I couldn’t have input into all the documents written, then at least I could make sure that they followed some good design principles, which may make them more readable.
Getting people to come to me for help with their documents is difficult. Few people, if any, have worked with a technical writer. As I mentioned earlier, the manager of the group, who had pressed so hard for the job to be created (a difficult and long task in a public service organisation), left not long after I joined.
People I had to deal with were very helpful, but they just couldn’t understand how a “non-technical” person could write about the technical things they knew about.
So in the last year, people in the group have redesigned many forms and have written many documents without my input because they didn’t realise I could help.
When I realised people were not requesting my help, I tried to get some runs on the board. It was at that point I decided to focus on our external documents. I ended up preparing a lot of small documents (Web and paper) about new tools that were being rolled out to the organisation.
And, I wrote many articles for the in-house magazine about what the group was doing because the group wanted to raise its profile and the magazine was a useful way of getting some exposure.
In most cases, the people I worked with to produce these documents were happy with the process and the results. I think they were surprised that I really did write a technically accurate document that was aimed at a non-technical audience.
I believe these people will now want to “use” my services. I believe they will think of me when there is work to do.I have established my reputation with them.
But today, I have still worked with only a handful of people in my group.
It will be a long, hard track.
Third Problem: Other Management Changes
In addition to the change in the group’s manager, I also had three changes in my own line manager during the year. They basically didn’t know where to “put” me.
Within IT, I moved from the Standards group (who defined the software and hardware allowed by the organisation), to the Client Service Group (who provided the help desk and support), and now to the Knowledge Management group. This group encompasses strategy, records, intranet expertise, standards, and security, a bunch of specialists together.
The technical writer position doesn’t easily slot in the organisational structure of this support group. My current group is still not ideal, but probably the best fit so far.
With each change, I’ve had to re-educate my new manager as best I could. These managers haven’t worked with writers before.
Where To Now?
I think partly because of the documents I wrote last year (and the huge improvements I made in the quality of the group’s external documents), my group now has a full-time “Communications” person, transferred from elsewhere within the organisation.
No one has specifically told me that I won’t be writing external documents anymore, but I think that’s what will happen.
That’s okay with me. External documents were fun and quick, but I was always aware that there was another, larger job looming for me.
I need to “win over” my new line manager, so he can be my advocate.
I need to put some focus on getting some document control.
I need to publish some document templates.
And, I need to choose to work on projects that will, sad to say, provide the most visibility for me.
Living at Level 0
Sr. Systems Analyst
My story begins in 1998 with an idea—a radical idea. How can we bring people together to share their work and coordinate writing projects? At the time, I was an Information Technology (IT) lead for a team of approximately 15-20 people, depending on who counted. I was assigned to work with the vice president of the company’s Corporate Communications department. It was a great opportunity and being young and naïve, I thought I could make their work lives better through technology.
I listened, I studied, and I debated. The Communications department wanted a content vault. A single repository with a single gatekeeper who could dole out content and deposit it like money in the bank, this model screamed bottleneck, as well as other words I cannot say. I researched more and fought with IT management. The IT leaders wanted me to deliver only what the business wanted—no more and, if possible, less. I objected to the approach. I learned about content- and document-management systems. I educated the Communications department and others in various IT and business areas about the pros and cons of the proposed system. The strategy worked. The business leaders were beginning to recognize the benefits and started moving out of the oblivion. A few of the IT developers were still wary of the system’s complexity and of the power it put in the business’ hands. IT management, on the other hand, was determined to stop what they saw as a renegade project.
A new year approached and with it the budgeting process. A business leader who wanted to advance content management was promoted to lead an area of the Communications department. Knowing the struggle I was facing in IT, he presented an alternative strategy. I could move from the IT department to the business group and run the project from there with my own budget using my desired software-development process. The catch—I would not have a staff and would need to rely upon the coalition I could build between about 12 IT and half as many business areas. Finally to accomplish the project, it needed to operate as a Skunk Works project and stay under the radar, which would prove very difficult because of the interdependencies of IT. Nevertheless in 1999, I moved from IT to the business world as a stealth operative.
1999 was the year XML became viable. Products were available and its ability to carve content into reusable and re-purposable chunks went mainstream. Of course, XML was not new to the SGML community, but to me it was the eureka moment I had been looking for, a vendor-neutral standard allowing several authors to work on a single document without colliding with one another. Productivity could advance significantly with the ability to transform the content into PDF, HTML, and other formats by developing only new stylesheets. Finally with XML, I would be able to meet the objective of increasing communications productivity without a commensurate increase in headcount. Working with the department vice president and my new manager, we made a decision. The department would develop an XML content-management system the business could use as easily as it used MSWord.
Now for the hard part—there were few content-management converts in the department. To the majority of employees, a content-management system was neither needed nor welcome. First, they saw new activities that were to be imposed upon their already harried communications process. Second, they would have to learn a new IT system. Third, their job would be in jeopardy. Essentially, the biggest hurdle to overcome was the ignorance of content and document management. It was a year’s worth of work to educate the content creators and designers on how this system would make it easier to write content, to find content, and to ensure consistent messaging and branding; to the writers this idea was a nightmare of unnecessary complexity.
During the education process, the project sponsor left to join an Internet start-up. With my vice president support now gone, the project was in jeopardy. The company decided to carve up the communications department and reassign the graphics development group to branding, the communications group to marketing, and the public relations and the internal communications group to executive management. Now, each group that produced company communications and had previously worked together on projects was under different vice presidents. I saw that a content-management system was needed now more than ever, but I lacked a sponsor.
Fortunately, my manager took on the role of sponsor and I stayed in my communications group working to keep the acquisition of the system moving. To locate areas of resistance and concern for the project, I hired two knowledge-management consultants to do a cultural analysis of the ex-department. The work paid off. My manager was an active sponsor of the project and I was able to find where in my user group I needed to concentrate my efforts. In the summer of 2000, I worked with a consultant and several IT areas to build a prototype and evaluate the XML authoring and content-management products. The prototype was presented to the business users and IT in five sessions to more than 100 people. The response was encouraging. The business began to see the benefits and the potential of such a system. Furthermore, a content-management system was starting to make its way into conversation. At this point, symptoms of a power struggle began to appear.
The business recognized the power the system gave them to control workflows, content creation, and design. IT saw the system as a loss of control that didn’t fit into their sanctioned environment. In retrospect, I agree the system did not fit into the black and white architecture model, but then there was not a model for n-tier systems that crossed several platforms and business channel boundaries. My project budget paid to build the system in 2001, but who would pay for maintenance, customizations, and upgrades was not yet clear. In the spring of 2001, system acceptance testing finished and work began to bring the system in-house. Regardless of the business benefit, the system was a very tough sell to the IT department. The system would require fragments of time from 12 operational areas or 2 dedicated employees with access to those same areas. Neither model was acceptable to IT management.
The market turned south and the Finance department in conjunction with IT began repeated requests for detailed justification of the cost benefits. Justifying the cost benefits would not be so interesting except this project was singled out for an unprecedented detailed cost analysis. Because of my diligence in selecting products and planning for the system, I was able to show revised content cycle time-savings, as well as other soft dollar savings. For one content type, we were able to reduce the writing and production time from 30 days to approximately 5 days. For another content type, we were able to remove the number of people involved from 11 to 7. Altogether, it was predicted the system would save the equivalent time of 14 full-time employees in the first year. The savings surprised the Finance department, to say the least. IT said the numbers could not be accurate, and I was asked to recalculate them several times under restrictions and assumptions imposed by IT management. In the end, the Finance department told me the numbers could not possibly be realistic and the company could simply not be that inefficient. At this point, it became glaringly clear operational efficiency was a four-letter word.
The summer of 2001 rolled by and the project was put before a joint business and IT steering committee. The argument laid out by IT was the system was too expensive to maintain because it required massive amounts of coordination and the ROI numbers could not be thoroughly proven. The business argument highlighted the savings a content-management system could deliver but conceded that under the current IT support structure, maintenance would be complicated. So in the end, the decision was made to postpone implementing the system because it would require change to the business and IT areas. An opportunity was missed and the organization remained at Level 0, oblivious to the true benefit of content management.