CompTIA Project+ PK0-003

Project Quality Management

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

Create WBS and WBS Dictionary

Define Change Management Process

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

00:00:00 - This stop in 4.0 change control and communications, skips over
00:00:05 - 4.4 and goes to 4.5
00:00:09 - quality management or the full definition from the CompTIA is
00:00:13 - 4.5 explain the appropriate steps to insure quality of project
00:00:18 - deliverables. We are skipping over 4.4 is I will be combining
00:00:23 - it with 4.6 and discussing it in the next nugget. This nugget
00:00:28 - is focused on quality management,
00:00:31 - often one of the most overlooked, often one of the most skipped
00:00:36 - components of overall project execution and one of the most dangerous
00:00:42 - components of project execution to be overlooked because quality
00:00:46 - management is where we insure the quality of our deliverables
00:00:51 - hence the acceptability of our deliverables. So I will encourage
00:00:55 - you throughout this nugget to stick to your guns and to insure
00:00:59 - that the time originally planned for quality management is preserved
00:01:05 - and you are allowed to execute on the quality plan that we developed
00:01:09 - during planning.
00:01:12 - As discussed in our planning nuggets project quality management,
00:01:15 - the execution of the quality plan has to two key components.
00:01:20 - Quality assurance and quality control and we will discuss both
00:01:24 - of these in this nugget, quality assurance is all about doing
00:01:28 - the right thing
00:01:31 - if our quality plan says we are going to do x quality assurance
00:01:36 - is about insuring that we do x and it is also about quality control
00:01:41 - insuring that we are doing the things right
00:01:45 - that the deliverables are acceptable that the deliverables satisfy
00:01:50 - the business case under which the project was taken. Both
00:01:54 - quality assurance doing the right things and quality control
00:01:59 - will combine to insure we have quality
00:02:04 - on our project just doing one of quality control or just doing
00:02:11 - one of the quality assurance will not insure overall project
00:02:15 - quality. Quality assurance is doing the right things, quality
00:02:21 - control are doing things right and I will give you an example
00:02:24 - from my background.
00:02:27 - I worked on a project along time ago where I would have to say
00:02:31 - our quality assurance was very poorly done, but our quality control
00:02:36 - was quite well done. Our focus during project delivery was insuring
00:02:42 - that every thing we did was focused on satisfying the project's
00:02:48 - deliverable requirements. Whenever
00:02:52 - our project deliverable requirements was a data dictionary,
00:02:56 - we had to delivery a full complete data dictionary as a part
00:03:01 - of our development project so our team focused on every time
00:03:07 - we quoted a module, we insure that any new data elements identified
00:03:11 - were included in the data dictionary.
00:03:15 - Now, the problem with that was we were insured it was included
00:03:19 - in our personal copy of the data dictionary
00:03:23 - which in retrospect was sadly lacking of the quality assurance
00:03:28 - because by including it our own personal dictionary we weren't
00:03:33 - doing things right. We were doing it in our own personal dictionary
00:03:37 - insuring all of the elements were there
00:03:40 - but we weren't doing it right because we are doing it in our
00:03:44 - personal space. What the net of this was when the time came
00:03:48 - to deliver the data dictionary and we attempted to consolidate
00:03:53 - all of our personal
00:03:56 - data dictionaries into a project
00:04:00 - data dictionary it didn't consolidate. There was a lot of issues,
00:04:06 - different people use different tools, different people used different
00:04:10 - font sizes. Different people used different writing styles, active
00:04:14 - tense versus passive tense. Different
00:04:18 - in the personal data dictionaries resulted in great detail of
00:04:22 - pain creating the project dictionary and it was that pain are
00:04:27 - either rework
00:04:29 - that caused our problems. We weren't able to deliver the project
00:04:33 - data dictionary until we did things, right,
00:04:38 - do it right,
00:04:42 - we had to rework
00:04:45 - all of our personal data dictionaries and create the project
00:04:48 - data dictionary. The content was perfect in our personals, but
00:04:53 - the ability to deliver for the project wasn't there, significant
00:04:57 - rework. Had we done it the right things the first time,
00:05:03 - the delivery of the project dictionary would have been painless
00:05:06 - and then all of this pain all of this rework would not have been
00:05:10 - required. So let's see what quality assurance is all about. As
00:05:15 - in my brief introduction to quality assurance, quality assurance
00:05:18 - is all about doing the right things insuring that the work meets
00:05:24 - the project specifications from a quality
00:05:29 - view point.
00:05:32 - Insuring that we meet the project specifications form the end
00:05:35 - business expectations is quality control. What do we mean by
00:05:40 - meeting the project specifications that we complete
00:05:46 - everything in
00:05:51 - the project? If we said we are going to produce a project data
00:05:56 - dictionary, we produce it. We don't decide halfway through the
00:06:00 - project that says you know what this data dictionary is a really
00:06:03 - silly idea. I am just going to not produce it because I don't
00:06:06 - think it makes sense. If the project says we are going to do
00:06:09 - it complete everything the project said it is going to do and
00:06:15 - we complete it to the project standards and procedures.
00:06:20 - If we said the data dictionary is going to be a global
00:06:24 - data dictionary we adhere to the standards and procedures defined
00:06:29 - for our project for the data dictionary. That is going to be
00:06:32 - the font size.
00:06:34 - That is going to be the writing style.
00:06:40 - The act of
00:06:43 - versus the passive voice that is using known phrases versus verb
00:06:47 - phrases that is following all of the project standards and procedures,
00:06:53 - that is insuring we are using the same tools. If
00:06:58 - we said we are going to produce our project stated dictionary
00:07:00 - in word
00:07:03 - we have to insure that all of our team members are using word
00:07:06 - that some of our team members aren't using open source tools
00:07:10 - or text or a pure text editor that they have seen to find works
00:07:16 - better within their system's development environment and so on
00:07:19 - and so on. It is meeting the project specifications, everything
00:07:24 - the project originally set out it was going to complete an deliver
00:07:29 - two specific standards and procedures is in fact what the project
00:07:34 - does and that is doing the right things and as per my example
00:07:39 - of the data dictionary if we followed and applied consistent
00:07:44 - with quality insurance expectations my data dictionary experience
00:07:49 - would not have been an extensive rework and it actually wasn't
00:07:52 - extensive rework. I was with a consulting firm at that time.
00:07:56 - This was the first project this consulting firm had taken on
00:07:59 - for a local government. We were very anxious to have favorable
00:08:03 - impressions within this local government of this preliminary
00:08:07 - project. We wanted all of our deliverables to be perfect and
00:08:11 - someone only discovered that our data dictionary was far from
00:08:15 - perfect about 2 days before the delivery was due and it turned
00:08:22 - out the project itself did not have the person power to correct
00:08:28 - all of the stupid stuff and I will be blunt it was stupid stuff.
00:08:34 - Critical to having the data dictionary accepted but it was stupid
00:08:38 - things that we in the project didn't adhere to that required
00:08:42 - the rework in fact the entire consulting organization was called
00:08:48 - in and head to work over a weekend of both Saturday and Sunday
00:08:52 - fixing doing the cutting and pasting, doing the blocking, doing
00:08:56 - the corrections required to produce this global dictionary according
00:09:01 - to the standards and procedures. And I can assure you all of
00:09:05 - the other members of our consulting firm were not overly pleased
00:09:09 - with giving up their weekend pick them in and fix our projects
00:09:14 - over site, our project lack of quality assurance
00:09:19 - so again when push comes to shove and your project is having
00:09:23 - delivery challenges
00:09:25 - resist the urge, resist the pressure, resist the Steve, cut the
00:09:32 - time you are spending on quality assurance, we need to focus
00:09:35 - more on writing code as politely as you can without getting fired,
00:09:39 - push back to the boss and say no, I am sorry boss, I really believe
00:09:45 - cutting the time on quality assurance is a bad idea because it
00:09:49 - insures that we are doing the right things and it insures that
00:09:52 - the deliverables that everything we produced is going to be acceptable
00:09:58 - when it is delivered. Quality assurance is an equal partner in
00:10:03 - effective quality management. And the second half of that equal
00:10:07 - partnership is quality control which is really summed up in testing
00:10:10 - and validation which effectively is insuring that we are doing
00:10:14 - it right that all of the work satisfies the requirements that
00:10:19 - the business stated for the project. Doing it right is satisfying
00:10:26 - what was asked for
00:10:32 - and we do that by applying the appropriate testing and validation
00:10:37 - throughout the project. Testing
00:10:44 - is not just a development activity. We test code,
00:10:51 - absolutely, because the code is what is going to be finally delivered
00:10:55 - to the business but we also test our analysis documents
00:11:01 - that the analysis document specifies what was asked for. We test
00:11:06 - our design documents
00:11:09 - to insure that the design document designed what was asked for. We
00:11:14 - test our test plans, we do previous in our test plans, we do
00:11:18 - peer reviews on our code. We do lots of testing
00:11:23 - in the form of validation for the non-code components of our
00:11:28 - project. Testing is so much more than just testing the software.
00:11:34 - Absolutely, we need to test the software and probably the single
00:11:38 - biggest component of testing is testing of the software as we
00:11:42 - will explore in just a moment there is a lot of activity around
00:11:46 - testing at software. There is unit testing the system testing
00:11:49 - there is integration testing. There is performance testing so
00:11:52 - certainly the lion share of quality control is testing the software,
00:11:57 - but we need to test everything. We need to test our documentation.
00:12:01 - We need to test that are analysis
00:12:07 - satisfies requirements. We need to test the design doc
00:12:13 - satisfies what the analysis document was. We need to test our
00:12:18 - test plan
00:12:21 - and how is that for a self fulfilling prophecy? We are going
00:12:24 - to develop a test plan for a project and we need to test that
00:12:29 - the test plan will satisfy insure that all of the requirements
00:12:35 - spaded in the analysis document are going to be properly tested
00:12:39 - and satisfied as part of our project. We are going to test each
00:12:44 - and every component of our project. We are going to test the
00:12:48 - user's manuals. We are going to dry run and test the training
00:12:52 - on a pilot crew on someone who is going to say yes this training
00:12:55 - is adequate. We are going to test our operations manuals. We
00:12:58 - are going to test everything on the project.
00:13:01 - Most of the testing in these areas is not going to be as formal
00:13:05 - as testing of software and again this is often
00:13:13 - called verification more so than testing. Another
00:13:17 - term often used is the concept of peer review
00:13:23 - or self checking.
00:13:29 - Or again many other terms of different organizations you are
00:13:32 - going to use, but
00:13:36 - every deliverable needs to be validated at the appropriate level
00:13:41 - of verification at the appropriate level of peer review, at the
00:13:44 - appropriate level of self checking and I have always said self
00:13:47 - checking in here self checking in it of itself is never sufficient.
00:13:53 - If I was the only one checking the analysis document and I was
00:13:58 - the one who wrote the analysis document that is probably not
00:14:02 - a very fair complete unbiased validation
00:14:07 - so therefore we always again need to bring in a peer review,
00:14:10 - we need to bring in an outsider. We
00:14:13 - need to bring in an expert.
00:14:16 - We need to bring in someone who is going to pre-test
00:14:23 - all of this material before
00:14:28 - the business/user
00:14:33 - see it. And why? Because we want the business
00:14:40 - to have a positive
00:14:44 - experience with our project and we are going to insure the business
00:14:50 - has a positive experience with our project by validating that
00:14:55 - everything we deliver to them that the code we deliver to them
00:14:59 - is going to have a minor number of defects. I would like to be
00:15:02 - able to stand up here and say if we implement effective quality
00:15:05 - control we would never deliver code that has a single bug in
00:15:09 - it and we have effective quality control we would never deliver
00:15:14 - a single document that has a single defect in it or so on. Ideally,
00:15:20 - that is what quality control is striving for is zero defects,
00:15:24 - but recognizing that we are all humans and we will all make mistakes
00:15:29 - at some level. We want to insure that the business has a positive
00:15:33 - experience by having a minimum
00:15:37 - number of defects
00:15:39 - and this term defects applies to more than software. If there
00:15:43 - is an error in the documentation, if it has got a grammatical
00:15:47 - error if it has got a spelling error or there is a total requirement
00:15:52 - missed that is a defect in the document that needs to be fixed.
00:15:57 - We want the business to have this positive experience, we are
00:16:00 - going to pre-test
00:16:02 - through our verification peer review outside unbiased observer,
00:16:08 - expert opinion that we are going to deliver quality deliverables
00:16:14 - and quality code to the business. As
00:16:18 - I said testing of the software is significant, it will be the
00:16:22 - largest single time consumer and the largest single piece of
00:16:28 - value you are going to deliver to the business is a complete
00:16:34 - sweet of software testing.
00:16:44 - Here is an attempt at a complete suite
00:16:47 - not all of these will apply to every project and some projects
00:16:51 - will have some variation on this suite of complete software testing
00:16:57 - principles. I would like to suggest that the single most important
00:17:02 - piece in the testing suite is the unit test which is done by
00:17:07 - the developer
00:17:09 - where the developer validates
00:17:13 - that the code works
00:17:17 - and we don't just stop at saying that the code works, but the
00:17:20 - code works to the specification
00:17:27 - and it is generally considered the best way to validate that
00:17:31 - the code works to the specification is that the unit test plan
00:17:35 - UTP is created
00:17:39 - based on the spec
00:17:43 - before the code is written. So
00:17:50 - if we write the unit test plan to validate the code is going
00:17:56 - to function according to the specification and then we rate the
00:18:00 - code there is a high probability that in fact that if the unit
00:18:06 - test plan complete successfully that we have validated that the
00:18:10 - code works to the specification and the risk of doing it the
00:18:13 - other way around of writing the code and then writing the test
00:18:17 - plan is at the developer in separating a test plan to test that
00:18:22 - the code he or she wrote
00:18:25 - works based on how he or she wrote it which is not necessarily
00:18:30 - the specification.
00:18:32 - Unit test should
00:18:36 - validate test all
00:18:41 - functionality according to the specification. If
00:18:49 - the screen and let's assume this is an online screen that the
00:18:52 - developers developing. If the screen has 10 data fields and each
00:18:58 - of those data fields has a specific set of edit criteria the
00:19:04 - unit test plan should validate that every possible error and
00:19:09 - every possible acceptance criteria on each one of those fields
00:19:14 - is satisfied. Now let's take that to another level of specification,
00:19:19 - one of the fields on the screen is the date of birth and we are
00:19:24 - writing a university registration system so the edits, the business
00:19:29 - requirements, the specification for the date of birth for university
00:19:33 - registration system is if the date of birth compared to today's
00:19:38 - date is in the range of 16 years of age to
00:19:45 - 45 years of age then that is considered to be a valid date of
00:19:51 - birth for university registration
00:19:55 - test condition passed. And again, I just picked 16 and 45 at
00:20:00 - the air and you are going to say, "But Steve, it is possible
00:20:04 - that you could have a child prodigies who are going to university
00:20:07 - before the age of 16 and it is possible that with the life time
00:20:12 - learning experiences in place today that people will be going
00:20:15 - to university long past 45 and agree and my specification allowed
00:20:21 - for that." It goes on to say that if the date of birth compared
00:20:26 - to today's date is between the ages of 10 and 16
00:20:32 - then we are going to produce a warning message that says, "Please
00:20:36 - verify date of birth
00:20:40 - and validate that you have iterated correctly" and will accept
00:20:43 - it as a university registration for the child prodigies and if
00:20:48 - the date of birth is greater than 45 and less than I don't know
00:20:53 - how old is lifetime learning going to work, 95 years o age. Again
00:20:58 - produce a warning message that says, "Please that the date of
00:21:01 - birth" but again we are going to accept it as a valid registration
00:21:04 - for the university and the reason for those warning messages
00:21:07 - is try to catch typos in the date birth. We are going to let
00:21:13 - them come to a university, but if they are you know between 10
00:21:15 - and 16 and 45 to 95 it is possible it is a typo let's just do
00:21:20 - a quick check
00:21:22 - unit test plan should cover those criteria's. It needs to test
00:21:27 - that date of birth with an age less than 10 is not going to be
00:21:31 - accepted to the university and a date birth of greater than 95
00:21:35 - or maybe we want to be more reasonable 115
00:21:38 - is not going to be accepted into the university.
00:21:42 - And we need to insure that a date of birth that is not numeric
00:21:46 - and we need to insure date of birth that is in the future, and
00:21:50 - we need to insure that a date of birth that is in the wrong format
00:21:54 - maybe only two digits for the year rather than the four digits
00:21:58 - for the year and so on and so on and so on. A unit test plan
00:22:03 - for single field on the screen could well have 12, 15, specific
00:22:12 - test cases that need to be validated just for the date of birth
00:22:17 - and then you have other test conditions that must be validated
00:22:20 - for every other specification for that screen.
00:22:24 - A unit test plan should validate all functionality complete validation,
00:22:30 - not just a simple test that says, "Oh here is the date of birth
00:22:33 - that somebody who's 19 enrolled." Here is somebody with a date
00:22:37 - of birth that is 199
00:22:40 - failed that is not a good unit test. The unit test validates
00:22:45 - all functionality
00:22:47 - now. I have to stop and say within pick and finds a reasonableness
00:22:53 - and here I put a huge
00:22:56 - quantitative measure in there. What is within the confines of
00:23:01 - reasonableness, do I validate every date of birth possible?
00:23:07 - Probably not, I don't need to validate that a 16 and 17 and an
00:23:11 - 18 and a 19 and a 20 and a 21 year old all get accepted.
00:23:16 - Do I validate that everybody between 10 and 16 and so on and
00:23:20 - so on? No. But I have to apply reasonableness checks to try to
00:23:25 - validate all of the functionality within the confines of the
00:23:29 - time available to the project for testing
00:23:33 - and again that is a bit of an oxymoron. I am saying I need to
00:23:36 - validate all functionality but realizing that we probably don't
00:23:40 - have time to validate all functionality. We have to validate
00:23:44 - that the core mission critical functionality is tested extremely
00:23:48 - well and that the non-core fringe functionality gets some attention
00:23:54 - to testing but probably not as much.
00:23:59 - So I have compromised my statement that we should validate all
00:24:03 - functionality by saying within the confines of the available
00:24:06 - time for unit testing recognizing that some test cases, unit
00:24:12 - test cases will be more mission critical than others and we have
00:24:16 - to focus on the more mission critical.
00:24:20 - With a good complete unit test executed and passed the code passes
00:24:26 - on and we begin functional testing or integration testing combining
00:24:31 - all of the individual pieces of code into a full registration
00:24:37 - system where we combine the enrollment system with the core selection
00:24:41 - system with the class scheduling system with the whatever components
00:24:45 - to do a full functional test. As we move down or up in our hierarchy
00:24:51 - of testing depending on how you see the testing pyramid written
00:24:55 - functional testing should not retest the same features and functions
00:25:00 - that we did in unit test. So functional testing is not about
00:25:03 - testing that the date of birth edit works, functional testing
00:25:08 - is about validating that a student enrolled on the enrolment
00:25:12 - screen is properly updated in the database and that, that student
00:25:17 - is not available to participate in course selection so we are
00:25:21 - starting to validate the functionality and we do not
00:25:26 - repeat functionality from unit test, compatibility testing, maybe
00:25:33 - it has to integrate with other systems, maybe it has to run in
00:25:35 - specific hardware. Again,
00:25:38 - very focused testing as we move from functional testing or compatibility
00:25:42 - testing into system testing again we are going to build on it
00:25:46 - is incremental. We are not going to retest the data added, that
00:25:49 - has been done. We are not going to retest that the student is
00:25:53 - now knowledgeable for class selection. We are going to start
00:25:56 - to test end to end
00:26:01 - functionality that a student is enrolled, is registered, takes
00:26:05 - classes, gets grades, passes, graduates,
00:26:10 - and pays the library fines. So we are starting to provide full
00:26:14 - into end testing without repeating the date of birth edits
00:26:20 - if we are buying software from third party components we may
00:26:24 - need to do a special level of factory testing. If there are
00:26:28 - specific performance criteria, we must be able to process 60,000
00:26:34 - enrollment transactions an hour or probably more appropriate
00:26:38 - performance test. We must be able to process 60,000 class selections
00:26:42 - in an hour to deal with that high performance peek during the
00:26:47 - first week of each term when all of our students are selecting
00:26:51 - their courses and finally we will pass.
00:26:55 - This is where the project testing stops.
00:27:00 - This is where we are insuring that we had given the business
00:27:03 - that positive experience.
00:27:06 - Project testing stops. Acceptance which is the business validation
00:27:11 - testing BV starts and we expect to have minimal
00:27:18 - defects because we didn't add a good job of testing. And
00:27:24 - throughout quality control we need to plan for and allow for
00:27:28 - a time for rework and retesting
00:27:31 - and that is not just for software that is for all testing and
00:27:35 - validation. Document rewrites as well as code defects.
00:27:41 - Part of reworking a request is, document the test failures formally.
00:27:48 - You need to log it and we need to track
00:27:53 - to closure.
00:27:55 - So every time a peer review identifies a document defect every
00:28:00 - time a developer identifies a unit test defect, every time a
00:28:04 - tester identifies a functional or a system or a performance defect
00:28:08 - it needs to be documented formally. It needs to be in a log and
00:28:13 - we need to manage it and track it to closure. Once
00:28:17 - the defect has been properly logged it will be assigned for correction
00:28:23 - and it will be assigned back to the original author or typically
00:28:28 - it will be assigned back to the original author. So if it is
00:28:31 - a document defect it would be assigned back to the analyst who
00:28:35 - wrote that document or that chapter or that section of the document
00:28:39 - for a correction. If it is a piece of code it will be assigned
00:28:42 - back to the developer for correction. The developer, the analyst,
00:28:47 - the author of the document will correct the defect and then we
00:28:51 - will rerun
00:28:52 - sufficient test to revalidate that the defect was in fact fixed
00:29:00 - and we will run sufficient test to revalidate and regression
00:29:07 - test to insure that we didn't
00:29:13 - break something else. And
00:29:21 - in my experience, often this rerunning sufficient test to revalidate
00:29:26 - is often not well done especially we are in the crunch of, we
00:29:32 - are late and we need to get this code delivered to acceptance
00:29:35 - test. We will document the failure, we will assign it and we
00:29:40 - will correct it and we will run one test
00:29:44 - very tiny. We will run test to validate that the original core
00:29:51 - defect identified has been corrected but we won't run sufficient
00:29:55 - test to fully revalidate that and we won't run sufficient test
00:29:59 - to do adequate regression test to make sure we didn't break something
00:30:04 - else along the way and again. A lot of this re-run sufficient
00:30:10 - test to revalidate is more code focused,
00:30:13 - but not totally. If we have identified a defect in an analysis
00:30:18 - document and the analyst went in and corrected the basic defect,
00:30:23 - the missing requirement have they completed all of the updates
00:30:28 - required for that missing requirement. Maybe the update for missing
00:30:32 - requirement three
00:30:34 - has an impact to an existing requirement five. Have they gone
00:30:39 - through and validated what the impact of adding requirement three
00:30:43 - is to requirement five and so on and so on. So again there is
00:30:47 - an element of rework and retest throughout all aspects of quality
00:30:51 - control but certainly more heavenly based in
00:30:56 - the software testing aspect. But spend the time resist the urge
00:31:01 - the cut the corners and your project will be better off for it
00:31:05 - will deliver that positive experience to the business because
00:31:08 - when they get the document for a review or when they get the
00:31:12 - code for acceptance testing it is going to be very defect light
00:31:16 - or very defect free. And
00:31:19 - the final aspect of project quality management and I am only
00:31:22 - going to touch on this nugget because when I am going to deal
00:31:25 - with this in much more detail in the next nugget on project delivery
00:31:28 - management is quality measures that we can apply during the execution
00:31:34 - of our project to help improve the state of the quality assurance
00:31:39 - and/or the quality control on our project. We can go through
00:31:44 - and review and measure our quality
00:31:49 - delivery. In any of a number of ways we can apply control charts
00:31:55 - to determine what is our performance are we getting the appropriate
00:32:00 - number of defects, are we getting an abnormal level of defects. We
00:32:03 - can sample unit test plans. We can sample unit test plan execution.
00:32:08 - We can sample test results. We can look for trends are we getting
00:32:12 - early defects and capturing them and correcting them or was all
00:32:17 - of the first code written defect free because it was written
00:32:21 - under a less time constraints and the later pieces of code are
00:32:24 - more defect heavy. We can look at Pareto charts to determine
00:32:28 - what our trends, and our most appropriate actions for correction.
00:32:34 - We can flow chart problems. We can do fishbone for root cause
00:32:37 - analysis. Lots of different quality measures and
00:32:43 - corrective actions
00:32:49 - that we are going to apply to improve the quality in our project
00:32:54 - that we will discuss in much more detail in the next nugget. This
00:32:58 - concludes our nugget on project quality management. Project quality
00:33:02 - management has two key components, quality assurance,
00:33:06 - doing the right things
00:33:14 - and quality control doing things
00:33:19 - right. Quality assurance is all about doing everything that we
00:33:25 - planned to do for the projects that we produce all deliverables
00:33:28 - and that all deliverables follow the standards and procedures
00:33:33 - that were defined during planning to insure that the deliverables
00:33:38 - will satisfy the expectations of the business and quality control
00:33:42 - is all about insuring that the content in those deliverables
00:33:47 - satisfies the expectations for the problem under which the project
00:33:51 - was taken on. They are equal partners in quality management. Quality
00:33:56 - assurance insures that what we are producing is acceptable from
00:34:00 - a format, from a style from a content, from an expectation management
00:34:05 - view point and quality control is about insuring that the product
00:34:11 - satisfies addresses the problem for which the project was taken
00:34:15 - on. Doing one without the other is doing no justice to your project.
00:34:22 - Equal time and attention needs to be paid to both quality assurance
00:34:26 - and quality control for your project to truly deliver the quality
00:34:32 - needed to insure a positive business experience with the results
00:34:37 - of your project. This
00:34:39 - concludes our nugget on project quality management. I hope this
00:34:43 - module has been informative for you and thank you very much for viewing.

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

This forum is for community use – trainers will not participate in conversations. Share your thoughts on training content and engage with other members of the CBT Nuggets community. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.

Bookmarks

Pick up where you left off watching a video.

Notes

Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with one-to-one assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer

Certifications:
PMI-PMP, PMI-ACP, PMI-SP, Project+

Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development


Stay Connected

Get the latest updates on the subjects you choose.


  © 2014 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS