TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: The non-learning organization? From:Stuart Burnfield <slb -at- westnet -dot- com -dot- au> To:techwr-l -at- lists -dot- techwr-l -dot- com, rjstevenson -at- sprynet -dot- com Date:Sat, 14 Jan 2006 00:17:15 +0800
**Easy--just start drawing DFDs and all your problems will be solved!
I worked for a company with some of the same problems, though not as
bad, from the sound of it. They had excellent technical staff, though
not enough of them to cover all the technical work that needed doing
(develop new features, fix bugs, handle support calls, support pre-sales
and customer trials, work trade shows and conferences, support
distributors, ...). The result was a lot of churn and delays.
They brought on someone to be a project manager. I don't know if that
was her official title but that's what she did--managed the people so
that the right things got done in the right order so that most projects
got done mostly on schedule.
You might think that you'd need an experienced software development
manager to make this work, but in fact she had no software development
experience and not much technical background.Yes, we were a software
company with technical products and technical challenges that needed
technical solutions, but there were technical people to deal with those.
This company's main problems weren't technical, and I expect that's true
of most software development companies.
The problem was coordination. Fran just made sure there was a plan for
each project, including what people and equipment were needed for each
phase. She made sure that at any given time it still looked feasible for
all the projects to be completed according to the plan. If it no longer
looked feasible for some reason--
- let's add this cool feature!
- let's write our own browser! in Java!
- Bill needs the stacker for a demo in Sydney next week but Ben needs it
in Perth for testing!
... then something would have to change--either what was promised, or
when it was promised, or how the plan said we'd get there. She did this
without cattle prods or 36-hour coding marathons.
This might sound like either basic project management or pie-in-the-sky,
depending on where you work, but in my experience this basic stuff is
often what's lacking in smaller software development orgs. Have plans
that make sense, then each week check that they still make sense in
light of what happened last week. In that company, we outsourced
(insourced?) most of our project management to one person.
I think what made it work was that she didn't have any other axes to
grind, wasn't interested in technical holy wars, wasn't pining to get
back to 'real work', didn't have her own projects to compete with other
projects. She just made sure that the company made promises it could
keep and kept the promises that it made.
Is there any chance this would work in your place, Rebecca? You'd need
the right person, management to be on side, and reasonable good will or
pragmatism from the existing project leaders.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l