|
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
Lynette Twigg
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.
My Background
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).
Problems
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 the most 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
Christine Adcock
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.
|
