Paperbuilding - hints & tips

Hints & Tips

• Before you begin
  • Make sure you know the details of the requirement – ie what it’s for, who will use it, where it will be sited, what it’s to be built in, what’s the server set up etc. Use the Project Brief Questionnaire
  • Make sure you know the limits of the project – there’s no point PaperBuilding things which will never see the light of day
• At the intro session
  • Introduce the PaperBuild to participants, what it is, what we do, what participants get out of it, the limits of it.
  • Introduce the scope of the project.
  • Tell participants what happens to the PaperBuild after it’s created, what it means - the PaperBuild is your contract with your users. If the project goes ahead (as planned) you will deliver the functionality expressed in the PaperBuild. There are no assumptions in a PaperBuild, it’s black and white and if it’s not in the PaperBuild, it’s not in the project – make sure the participants understand this.
• At the first session
  • Strike a fast pace, inject a sense of urgency and keep them on their toes – be the unequivocal leader, boss them, keep everyone busy, they should know they’re not on holiday.
  • The first step is to assign who will do what in the PaperBuild, it can take a lot of time if the PM is to draw up everything, so firstly appoint someone to draw forms, someone to do the tables and fields, someone to do the function list. NB – this request can be met with reluctance but try and make sure the client is active in the process, ultimately you’ll find they’ll be fighting for the pen and paper to draw the form how they want it.
  • Start with small exhibit or say an overview of the system – probably to be found in the PBQ filled in, or from the ITT (keep it brief, but it’s an anchor to check things have been covered).
    • What will the system do in broad terms?
    • What data will be put in? (get first pass ERM from this)
    • What data will be taken out? (get first pass report ideas)
  • Isolate the first area to concentrate on, e.g. contact management.
  • Talk through the business process, map it.
  • Note the data to be captured for eg for an individual.
  • Draw each field on the form.
  • Number the field, then make an entry with the same number in the field list – marking the table the field belongs to.
  • Any functions that are required, note on the form, then add a corresponding entry into the function list eg auto create salutation field from first name surname and title already entered.
  • This process continues for all areas / all exhibits.  After each session you’ll have identified more fields, tables, etc and will need to build up the ERM as you go and keep it up to date.
• At the end of the session
  • Tell them what happens next time but no review, just stop dead – leave them wanting more (it is a bit of a show, or at least you have to keep your audience interested).
  • After each session you’ll have identified more fields, tables, etc and will need to build as you go and keep it up to date.
  • You will need to do a fair amount of session tidying-up, prep for next time – as much time in front as back stage.
  • Always leave a photocopy of everything with the client project manager/if possible leave it hanging up in the ‘project room’.
• Next session
  • Start with review of the PaperBuild documents you’ve got to-date – make it fast, horse race commentary, get the momentum and sense of urgency built up and then hit the next exhibit at pace.
  • Once you’ve completed all the exhibits you need to start raking through the PaperBuild filling in detail, checking it cross references correctly.
  • Above all you need to make sure the whole thing is consistent, makes sense within itself. It’s not unusual for contradictory requirements to be recorded, it’s your job as the PaperBuild practitioner to make sure this is a coherent statement of requirement.
• PaperBuild structured walk-through
  • Arrange a short lull – just a few days.
  • Come back and (with the client project manager) present the whole PaperBuild to the staff not involved to-date, managers, funders and the PaperBuild team itself.
  • Stick copies up on the wall and make booklet copies.
  • Make the walkthrough quick but comprehensive. Synthesise the essence of the organisation and this requirement in a rapid fire presentation – sell the project to the broader board. Have bit parts for team members so they nail their flags to the mast in public. Stress the benefits it will bring.
  • Ask the audience to chip in with any queries as you go but tell them you won’t deal with them there and then you’ll come back in review.
  • In review, just weight them Must / Should / Could / Would be nice – don’t answer them just weight them.
  • Ask the audience if you could deal with the Musts, is this system really what they want, can this project proceed?
  • Go to it.
• Build it
  • Always prototype or pilot – never launch in hope
  • When it comes to the development you can accept new requirements if you wish, if you have the budget, but as a rule they should be costed separately and then PaperBuilt in a subsequent phase. NB  Failure to be strict here is where we allow scope creep and the whole project could unravel – you have to be strict!