CompTIA Project+ PK0-003

Quality Management Plan

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

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.

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

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. 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.


Pick up where you left off watching a video.


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 assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


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

Stay Connected

Get the latest updates on the subjects you choose.

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