Project Handbook Report and Tool Kit: Research and Scoping
Jinfo Blog

By Stephanie Taylor

Item

[The latest report from FUMSI, The Project Handbook, is a tip-packed resource that helps those looking to document projects. This first chapter shows how to begin structuring your project handbook, and you can learn more and read activities in the whole report, available on <http://web.fumsi.com/go/report/>.]

From workflow to users

The first step to any good end user documentation is to identify as early as possible who will be in this group and start talking! Talk to them about what they do, what you want them to do, and where the changes your project is initiating will fit in with their work. This helps people feel a part of the project and introduces the new ideas to them well in advance of the implementation. At the same time, you get an understanding of the way they are already working. You need to start looking at how your project will fit in on an operational level. And once you have started talking, keep talking! New ideas will constantly emerge, and you will continually gather new information about what your users want and need.

It isn't always possible to identify everyone who will be involved in a project at the beginning of the process, so view your identification of users as an ongoing process, carrying out regular checks and updates to find new user groups and repeat your initial introduction to the handbook and your work to each group.

Consider an example: a project designed to implement a new inter- library loans module of a library management system for a hospital library has some obvious groups of users within the organisation; the library staff who run that service, the technical staff who support the system and the patrons who will place orders for items are the most obvious. However, as the project progresses, new users are identified. The Web design team need to include an online request form that links to the system on the library website and staff working on the main issue desk often deal with inter-loan items in the evenings and at weekends. Two new patron user groups also emerge. The library is a member of a local consortium and patrons from any member libraries can place inter-library loans requests. The library also supports a number of mental health staff who are based away from the hospital, living and working in the community, and also regularly order inter-library loans.

Before you can create the documentation to help your users, however, you have to understand them better - what their needs are, how the project will fit into their daily work, and what questions they will have about the project. Drafting a workflow first will help you identify the right users more quickly. The workflow processes on which your project touches are, essentially, what the project is all about. Your users, then, are identified because they are the ones who participate in these processes.

User input

Once you have defined the workflow, use it to identify your users. Show the workflow to people within the organisation, and ask who will be affected by your project. Be as inclusive as possible in getting people involved. If people know what is happening, know where to get updates and (most importantly for your handbook) know where to get information that requires changes to their work, they are much more likely to view your project in a positive light.

Pull a group of user-stakeholders together, and explain your plans for the handbook. Make sure they understand that your aim in producing it is to help them and to make their work easier. Let them know that you will be keeping the information updated and that you will welcome feedback on the handbook and the project.

Most importantly, ask for their help. And then listen to what they say. If your project handbook is to be genuinely useful, then you need to begin with a flexible framework, not a rigid plan. Activity 1 (available in the full version of The Project Handbook) leads the way for identifying the needs, thoughts and feelings of your users and addressing these in the handbook. Use the session to get a clear idea of your users too. Keep them in mind when you start to actually write, as they are your audience. Do you need to reassure them? Inspire them? Encourage them? Hold their hands to give them confidence or rein them back a little because they're raring to go? Understanding the levels of confidence and competence your users will bring to their interaction with the project and knowing their preconceptions (both good and bad) are very important. The handbook can set the tone for the project delivery, and pitched in a way that addresses the hopes and fears of your users, it can stop some problems before they have a chance to take hold.

Remote access

Real-time and face-to-face meetings are not always possible for pulling together user groups. You may have difficulty with:

• Project partners based overseas
  
  
• Posts that are still at the recruitment stage
  
  
• Colleagues who are not easily available due to other commitments.
  
  

In such cases, explore alternative communications channels. For remote workers rework your face-to-face meeting agenda to start with a document-based or Web-based introduction followed by a conference call. For time-strapped colleagues, concentrate on presenting them with the key issues that are relevant to their specific involvement and create a short conference call or VOIP contact. A guarantee that the time commitment will be no longer than 20 minutes maximum will make scheduling easier. For vacant posts, flag up the required involvement with your project at an early stage and ensure it becomes part of the role so successful candidates are already aware of what you will be doing. Create a short project introduction and make it available to the colleagues who will be involved in the selection and management of the new posts, keep updated with progress on recruitment and prepare a package about your project that can be delivered as part of the induction process.

Scope for inclusion

Scoping the handbook is a key task. Scoping is about focusing on what is to be included, and equally about understanding what should be left out. It's about arriving at a compromise between including enough information to support your users but not adding so much that the user is swamped and confused by detail. Keeping the focus is the main job here. If you are unsure to begin with, draw up a rough plan that includes everything in detail. Then review it and refine it down by asking of every point 'Is this necessary? What happens if I take this out?' This process should give you a focus on what is useful and what level of detail is best for supporting your users.

Next, you need to get an overview of key areas that will be affected by the implementation of the project. You also want to identify how these changes will blend with the existing workflow. Having this overview will help you understand how broadly to scope the content of the project.

Different types of projects will have different scope. The section below shows two examples of project types and the kind of scoping notes that they raise.

Type of Project: Technical change

Example: Introducing a new system, eg library management system

Users: Administrators, staff users, onsite patrons, remote patrons, technical support

Scope Notes:

• What are the main operational tasks currently performed with the existing system?
  
  
• How will these tasks be affected by the new system?
  
  
• Which user groups are involved in which tasks?
  
  
• Are there any additional tasks that the new system will carry out?
  
  
• If there are new tasks, are there operational/admin procedures in place to deal with them?
  
  
• Consider also making more than one version of the handbook to meet the needs of different users.
  
  

Type of Project: Operational change

Example: Introducing new, global, administrative procedures to an existing content management system

Users: Staff users at all sites, patrons at all sites, offsite patrons, technical support

Scope Notes:

• How are existing workflows within the system going to be affected by the procedural changes?
  
  
• Are there any areas of the system that will be used in the new procedures and are unfamiliar to users?
  
  
• Are there are familiar areas of the system that will be used in new/unfamiliar ways?
  
  
• Make sure that staff understand the user perspective for patrons and ensure that any differences in the user workflow for onsite and offsite patrons are highlighted
  
  
• Technical support staff should be aware of the new procedures although there is no technical change.
  
  

Sample scoping - UK-based document delivery/ILL system

In the project handbook, it can be useful to include a description of what users used to do along with what they will be doing in the future. This helps put things into context. For example, any UK-based library document delivery/ILL system will handle requests to the British Library (BL), but will handle them in different ways. For a project that is introducing changes to the technology in this area, you should be looking at how the users interact with BL now and how the workflow introduced by your project will interact with BL in the future.

Type of Project: Technical change

Example: Introducing a new document delivery and inter-library loans system

Users: Administrators, library staff users, onsite patrons, remote patrons, technical support

Scope Notes:

• How do library staff users currently order from the British Library (BL)?
  
  
• How will these tasks be performed by the new system?
  
  
• Are there any new procedures in the workflow at the BL side?
  
  
• Are there any new procedures in the workflow at the library side?
  
  
• Are there any additional tasks that the new system will carry out?
  
  
• If there are new tasks, are there operational/admin procedures in place to deal with them?
  
  
• Ensure that library staff are aware of the user perspective for patrons
  
  
• Highlight any differences in the workflow for onsite and offsite patrons.
  
  

Identifying the key areas for the whole workflow of the project application will ensure that the handbook gives a detailed explanation to the users about what is going to happen, and what they need to do. Read more about workflow in The Project Handbook <http://web.freepint.com/go/shop/report/>.

Related FreePint links:

• "Project Handbook Report and Tool Kit" <http://web.freepint.com/go/shop/report/>
  
  
• "The Project Handbook: How to Write Clear and Cogent End-User Documentation" By Stephanie Taylor <http://www.freepint.com/issues/210906.htm#tips>
  
  
• "Life of the Party: Social Web Browsers" By Stephanie Taylor <http://www.freepint.com/issues/150207.htm#feature>
  
  
• "The Content Management Handbook" Written by Martin White Reviewed by Steve Lee <http://www.freepint.com/bookshelf/conmanhan.htm>
  
  

« Blog