When checking the User Functions Design (UFD) one is largely checking that it satisfies the relevant bit of the requirements, so have a copy of the requirements document to hand when preparing for and holding the UFD inspection. Similarly, when inspecting the IT technical design have the UFD to hand.
We will see that driving for zero defects does not imply infinite cost nor unconstrained cost, nor even great cost - nor actually any cost. The tasks that we put into the plan for inspection preparation, inspection meetings and re-work following inspections are like any other tasks in the plan: they have an allotted number of hours. And the original task to produce the bit of work will have had a number of hours within it for the author to check his own work. We are not pursuing quality regardless of cost - we are investing a predetermined amount of effort and money in what we believe to be the most cost effective way of removing errors. Further, this investment should be recouped via lower testing costs later in the project - and the real 'profit' comes because there will be fewer problems when the system goes live.
Can't we rely upon people to get things right without all this checking? If only we could. Defining a complicated business process fully and unambiguously is very difficult. Producing complete and correct systems designs is very difficult. Checking will be needed. And by the way this does not let the author off the hook - he still has an obligation and an incentive to get it as right as he can, as we shall see towards the end of this chapter. In the process-oriented world the aim is for people to get it right without checking. If we found they weren't getting it right we would change the process (or change the people). But if Finance was producing the Annual Report and Accounts or a Takeover document there is no way one person, however skilled, would produce that and it would be published without being checked. Inspections are not unique to IT projects. They are used when anything complicated, and usually one off, is being produced where correctness is important.
If we were inspecting the heart of a complex system design we might need many people there to verify its correctness from their perspective - inspections with a dozen people present are not unknown. But if by contrast an expert has done something very simple a dozen people checking it might be a bit over the top. There are three equally valid forms of inspections:
The real fine art of quality planning is this: at the beginning of the project stage thinking through every bit of stuff that will be produced and deciding whether it will need 12 people in an inspection meeting to check it or a quick over-the-shoulder-glance check, and then planning all those inspecting tasks into the project plan. This can be horrendously complicated to do. This is why it helps to have a quality expert in the team who can take the lead in this.
|
|
For example, let's say we are planning the project on the right. Who should attend the inspection of the section of the UFD indicated?
First, the author must be there. Also the 'user', though this is actually two people: the person who wrote the relevant bit of the requirements document (who may never actually use the system) plus someone from the genuine end user community who will eventually use this part of the system. And what should those two users say at the end of the inspection? It meets the requirements and we are happy to use it as it has been designed. When in the bad old days did the users give their verdict on those two things? Perhaps in user acceptance testing or even when the system had gone live. A bit late in the day.
Think back to that house you are having built for you. The architect rings to say he's designed the kitchen so you go into his office, check the design and sign it off - or point out how you'd like it changed. One week later he rings to say he's designed the bathroom. You go in and check it out. If it was your money and your house would you do those design inspections thoroughly and carefully? You bet. Unfortunately in IT projects the users don't have quite the same incentive to do the inspections. Whose job is it to make them do the inspections properly? You guessed it, the project manager.
Again we stress that these inspections are tasks planned into the users' project plans. At the start of the stage their time was committed to the project manager by their line managers and the individuals have agreed to perform these tasks.
Who else should be at the inspection of that section of the UFD and why will this next person probably be the best inspector of all? The person who must do the relevant bit of the IT technical design. He will be a very assiduous inspector because his ability to do the IT technical design depends upon the UFD section being complete correct and intelligible.
And who else, later in the project, will be working from this section of the UFD? The test team, so we may want someone there from the test team to verify they will be able to base their testing upon it. Incidentally, involving the test team in this way can also result in the design being changed so that the system will be easier to test, which can save time and money later in the project.
|
We may also invite other members of the UFD design team to the inspection to check that this bit of the design fits with their bit. You can see that quite big teams can form to check key sections of the UFD.
Generalising, an inspection team comprises:
Moderators do need to be trained (takes half a day) to ensure inspections don't descend into personal abuse, arguments over grammar or discussion about document prettiness. We are after a short sharp meeting that identifies things that, if left uncorrected, would have been bugs in the final system. The moderator will need to be a strong chairman to curtail debate about how errors should be corrected.
One person who should not attend inspections is the project manager. If the team like the person whose work is being inspected no errors will be found in the meeting (and after the meeting the author will be slipped the list of errors under the table). If the author isn't so popular all the errors will be painfully dragged out in front of the boss. Make this a pure peer review process without the beady eye of the boss skewing it.
A word of caution about multi checks. They can seem like a cheaper version of inspections but can end up costing more. Suppose you have written a section of a UFD. You send it to the relevant users to check it. They send errors and comments back to you. You correct the UFD and sent it back to them. Someone who was happy with the first version now thinks there is something wrong in the revised version. You do your best to change it to their satisfaction and re-issue it, but now someone who made no comments at all on the first version makes loads of comments on version three - maybe because they didn't read versions one and two. And so it goes on, ping-ponging back and forth. Particularly where many people are reviewing a piece of work it can be cheaper and quicker to hold an inspection meeting.
Plan inspection preparation tasks, inspections meeting tasks and re-work tasks like any other project tasks and then resist the temptation to skip them when the project gets behind schedule.
Inspections can be mind-numbingly boring so try and give inspectors some incentive to put their backs into it. One simple idea is to put a chart up on the wall which plots how many errors each team member has found (note: found not made) and reward this month's top inspector with a £50 award. This is an unequal competition as some people will attend more inspections than others but at least it provides some recognition for those who are finding errors and saving you and the team stress later in the project.
Inspections are good value for money - but you will need to measure this for yourself before you'll really be persuaded.
However, they do have one major weakness. If a team sits down to inspect a section of a document they tend to check
what is there - they don't always spot what is missing.
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book