| ACTION PLAN
for
Continuous Improvement Task Force
Issued by:
Barry Salussolia March 31, 1993
Task Force Members:
Diane Florio
Bruce Gillham
Jim McAleese
Barry Salussolia (Chairperson)
1
INTRODUCTION
The following plan recommends that TNPUBS adopts a standardized postmortem
process that all groups within the department follow.
2
SPECIFIC GOALS
The goal of the Continuous Improvement committee is to analyze departmental
procedures. One way of going about this is to design a consistent, department-wide
postmortem process that will enable the Continuous Improvement committee to
extract quantitative data from TNPUBS postmortems. The proposed postmortem
process is a means of achieving the committee's goal of data gathering and
analysis. Our goals include:
o
Provide a consistent, department-wide postmortem process.
o
Help TNPUBS achieve its ISO 9000 goals. ISO 9000 looks for processes to which
everyone in a work group complies.
o
Design a postmortem process that facilitates a free discussion of a project.
3
NON-GOALS
The non#goals for the Continuous Improvement committee include:
o
Continuous involvement with departmental postmortems.
4
DELIVERABLES/IMPLEMENTATION
Deliverables include:
o
A detailed proposal outlining the postmortem process and information about
what to do with the data gathered at the postmortem meeting.
o
A training session for the department is probably unnecessary.
Implementation is:
o
The use of the proposed postmortem process.
5
SCHEDULE
Milestone Start Date End Date
Submit Action Plan to Core Team April 1, 1993 April 1, 1993
Proposal Available May 1993 May 1993
Present Taskforce Results December 1993 December 1993
|
|
The Continuous Improvement group met on August 30, 1993. The following
people attended:
Diane Florio,
Bruce Gillham,
Barry Salussolia
We discussed the upcoming CI presentation to Kathleen's staff and
ideas about providing post-project review training to the department.
o We decided that we needed to say more than we originally
planned about the post-project review process in the presentation
to Kathleen's staff. We want to clarify this year's deliverable
and attempt to get buy-in from the staff for moving our
post-project review process through the IPA into day-to-day use
by members of the department.
o For departmental training, we agreed upon the following goals:
o Provide 10 or 15 minutes of training at a group meeting.
o Provide a Bookreader (WorldView) file that contains detailed
information about the post-project review process,
including minutes from one of the pilot reviews.
o Provide a note in DELNI::NACDOC that contains a .TXT file
with information about the post-project review process.
Another subsidiary note will contain the proposed list of
topics, so writers can extract the list rather than typing
it in. The notes file will also be a repository of minutes
from post-project review that use the new "voting" method of
conducting a post-project review.
|
| The Continuous Improvement group met on October 18, 1993. The
following people attended:
Diane Florio,
Jim MaCleese,
Bruce Gillham,
Barry Salussolia
In light of T&N Publication's merger with IDC, we discussed bringing
our post-project review work to a close. We will provide the following:
o Bookreader and hardcopy files that contain detailed
information about the post-project review process.
o A note in DELNI::NACDOC that contains a .TXT file explaining the
post-project review process. The note will also provide a
pointer to the postscript and Bookreader document. We will
request that all groups doing post-project reviews post
their minutes as replies to the note.
Team members will review the post-project review document a final time
before we make it available.
The team hopes to complete its work by the end of November.
|
|
This reply is an ASCII version of the Post Project Review Process.
Postscript and Bookreader versions of this file are located in
TNPUBS::PUBLIC$DISK:[PUBLIC.IPA.IPA3]POST_MORTEM_PROCESS.**
____________________________________________________
Post-Project Review Process Proposal
November 11, 1993
_________________________________________________________________
Contents
Preface................................................... iii
1 Post-Project Reviews
1.1 Who Holds a Post-Project Review?................. 1-1
1.2 Who Attends the Post-Project Review?............. 1-1
1.3 Preparation for the Post-Project Review.......... 1-1
1.4 Voting on Topics................................. 1-3
1.5 Post-Project Review by Mail...................... 1-3
1.6 Post-Project Review Report....................... 1-3
1.7 Follow-Up........................................ 1-4
1.8 Benefits of this Post-Project Review Process..... 1-4
A DECnet/OSI for DEC OSF/1 Documentation Post Project
Review
A.1 Post Project Review Process...................... A-1
A.2 Topics and Discussion............................ A-2
A.3 Accomplishments.................................. A-4
A.4 Followup......................................... A-4
A.5 Process Comments................................. A-5
iii
_________________________________________________________________
Preface
This document describes a new post-project review process.
The following people designed the new process and tested it
in several pilot reviews.
o Diane Florio
o Bruce Gillham
o Jim McAleese
o Barry Salussolia
iii
1
1
_________________________________________________________________
Post-Project Reviews
The following document presents the recommendations of the
Continuous Improvement committee's examination of the post-
project review process. A post-project review is a review
of a completed documentation project.
Post-project reviews are also known as postmortem reviews
or postpartum reviews.
1.1 Who Holds a Post-Project Review?
Every project that produces documentation will hold a post-
project review.
1.2 Who Attends the Post-Project Review?
All members of the documentation team will attend the post-
project review, including the following:
o Writers
o Project leader
o Supervisor
o Editor
o Illustrator
o Production editor
1.3 Preparation for the Post-Project Review
When setting up your post-project review meeting, send out
the following list of topics to your project team.
o Schedules
o Roles and responsibilities
o Testing
Post-Project Reviews 1-1
Post-Project Reviews
1.3 Preparation for the Post-Project Review
o Customer interaction
o Technical reviews
o Editing
o Tools
o Art
o Production (EDMS)
o Packaging
o Product requirements
o Decision making
o Staffing
o Teamwork
o Specs, engineering documents, development plan
o Doc plans
o Benefits (cost reductions, reduced page counts,
innovation)
o Usability
o Leadership
o Dependencies
Ask the team if there are any other topics not listed that
they would like to see addressed at the meeting. If you
receive any additional topics save them. Tell participants
of the post-project review that they will find the list of
topics taped to the walls or whiteboard when they arrive at
the site of the post-project review.
Bring either Post-its or colored labels to the project
review meeting. (The department will supply these.)
Arrive early at the conference room where you will hold
the post-project review. Write all topics on sheets of
paper and tape them to the walls or whiteboard of the
conference room. Be sure to include any topics suggested
by your project team.
1-2 Post-Project Reviews
Post-Project Reviews
1.4 Voting on Topics
1.4 Voting on Topics
When all participants of the post-project review are in
the conference room, give each person 5 Post-its or colored
labels. Give everyone in the room a few minutes to look
over the topics on the wall. Ask the participants to place
their labels on the topics they considered had the highest
impact on the project. Tell them that they may vote more
than once for a topic if they feel it outweighed other
topics.
Rank all of the topics from the most votes to the least.
Record the rankings.
Now begin your post-project review discussions based upon
the rankings. That is, begin talking about the topic with
the most votes and proceed down the list as far as you can
in the remaining time for the meeting.
1.5 Post-Project Review by Mail
If any group in the department cannot hold a post-project
review because of the way their business is charged, we
recommend that you collect post-project review comments
through mail.
Send out the list of topics. Ask members of your team to
rank the five most important topics. Tell the team that
they can add topics if they think the suggested list misses
something. Emphasize that they must rank the topics from
the most to the least important. Then have the team write
up their reasons for ranking the topics as they did.
Collect this information and write up a post-project review
report.
1.6 Post-Project Review Report
Write the minutes of the post-project review. Structure
the report around the ranking of the topics, discussing the
most voted on topic first, and so on. (Appendix A contains
a sample report.) Include the number of votes cast for
each topic. Include a separate section in your report
for recommendations for future action and how you plan
to follow-up what you learned at the post-project review.
Circulate the minutes to the immediate product group.
Post-Project Reviews 1-3
Post-Project Reviews
1.6 Post-Project Review Report
Post the results of the voting on post-project review
topics (that is, the complete list of ranked topics) and
the minutes from your post-project review in note 176 in
the DELNI::NACDOC notes file.
1.7 Follow-Up
Follow-up on recommendations to improve your product
documentation or processes.
Disseminate recommendations or innovations learned from
the project to the department by means of the NACDOC notes
file.
1.8 Benefits of this Post-Project Review Process
The post-project review process described in this document
offers a couple of areas for future investigation and work:
o The data gathered from multiple post-project reviews can
be analyzed with continuous improvement techniques as
means of studying departmental documentation processes.
o The post-project review process, if implemented
across the department, can become part of the ISO 9000
processes.
1-4 Post-Project Reviews
A
_________________________________________________________________
DECnet/OSI for DEC OSF/1 Documentation Post Project Review
The DECnet/OSI for DEC OSF/1 documentation post project
review was held March 15, 1993. The following writers
attended this meeting:
o Diane Florio
o Jo Fogarty
o Betty Lew
o Jim McAleese
o Cyndi Miller
o Steve Nazzaro
o Carol Noones
o Mark O'Brien
o Barry Salussolia
A.1 Post Project Review Process
Before scheduling the post project review, we planned our
approach following the guidelines for post project reviews
presented by the IPA Continuous Improvement committee. As
one of several pilot projects for this committee, we not
only discussed topics relevant to the project, but also
evaluated the process itself. Briefly, the CI committee
recommended using a list of topics. All participants
were given 5 colored labels. We wrote each topic on a
separate piece of paper and asked each person to place
their labels on the topics the felt had the highest impact
on the project. Each person could vote more than once for
a particular topic if he or she felt it outweighed other
topics. The topics were ranked and discussions were based
on the rankings.
DECnet/OSI for DEC OSF/1 Documentation Post Project Review A-1
DECnet/OSI for DEC OSF/1 Documentation Post Project Review
A.2 Topics and Discussion
A.2 Topics and Discussion
The following topics were discussed in the order of most
votes received:
1. Staffing- Due to the numerous last minute staffing
changes, not much was accomplished in the important
areas of product usability and improved user interfaces.
Even though these changes were primarily the result of
engineering cuts (3 people), this reduced motivation and
our time to market response.
2. Communications Between Groups- Communication was
generally effective considering the number of groups
we are dealing with at any given time. We need better
notification of changing project dates and review
schedules, particularly release notes. Teleconferences
and a designated contact for writers from REO and
Australia helped reduce some of the problems in this
area.
3. Schedules- With deliverables every few weeks, this is
an administrative area that needs tighter control.
Information needs to be sent out regularly and a
checklist for deliverables would be very helpful.
Notification of schedule changes improved as the
project continued. Much of the confusion had to do with
multiplatform books and writers owning books on both DEC
OSF/1 and OpenVMS.
4. Technical Reviews- We need more feedback earlier in
the cycle. Often the reviews were good, but too late
to be incorporated for the deadlines. The reviewers
kept changing and it was difficult to track who was
responsible for what. Some books had uneven reviews,
depending on the reviewer for various areas. Since
we dealt with REO, Australia and DNS writers, as well
as our engineering groups, it was difficult to track
accuracy of the information. Large review meetings were
suggested as a possible solution. Multiplatform books
require longer review cycles. We must consider review
cycles for other groups as well as our own engineers. It
was suggested that we could coordinate our book reviews
so that they were received at the same time. This would
make reviewing similar information in different books
easier.
A-2 DECnet/OSI for DEC OSF/1 Documentation Post Project Review
DECnet/OSI for DEC OSF/1 Documentation Post Project Review
A.2 Topics and Discussion
5. EDMS- The issue around rags art not compliant with EDMS
caused a lot of last minute confusion. Although the
workaround of submitting hardcopy books worked, there is
no guarantee this will not occur in the future. Also, we
received last minute notice that Demand Print uses EDMS
and just sending postscript files was not sufficient.
6. Art- Most art issues were controlled by our editor.
Charge numbers for multiplatform books was a problem. We
need to label art changes by platform. New art is more
expensive than revised art and we need to watch our cost
carefully.
7. Customer Interaction- For this project, it has been
almost nonexistent. We need to get more feedback
on our books. We must put together questions and if
contacting customers directly is a problem, we need to
ask engineering and/or product management to help. It
was suggested that we look into a public area to keep
any customer feedback.
8. Tools- Our tools are generally slow. It takes many hours
to process an average book through VAX DOCUMENT. Writers
new to the project need more ramp-up time, better
training and more support. Courses are continually being
cut back (nothing beyond April) so we need more internal
support.
9. Editing- We need a public directory that contains title
pages and preface templates. This will avoid confusion
on what to use for each platform for field test and for
final submission.
10.Doc Strategy- This work was done up front and has paid
off well. Multiplatform books have been well received
by both engineering and customers. We need to continue
looking for opportunities to cut the size of our books
and doc sets.
11.Leadership- Good leadership from engineering and
documentation made our jobs easier.
12.Decision Making- Reducing the number of writers made
decision making less complicated. Also, using small
groups of two or three writers to look into an issue
(such as icons or packaging) helped the process. Lengthy
DECnet/OSI for DEC OSF/1 Documentation Post Project Review A-3
DECnet/OSI for DEC OSF/1 Documentation Post Project Review
A.2 Topics and Discussion
large group discussions were eliminated and freed up a
lot of valuable writing time.
13.Teamwork- Teamwork was not always smooth, especially for
new members of the team. However, the group generally
works well together and is supportive of each other. The
DPE group considers us a great professional team to work
with.
14.Doc Plans- We are looking forward to the IPA task force
revision that is being updated to reflect ISO 9000
relevance.
15.Specs- Engineering documents were essentially
nonexistent.
16.Roles and Responsibilities- With fewer writers, this
became a non-issue.
A.3 Accomplishments
Despite a number of issues, we achieved many of our goals,
including:
o Implementation of our Multiplatform documentation
strategy with excellent results.
o Meeting all of our schedule commitments.
o Using icons to differentiate platform-specific
information.
o Creating a CMS library to keep strategy plans,
conventions and templates.
o Achieving significant page reduction and therefore cost
reduction.
A.4 Followup
We agreed that the following would be helpful to every team
member:
o A checklist of what is needed when, including all
schedule changes.
o A list of questions to add to any engineering customer
contacts.
A-4 DECnet/OSI for DEC OSF/1 Documentation Post Project Review
DECnet/OSI for DEC OSF/1 Documentation Post Project Review
A.4 Followup
o More customer calls.
o Putting CMS library information into our editing public
directory to make it more readily accessible.
o Assigning a "contact" writer to writers new to the
group.
A.5 Process Comments
Everyone agreed that this was an effective method for
holding a post project review. It gave each team member
an opportunity to express his or her views. The focused
topic areas led to open and lively discussion. We highly
recommend this approach to other writing teams.
DECnet/OSI for DEC OSF/1 Documentation Post Project Review A-5
|