In policies and procedures writing, we talk about the development process instead of the planning process. It’s important to develop the project instead of diving into writing, because if we immediately start writing, we may be missing something crucial to the project.
The four steps of development are
- Planning
- Analysis
- Research
- Prewriting
Each step should be covered, if even briefly, and all should be done in order. Outlining is not recommended because it wastes time and could cause errors.
Step 1: Planning
- A plan, in most cases, should be written
- This step is not always formal
Since every project has a deadline, a plan should be kept somewhat simple. For this, it is a good idea to plan the basics:
- Tasks
- Sequence
- Deadlines
Set a schedule
- List the steps
- Indicate team member responsibilities
- Make timetable estimates
A team’s size is important because too much work for few writers will make it difficult for the team to meet the deadline. Our text states the following when working with a team of writers:
- Select members with appropriate backgrounds or expertise
- Meet or talk regularly
- Establish ground rules
- Agree on assignments and responsibilities
- Establish a monitoring system
- Agree on deadlines
- Develop a team style guide
Be realistic: Make sure the plan is doable, and always check for conflicts and other possible concerns (such as other projects that have their own deadlines). A written plan should help address these possible road blocks.
Step 2: Analysis
In this step, the team should look at the project’s
- audience
- assignment
- context
- relevant research
- conditions for the work
Some concerns can be answered in analysis through the following:
- Look at who requested the project, and why the requested it. What led to the project’s conception? To what degree is the nature of the project? Is it technical or non-technical? Simple or complex?
- Know your goals. What do you want to result from the project? If you’re ever unsure, ask for more information (from knowledgeable sources such as the requestor).
- Know your audience so you can mold the document for them. What are their experience levels, interests, preferences, attitudes, and so on? How will they use the document?
- Know the project’s subject matter and its urgency. How big of an impact will it have on the organization? What are the conditions you will be working under?
- Go over important concerns with the requestor of the project. In this manner, update them regularly.
Step 3: Research
- First action here should be on matters of content.
- The amount of research here should be determined on what was found relevant in step 2.
- Ultimately, you will determine the amount of research.
Start with the most difficult research first as it will probably take the most time. This will give you time to ask questions and get clarification.
If it is possible, get information from experts who know the information you’re searching for. Also, talk with anyone who could provide input (such as the users of your document).
Relevant material should be read (books, articles, organizational files, etc.). And, of course, concentrate on critical information over anything else.
Step 4: Prewriting
Prewriting involves organizing the material, and this helps to speed drafting. This step is done before writing, and it is recommended to hold off writing at this point. An important question here is, “How do I convey this information to the reader in the clearest, most logical way possible?”
Content is key, so make sure all necessary information is gathered. The book suggests to practice mind-mapping (see example 2-8, p. 55) to gather and organize data. Mind-mapping reverses the process of outlining and allows you to focus on content issues first:
- It removes our creative side and brings all content to the forefront of organization.
- It helps you record your thoughts and knowledge at random.
- It is less likely that important information will be omitted.
- It may be easy to do, but it gets results.
Finally, in prewriting, you should develop a flow or sequence of the material that would be most logical to the reader. Will the reader use the information in a way that works for them and the organization?
Thank you, everyone, for participating in discussion on this chapter!
Team 3 (Lori Hood and J.J. Carlson)
12 comments:
Hello, everyone. I just wanted to say that I was having a lot of frustration with this blog. Has anyone else experienced formatting issues? I could not seem to copy/paste or even type from scratch and get the same outcome from what I viewed in the editing window. I then tried html, and it was still not working properly after I saved.
Anyway, I did want to address a couple of things about this chapter that hopefully will bring about some discussion.
First, the author had mentioned that outlining wastes time and could cause errors. Now I know there are differences between this and planning, but what do you all think would be the main problem with creating an outline? Do you suppose that outlining would create bias?
Next, I felt that this chapter seemed to approach everything with a bit of skepticism. For example, it was basically assuming that errors would come about during the process. Do you think that this is a good thing to share with readers? Could this actually hinder readers when they conduct the four steps?
Thank you for your feedback!
I copied and pasted our summary from Google Docs, and it formatted correctly. Maybe using bullets causes the formatting issues?
Mind-mapping is the main point that stuck out to me in this chapter. Mind-mapping is something I never would've thought of using, but I can definitely see the benefits of using one. I think it is a great way to generate ideas.
As for outlining, I thought the author was suggesting not to outline too early in the process. Go through the steps, mind-map first, then consider using an outline to draw all the information together. I think that the point the author was trying to make is that if you outline too early, you may miss some important information in your final document.
Thank you for the summary!
As I read this chapter, I thought: "Ha, this sounds just like traditional project management theory." Well, it is. I think it helps writers to see their work as individual projects and to try to treat the tangible parts as such. Since policies and procedures are 99% technical in nature and their contents is pre-defined (most likely by authorieits that have decision-making power), it makes sense to strutre and plan the entire project to a) being able to see its end, b) communicate to management the scope of the project and c) work efficiently.
I think that people with "A" personality are more likely to end up in a profession such as technical writing or project management; to those individuals, a break-down of the project and a strategic approach may even come naturally.
But there is also always reality. In a culture that thinks that planning is a waste of time and effort, it may be difficult to justify taking extra time to lay out the project prior to starting it. Your boss may say: "Just start it, and get it done." It requires discipline to take a step back and lay out a game plan prior to beginning the project.
Finally, I would have to say that there is no cookie-cutter solution to everything. Some tools (like mind-mapping) may work great for creative writing, while otheres (like project management) would not work at all for a undefined project that requires creativity, but it will make a tangible project more manageable.
I believe that the most important thing I took from this chapter was the advice to form relationships with the content experts. The author tell us to spend some time developing reasonable working relationships with the content experts. People still do respond best to people. That is not to say other means of communication are ineffective (more on that later).
I also appreciated the advice regarding interviews. Campbell states that writers, "should inform the interviewee fully about your reasons for requesting the interview." I have found that time and time again to be valuable advice. I disagreed somewhat with the observation that written requests are ineffective. Many times, if you send your agenda to the interviewee, you'll end up with precise, accurate information even before the face to face. This gives you time to clarify anything during the actual interview.
J.J. mentioned the author's skepticism in his comments. I think the author was trying to convey the need for writers to anticipate the variety of situations that may present themselves. It seems like the advice was along the lines of--be prepared so you aren't faced with a situation that you hadn't envisioned.
I was also a little confused by Campbell's advice to be "realistic." She says it's impossible to find all the information that's out there on a given subject while at the same time giving us a rather extensive and elaborate four step process of development. It just seemed a little contradictory to me. Anyone else feel that way?
I found it really important that Campbell notes to first develop the project instead of going right to the writing. I think this is something young writers learn over time (such as some first-year undergraduate college students).
I also appreciated Campbell’s golden rule that she had in this chapter:
“Never write a policy or procedure just to have one or because it sounds like a good idea. A policy or procedure should always have a defined result. It should accomplish something” (pg. 32).
I think Campbell’s golden rule is relevant to us as technical communicators, but also to all businesses, agencies, corporations, etc.
Again, I know I made this comment last week, but I do enjoy the tools and resources located at the end of the chapter. I find helpful and as something concrete to use.
In answer to J.J.'s comments, I think Campbell's main objection to doing an outline early in the process is that you will have to do it over once you've completed your research. If you're writing a policy or procedure on an unfamiliar topic, I'm sure that's true. Then you can use the sticky note technique to organize your information.
But if you're the subject expert, then to me it makes sense to create an outline as soon as the plan is complete. If additional research is needed to make sure the information is up to date -- well, that isn't likely to affect the overall structure of the document.
Regarding errors, I think they are inevitable if you haven't been thorough in your preparation. Campbell wants the reader to be aware of the problems that can occur if writers aren't methodical.
The author has a very straight-forward, practical, and no-nonsense style of writing. It differs from regular textbooks that tend to present information in a more theoretical and scholarly manner. This book isn't really trying to be anything rather than a how-to book for writing policies and procedures. In a way, it's written as a procedure for writing procedures. I think this is part of the reason that her approach is described by J.J. as having skepticism. It tends to be more practical and honest than we are used to reading.
I agree with Jennifer that the tools that are provided at the end of each chapter are pretty helpful
I agree with Mary, in that I appreciated the information about mind-mapping. I think this will be very useful to me, as outlines have always felt so rigid to me, and I like that mapping leaves more room to go back and add things that were forgotten or just not thought about.
I think it was safe on the part of the author to assume that there would be errors. Nothing is ever perfect, unfortunately, and it is best to be prepared for any unforeseen circumstances or errors because this allows a writer to provide for some extra time to deal with these as they crop up. At the same time, I don’t think the author is excusing or validating errors, just pointing out that they can sometimes be difficult to foresee and avoid.
I thought that this was a good summary of this chapter, and so far am finding this book very useful and practical, both the chapters themselves, and the material at the end of each chapter.
Greaaaaat chapter for all the process freaks out there. Most large projects can't be managed properly without a fair amount of process tools and structure. I've worked at a lot of companies where Six Sigma processes and disciplines pretty much drive the business. This chapter just brushes upon the importance of inculcating planning and process discipline into major projects. The author mentions mind-mapping as a "critical" tool for getting at the content issues of a project. I concur-- it helps you discover new relationships and dependencies of topics. Great tool for brainstorming in groups!
I don't agree with the author on outlining. My team and I outlined our proposal and it helped us to see what needed to be covered. The only problem that I could even possibly think of is overdoing the outline and putting too much information into it. We went into great detail, but it also will cover all our points.
I liked this chapter because it seemed to flow like we planned our proposal, even though I read it after we did our proposal. It felt good that at least we had the right knowledge or perception on what to do from previous experience. Lance, maybe the author is a skeptic by nature. I feel that he covered all the bases in the lists and suggestions from previous experience and from common knowledge. Errors are about to happen, but he should be writing about foolproof errors don't you think? I still like the four steps and would follow them.
Books like this are great aides when you have to sit down and produce something from scratch. Like Keeley said, it's a How To manual, not a theoretical exploration of policies and procedures. As with all How To's, this book is prescriptive in its treatment of the policies and procedures creation process. It has to be--otherwise it wouldn't be a How To manual. Unfortunately, as we can see from the comments that this chapter has generated, not everyone will agree with the prescription. There is more than one way to do anything, and this book necessarily presents one viewpoint on the process.
The beauty of the single viewpoint is that we, as readers and future policies and procedures writers, have an opportunity to leave some of our accumulated work preferences at the door and try something new. I'm both eager and reluctant to try the mind-map technique. Eager because it's not something I would ever do on my own, and maybe I'll learn a new way of working productively. Reluctant because it's not something I would ever do on my own, and it's hard to "think different".
I agree that this chapter is very straight forward, but also easy to follow. I believe that all four steps of development in procedure/policy writing are important. For me the Analsysis step seems the most important, because it is hard to write a good policy/procedure if you are not aware of reasons behind it, goals the policy wants to achieve, audience it is intended for and so on. I think no matter how skillful you are if you do not examine the aspects of this step, you would not create good procedure/policy.
And also, I agree with creating outlines. They are really helpful in the writing process.
Post a Comment