00:00:00 - Nearing the end of our 2.0 Project Planning Road Map, we're down
00:00:04 - to 2.10 Quality Management Plan, or the full definition from
00:00:08 - the Project Plus Certification, 2.10 Identify components of a
00:00:13 - quality management plan.
00:00:16 - There are three main sites in the development of a quality management
00:00:19 - plan. Number one, define the quality requirements. Number two,
00:00:24 - identify the quality measures, the steps that we are going to
00:00:27 - implement in the project to ensure the quality requirements are
00:00:30 - satisfied. And number three, create the quality management plan,
00:00:34 - present it, and I think it's no surprise of what I'm going to
00:00:39 - say next, you can expect it from me, is get approval
00:00:45 - that what you have documented in the quality management plan
00:00:48 - will satisfy the stakeholder's expectations, the sponsor's expectations
00:00:52 - for quality. So let's spend just a moment, define quality requirements.
00:00:56 - What are the stakeholders' expectations for quality? Is this
00:01:00 - is a life-threatening, mission-critical application that absolutely
00:01:05 - must be 100%
00:01:08 - error-free? Or is this an average application where we would
00:01:13 - expect that there will be some errors, and yes, you heard it,
00:01:17 - we would expect there will be some errors.
00:01:20 - The degree of testing required in software projects is such that
00:01:25 - it is very difficult the amount of time we have to build into
00:01:28 - quality to ensure 100%
00:01:32 - defect-free is probably unrealistic, so we need to understand
00:01:36 - what the true expectations of quality are. What is the appetite
00:01:41 - for potential issues? If we apply the proverbial 80-20 rule,
00:01:46 - we are going to focus 80% of our testing on the 20% of the code
00:01:50 - that is core that runs day in, day out. We are going to ensure
00:01:55 - that that 20% of the core is absolutely bug-free, recognizing
00:02:00 - that we have only allocated 20% of our time for the other 80%
00:02:05 - of the functionality, so the one-offs,
00:02:09 - the things that happen periodically, or the error conditions
00:02:13 - that happen if and, if and, if and, if and, if may not we tested
00:02:18 - as rigorously as the core 80%. So we need to understand what
00:02:23 - the quality expectations are from our stakeholders, and then
00:02:27 - we need to identify what the appropriate quality measures are.
00:02:30 - What degree of inspections? What degree of testing? What degree
00:02:34 - of walkthroughs? What independent third party reviews do we need
00:02:39 - to bring in place to ensure that the quality measures are being
00:02:41 - applied to again achieve the quality requirements as defined?
00:02:46 - And then finally, as I said, we create the quality management
00:02:49 - plan, documenting the requirements and the measures. We present
00:02:52 - it and we get approval.
00:02:55 - But before we get into the details of the actual quality requirements
00:02:58 - and the quality measures, I want to get on my soapbox and I want
00:03:01 - to harp a little bit about the importance of building quality
00:03:05 - into the project.
00:03:08 - As we go through the requirements and as we go through the measures,
00:03:11 - we are going to identify the quality activities, the inspections,
00:03:15 - the walkthroughs, the testing processes, et cetera, et cetera
00:03:18 - that we are going to deploy on our project to satisfy the quality
00:03:23 - requirements. It's key.
00:03:25 - Once we identified those quality measures, we have to put those
00:03:29 - quality tasks into the WBS. We don't develop a WBS, as we've
00:03:36 - talked about already in this nugget series, that is focused on
00:03:39 - producing the deliverables and only the deliverables and stop
00:03:42 - at that. If we have identified that we need to do peer reviews,
00:03:46 - if we identified that we need to do an independent quality assessment
00:03:51 - of every deliverable on our project, we need to also add
00:03:57 - extra tasks
00:04:00 - that say, "Conduct
00:04:03 - peer review,"
00:04:06 - and build it into the WBS. We don't just make a quality statement
00:04:11 - upfront that says, "This is going to be a quality project and
00:04:14 - we are going to conduct peer reviews and we are going to conduct
00:04:17 - inspections and we are going to follow the XXX method of testing."
00:04:22 - Build it in. Add those tasks to the WBS and allocate the appropriate
00:04:28 - time to those tasks to ensure that we do an appropriate job.
00:04:33 - Again, it's not enough to say, "Okay. I'm going to allocate an
00:04:36 - hour for a peer review of a significant deliverable." If that
00:04:41 - deliverable is 200 pages long, it's not going to take an hour
00:04:45 - to do a peer review of a 200-page document. It's going to take
00:04:49 - hours or maybe even days to do the proper peer review that's
00:04:54 - required to satisfy our quality expectations. So build the quality
00:04:58 - tasks in and make sure you are allocating the appropriate amount
00:05:02 - of time for those tasks, and finally,
00:05:07 - protect the quality tasks in your WBS. When your project gets
00:05:12 - into delivery challenges and your project is running late, and
00:05:15 - let's face it, our projects are going to get into delivery challenges
00:05:18 - and our projects are going to be late, we as project managers
00:05:22 - have to protect those quality tasks when management, when the
00:05:25 - sponsor, when everybody is on your case and saying, "Steve, you
00:05:29 - need to get this brought back on track. You need to try to accelerate
00:05:34 - the project. What can we cut?" And often, when they look at the
00:05:38 - project plan at the WBS and say, "Oh, three days to do a peer
00:05:43 - review? Let's cut that out. We don't need to do that peer review.
00:05:46 - We will just go on the assumption that the original author has
00:05:50 - created it properly." Or they are going to say, "You don't need
00:05:52 - three days to do that peer review. Let's do it in half a day."
00:05:58 - Protect the quality tasks. In the calm and quiet of project planning,
00:06:03 - if such a state ever exists, but in the calm and quiet of project
00:06:07 - planning, if you've determined that the appropriate quality measure
00:06:11 - is to do a peer review of a 300-page document and you believe
00:06:15 - it's going to take three days to do that peer review in the calm
00:06:19 - and quiet of planning, those are probably the appropriate measures.
00:06:23 - Protect the quality tasks. Try to convince management, try to
00:06:28 - convince your sponsor that no, spending the time on that peer
00:06:32 - review will be time paid back later in the project when we catch
00:06:39 - the errors in the peer review upfront during requirements and
00:06:43 - we are not wasting time on analysis and design and development
00:06:46 - of the wrong requirement, et cetera, et cetera, et cetera. So
00:06:51 - again, this is my soapbox.
00:06:54 - Quality is more than a statement that says this is a quality
00:06:57 - project and we are going to conduct quality activities. Build
00:07:02 - the quality into the project and protect the time to do the quality
00:07:07 - on your project.
00:07:10 - So the first step in defining our quality management process
00:07:13 - is to define the quality requirements. As I said, identifying
00:07:18 - what the sponsor's expectations for quality is. Is this a life
00:07:22 - mission-critical application in which our quality requirements
00:07:27 - is 100% defect-free? Or is this an average application where
00:07:31 - we can expect that there will be some defects that will not be
00:07:35 - caught in the quality process, and where do we need to focus
00:07:39 - our quality process? What are the 20% of the core functions that
00:07:43 - we need to absolutely ensure are error-free, and what are the
00:07:46 - other 80% that, you know we're not going to deliberately introduce
00:07:51 - defects, don't get me wrong, but that the quality measures will
00:07:54 - not be applied as rigorously in those other areas, and the potential
00:07:58 - for defects may exist. The first step in doing that is to identify
00:08:02 - what the acceptance criteria are. How
00:08:07 - will the sponsor
00:08:12 - accept the system?
00:08:17 - Defining in advance what the acceptance criteria is going to
00:08:21 - be. Now, what does that mean?
00:08:25 - We want the acceptor to tell us in advance what degree of issues
00:08:31 - will they be willing to accept when we go into production? Will
00:08:35 - you allow the software to go into production if there are critical
00:08:39 - issues outstanding? And my expectation is the sponsor will not
00:08:44 - allow the system to go into production if there are critical
00:08:48 - issues outstanding. So the acceptance criteria is no critical
00:08:54 - errors. Now, again, we need to define what a critical error is.
00:09:00 - A critical error fundamentally
00:09:03 - affects the results of the system. It just plumb plain does not
00:09:08 - work. So again, I would not expect the system won't go into production
00:09:12 - with any critical errors. We will have less
00:09:17 - than pick a number five serious
00:09:23 - errors. And again, we need to define what serious errors are.
00:09:28 - A serious error is an error that does not impact the integrity
00:09:33 - of the system. A serious error may require some extra workaround.
00:09:37 - A serious error may require some extra manual effort to get the
00:09:42 - job done. But the system will still satisfy the basic raw business
00:09:48 - functionality. And maybe there are less than 15
00:09:55 - minor errors.
00:10:00 - And again, we need to define what a minor error is. A minor error
00:10:04 - is easy workaround, not obvious, does not impact business operations,
00:10:11 - something that would be nice if it was fixed, but literally,
00:10:14 - you can live with it as is probably for the life of the system.
00:10:20 - We need to define the acceptance criteria. No critical errors,
00:10:24 - less than five serious errors, less than 15 minor errors. And
00:10:27 - we need to define that acceptance criteria now we're in planning,
00:10:33 - not the day before we're trying to negotiate whether the system
00:10:37 - will go live.
00:10:39 - Now, let's take that into a practical example.
00:10:43 - We are going to buy a brand new house.
00:10:46 - The acceptance criteria for that brand new house will be a walkthrough.
00:10:50 - We are going to walk through and we are going to inspect our
00:10:53 - brand new home, and we are going to determine whether or not
00:10:55 - that brand new home is acceptable, that I'm willing to sign and
00:11:00 - accept the home as my own, that I will pay the mortgage on it,
00:11:05 - et cetera, et cetera. We should have the same type of criteria.
00:11:09 - When I do my final inspection of that home.. There should be
00:11:12 - no critical errors, i.e. the front door is on and the front door
00:11:17 - will lock, that the heating system works, that the electrical
00:11:20 - system works, that the plumbing system works, et cetera, et cetera.
00:11:25 - And we would not expect to move into that home if the front door
00:11:28 - is missing or the electrical or the heating or the plumbing or
00:11:32 - the key infrastructure components of the house are not there,
00:11:35 - and that the house wasn't built to specification, that I said
00:11:39 - it was going to be a three-bedroom house and the builder said,
00:11:41 - "Oh yes, but I decided that that extra bedroom in the upstairs
00:11:45 - was going to make it too small, so I just made it into one."
00:11:47 - So again, those are our criteria for acceptance. There are no
00:11:52 - more than five serious errors, and again, we need to define what
00:11:56 - a serious error is in terms of our home. A serious error is a
00:12:01 - piece of missing finish. There is a piece of baseboard missing
00:12:04 - in the living room, or there is a kitchen cabinet
00:12:09 - pull or drawer glide that is missing.
00:12:13 - Yes, I could probably accept it if those serious errors are
00:12:19 - infrequent and I have a commitment from the builder to repair
00:12:23 - those serious errors let's say in the next 10 days.
00:12:27 - Now we are getting into the nitpicky stuff. Now there are 15
00:12:30 - minor defects. There is a paint chip in the second bedroom, or
00:12:35 - there is a piece of trim missing in the second bedroom's closet
00:12:40 - back corner. So we are getting into the cosmetic things. And
00:12:46 - if there is no more than 15 of those little cosmetic things,
00:12:49 - and again, we may have some commitment from the builder to fix
00:12:51 - the minors or we may be willing to accept that maybe I, as the
00:12:56 - homeowner, will either just turn a blind eye to them and ignore
00:12:59 - them, or I, the homeowner, will deal with them over time myself.
00:13:03 - But defining that acceptance criteria in advance allows us to,
00:13:07 - as project managers, start to identify the quality measures that
00:13:11 - we are going to put into to ensuring that we are satisfying the
00:13:15 - acceptance criteria.
00:13:18 - Quality measures will be things like testing strategy.
00:13:25 - Are we going to run a systems integration test? Are we going
00:13:27 - to run unit test? Are we going to run a performance test? Are
00:13:31 - we going to run customer acceptance test? And so on.
00:13:35 - Long before we get into a testing strategy, we need to have a
00:13:38 - walkthrough review.
00:13:41 - All system code should be walked through by a peer. All test
00:13:47 - cases should be walked through by a peer. So we have walkthroughs.
00:13:51 - We have peer reviews.
00:13:54 - We have inspections,
00:13:58 - and maybe we have third party
00:14:05 - reviews/audits. But what are the quality measures we are going
00:14:11 - to put in place on our project to ensure that we are going to
00:14:15 - satisfy our sponsor's acceptance criteria?
00:14:19 - How far and how deep our quality measures go are going to be
00:14:23 - dictated in part by our sponsor's acceptance criteria, but partly
00:14:28 - on that cost/benefit analysis. People often think of cost/benefit
00:14:32 - analysis as a financial decision for determining what the project
00:14:37 - budget is. Cost/benefit analysis is equally applicable in quality
00:14:41 - measures. Remember that 20-80
00:14:45 - that I talked about and the 80-20?
00:14:48 - That 20% of the code is going to be subjected to 80% of my testing
00:14:54 - my quality effort. The other 80% of the code is going to get
00:14:59 - the remaining 20%. That's a cost/benefit analysis. Every day
00:15:04 - of testing
00:15:07 - equals X dollars.
00:15:11 - If I develop a testing strategy that's going to allow me to satisfy
00:15:15 - this 80-20, 20-80 rule,
00:15:18 - therefore, I know that my cost is going to be $15,000 for testing.
00:15:24 - That's my cost/benefit analysis for doing a 20-80 split versus
00:15:29 - doing a 50-50 split.
00:15:34 - If I do 50% of my testing effort well, 50-50 is almost a lot,
00:15:39 - but let's say a 40-60,
00:15:42 - 60-40. If I spend 40% of my time testing 60%
00:15:49 - of my time, maybe that number is going to go from $15,000 up
00:15:54 - to $25,000.
00:15:55 - Because we are testing more functionality,
00:15:58 - we are now testing 40% of the functionality instead of 20%,
00:16:03 - I now need to spend more time on testing, which is going to drive
00:16:08 - up my cost. So as we do the cost/benefit analysis on our various
00:16:12 - testing strategies, it's going to allow us to determine whether
00:16:16 - or not we are going to achieve our acceptance criteria. How much
00:16:20 - time can we spend on walkthroughs? Do we do a walkthrough of
00:16:23 - every line of code? Or do we do a walkthrough on only the mission-critical
00:16:28 - lines of code? How much time do we spend on peer reviews? How
00:16:32 - many peer reviews do we conduct? Do we have time? Is there money?
00:16:36 - Is there cost justification associated with having third party
00:16:40 - independent assessors come in and review our quality processes
00:16:45 - or our deliverables in our project? We need to know these quality
00:16:48 - requirements upfront so that we can define the appropriate quality
00:16:53 - activities, and I'm going to jump back on that soapbox for just
00:16:55 - a second, and build them into our project.
00:16:59 - I've already talked about most of the content on this particular
00:17:02 - area already. Once we've identified the requirements, we need
00:17:05 - to then identify the quality measures. How are we going to review
00:17:10 - our work to ensure that it's delivering the results that the
00:17:14 - sponsor is expecting? Inspections code inspections,
00:17:19 - test case inspections,
00:17:24 - deliverable inspections.
00:17:28 - Do we want to get into this concept of pair programming
00:17:34 - where we have active inspections of each other's work? When are
00:17:39 - walkthroughs appropriate? When should we be conducting walkthroughs
00:17:42 - of code versus an inspection? The difference between an inspection
00:17:46 - and a walkthrough, an inspection is typically one person individually
00:17:50 - reviewing the work of another; walkthroughs are typically a broader
00:17:54 - spectrum where you get multiple participants into a room and
00:17:58 - they will review the work. So again, in my humble opinion, inspections
00:18:02 - where I assign Joe to review Mary's work, and Mary will review
00:18:07 - Charlie's work. A walkthrough is when I invite Joe, Mary, Charlie,
00:18:12 - and the rest of the team into a meeting room for an hour, a half
00:18:16 - a day, a day and we will do a joint walkthrough of all of the
00:18:20 - deliverables that are being produced by the collective team.
00:18:24 - Reviews formal reviews, outside
00:18:29 - quality audits,
00:18:35 - outside peers,
00:18:42 - what extra third party assessments do we need to bring in to
00:18:47 - help ensure that our quality is going to be appropriate. Testing,
00:18:50 - talked about it already. What is our strategy for unit testing?
00:18:54 - What is our strategy for system integration testing? What is
00:18:57 - our strategy for performance testing? What is our strategy for
00:19:00 - customer acceptance testing?
00:19:02 - Where appropriate, you may need to bring in independent reviews
00:19:06 - as I said to ensure that the quality of the code is going to
00:19:11 - satisfy our sponsor's expectations on the deliverables we are
00:19:16 - producing for our project.
00:19:19 - Considering the cost of quality is part of determining what the
00:19:23 - appropriate measures should be to develop your quality system.
00:19:29 - And cost of quality comes down to we want to have proactive
00:19:36 - quality measurement activities.
00:19:39 - And prevention and appraisal are part of the proactive. Or do
00:19:43 - we want to have reactive?
00:19:48 - Prevention, this is the walkthroughs.
00:19:53 - This is the inspections.
00:19:57 - This is everything we can do in advance early
00:20:02 - in the life cycle to ensure that we are delivering the right
00:20:06 - product. If we do a walkthrough, if we do an inspection of our
00:20:10 - members' code before the coding pencil has even touched the paper,
00:20:16 - we've done a walkthrough of their code design and we've determined
00:20:20 - there is an error, and we fix the error during the code inspection
00:20:25 - walkthrough, we haven't wasted the time doing the code. We haven't
00:20:29 - wasted the time testing the wrong code, unit testing the wrong
00:20:33 - code, and we haven't wasted any time through our testing process
00:20:37 - prior to actually discovering the code error, which may not be
00:20:41 - found until cat testing, and then going back and doing the rework.
00:20:46 - Appraisal testing,
00:20:51 - inspections, quality audits.
00:20:58 - Again, proactively
00:21:00 - trying to identify where we can find the errors early. And this
00:21:06 - is all predicated on that whole
00:21:10 - cost versus life cycle
00:21:15 - graph in terms of where error prevention happens and the cost
00:21:19 - of error prevention that if you find an error early in your life
00:21:24 - cycle, it costs one unit. If you find it a little later in the
00:21:28 - life cycle, it's going to cost two units. Next stage of the life
00:21:32 - cycle, it's going to cost four units. And then eight units. And
00:21:37 - then 16 units. So if we find the error in analysis versus design
00:21:43 - versus test or development
00:21:46 - versus testing versus production is the whole cost of quality.
00:21:51 - The more cost of quality, the more quality measures we can build
00:21:55 - in that are proactive to discover the errors early is cheaper
00:22:01 - than the reactive which is the cost of the failure, the rework,
00:22:08 - which is again what we are showing in our graph. We do the prevention
00:22:12 - and appraisal cost early, we catch the error in the early stages.
00:22:17 - We don't put enough time in our prevention and appraisal, we
00:22:20 - get into the reactive failure costs, and we start to deal with
00:22:25 - the exponential increases in the cost of our project. So as you
00:22:29 - are building in your quality measures, build in as many prevention
00:22:33 - and appraisal quality measures as possible to try to minimize
00:22:38 - the failure costs, the rework, the retrofitting of the correction
00:22:44 - into existing material produced by your project.
00:22:49 - As you are building your project plan, building in peer reviews,
00:22:55 - inspections, et cetera, you can raise an expectation that there
00:23:02 - will be disputes. During a peer review, Johnny found errors in
00:23:07 - Mary's code. Mary gets defensive and says, "No, those aren't
00:23:11 - errors. Those are simply the ways that I coded it. My way of
00:23:15 - coding will work just as good as yours. It's your way versus
00:23:18 - my way." They both work. There will be disputes involved as we
00:23:23 - work through our quality measures. So part of a good quality
00:23:27 - system will also include a proactive approach to dealing with
00:23:32 - disputes. If during a peer review we have a predefined approach
00:23:38 - that says if during a peer review, Johnny and Mary don't agree
00:23:42 - that a defect was discovered, one person believes it's a defect,
00:23:46 - one person believes it isn't, what is the predefined approach?
00:23:50 - What is the escalation path? How do we deal with, how do we close
00:23:55 - the dispute process? Who are the appropriate participants that
00:23:59 - they need to involve? Do they take it to their team leader? Do
00:24:02 - they bring in a third independent peer and ask them to pick sides?
00:24:07 - Well, I'm not sure a peer is really the right person to satisfy
00:24:12 - disputes, but maybe bring in the team leader or bring in the
00:24:16 - project manager, myself. Or bring in someone from outside the
00:24:21 - project who has less skin in the game. But defining that dispute
00:24:25 - process early with a predefined approach, identify participants
00:24:29 - with the escalation process,
00:24:32 - and non-threatening and non-personal
00:24:38 - will go a long way, again, to having an effective quality process
00:24:44 - in place for your project. And with the quality requirements
00:24:48 - defined and the quality measures selected that are going to fit
00:24:52 - the cost/benefit analysis and a good dispute process, we simply
00:24:56 - document that all in our quality management plan. It is a formal
00:25:00 - definition of the quality. It defines the requirements.
00:25:06 - It defines the responsibilities.
00:25:09 - It defines the defect resolution process. We document it all,
00:25:15 - and we present it, and we obtain approval that if we follow this
00:25:20 - quality management plan, we will satisfy the sponsor's expectations
00:25:25 - for quality, that when we present the code for approval, the
00:25:28 - system for approval, it will be understood that will be implemented
00:25:33 - if there are no critical defects, no more than five serious defects,
00:25:40 - and no more than 15 minor defects, and there will be no negotiating
00:25:46 - at that point. That is the formal definition in the calm and
00:25:49 - quiet of planning. We obtain their approval and we obtain their
00:25:54 - commitment that they will adhere to this policy.
00:26:01 - This nugget was focused on quality plan development. First step
00:26:05 - was to define the quality requirements. What
00:26:10 - is the acceptance
00:26:14 - criteria? Documenting it in advance, identifying the quality
00:26:22 - measures, the inspections, the walkthroughs, the testing processes
00:26:25 - that need to be applied to ensure that we satisfy the acceptance
00:26:29 - criteria, identifying the defect dispute resolution process in
00:26:36 - advance to ensure that it is non-identifying, non-personal, and
00:26:40 - actionable. And then finally, creating the quality management
00:26:44 - plan, presenting
00:26:47 - it, getting approval
00:26:50 - paves the way for successful quality development on the project.
00:26:56 - And to close, I'm going to get back on my soapbox for just another
00:26:59 - second or two and build the quality processes into your WBS,
00:27:05 - ensure that appropriate time is allocated to the tasks. Tasks
00:27:11 - will tend to get completed if you plan them. Tasks will be easier
00:27:15 - to complete if you have the established process in place for
00:27:19 - dispute resolution for tracking the time, and as a project manager,
00:27:24 - we need to protect those quality tasks to ensure that they get
00:27:29 - done so that we can deal with our quality aspects proactively
00:27:34 - early in our life cycle as opposed to reactively later in the
00:27:38 - cycle when the cost of resolution is going to be exponentially
00:27:41 - higher. Build quality in, protect quality, and your project will
00:27:47 - be far more likely to be delivered successfully.
00:27:51 - This concludes our Nugget on Quality Management Plan Development.
00:27:55 - I hope this module has been informative for you, and thank you
00:27:58 - very much for viewing.