Leadership

Find errors as early as possible on your project


Project teams generally use three types of quality management activities:

  • Quality planning
  • Quality control
  • Quality assurance

The purpose of quality assurance is to prevent as many errors as possible by having sound processes in place to begin with. The purpose of quality control is to inspect or test the deliverables to find as many remaining errors as possible.

One important aspect of quality control is to find errors and defects as early in the project as possible. Therefore, a good quality control process will end up taking more effort hours and cost upfront. However, there will be a large payback as the project progresses.

For instance, it's much better to spot problems with business requirements during the analysis phase of the project rather during the testing process. If you see the problem during the requirements gathering process it might just take a call to your client and the quick update of a Word document to fix it. On the other hand, if you discover this problem in the testing phase, it could impact the business requirements, the solution design, and some of the construct work. It will also require you to re-test the solution again. As you can see, this is a potentially huge impact to your project.

Likewise, if you were manufacturing a computer chip, it would be much cheaper to find a problem with a computer chip when the chip is manufactured, rather than have to replace it when a customer brings the computer in for service after a purchase. In fact, if the error isn't caught until after the chip is sold to the customer, the cost to make the repair might cost more that the entire cost to manufacture the product to begin with.

There was a project early in my career that applied poor shortcuts to the development process. Since the programmers were under time pressure to complete their modules, they figured they would write the code and make sure it compiled cleanly. Then they would then call the module complete, with the attitude that they could "fix it in the testing phase." They thought that they were just deferring their unit test time until later in the project. But by pushing these errors further downstream, it actually took much longer to fix the problems later - to the detriment to the overall project.

In Figure A, we see a traditional approach to finding errors.

Figure A

On many projects the team plans to find as many errors as possible during the testing process, with some errors not caught until support/maintenance.
In Figure B we see the better approach. It is much better to catch any errors that are introduced as quickly as possible. In other words, errors in the deliverable created in the Analysis Phase should be caught in the Analysis Phase; errors introduced in the Design Phase should be caught during the Design Phase, etc. This greatly minimizes the impact of correcting the errors.

Figure B

The bottom line is that the project team should try to maintain high quality and low defects during the deliverable creation processes, rather than hope to catch and fix problems during the testing phase at the end of the project (or worse, have the client find the problem after the project has been completed).

11 comments
donstrayer
donstrayer

Regardless of the development methodology, the project manager should establish a quality management plan as a critical part of the overall project plan. A good one encourages all team members and stakeholders to report potential defects as soon as identified, whether in requirements, design, code, or anywhere else, and establishes procedures and responsibility for evaluation, prioritization, disposition and resolution. Start with an Issues Management Plan, but understand the difference. Only quality issues are transferred to the quality management process -- At which point the issue should be closed since it is being handled by quality management. With agile methods many quality issues are resolved quickly in due course. Only those issues that must be escalated to project management for resolution need be reported to the issues/quality management process. The quality plan should specify criteria for this escalation.

drowningnotwaving
drowningnotwaving

That is, [b]develop[/b] your test criteria / environment / scenarios before you actually develop the code. That is one of the methods encouraged by the "Lean" movement and it has worked wonders in our company. * It puts emphasis on examining the the "Design" before commencing the coding process, which is an immediate and measurable benefit; * It ensures that the test is independent of the code. We had experiences where the code was being tested, but the criteria was often the code itself. "Does it work?" is not the same as "Does it do the job intended?". Well, it worked for us and was easy to implement in a small team. We apply this across all aspects of our service delivery, not just code development.

sherman.meeds
sherman.meeds

It doesn't matter what methodology you use to develop, the concept of finding mistakes or judgement errors as quickly as possible reduces overall cost and project resources necessary. What is even more important, it tends to change the project direction and the end product gets better. `Quality` up front might seem to be a reasonable goal, but I have yet to find a perfect process that doesn`t allow mistakes or misjudgements to enter in during requirements definition, architectural design, or even in the initial problem statement, especially when you are building something in an organization that will change things in unknown or unproven ways. RAD confronts this better because, by definition, there is a constant means to reestablish the project requirements and rethink the definition of success. However, this does not mean that RAD cannot benefit from an attempt to better the processes ongoing in a project, and that includes problem definition and project change. The concept of finding errors as early as possible still applies. Unfortunately, the idea of taking the opportunity to rethink a project to continually work to find mistakes quickly gets lost in the day-to-day grind. A focus on the team`s ability to find problems must be maintained or the project begins to go off track. That seems to me to be the point of the article, not presenting techniques that work only with the waterfall approach.

ajaybit
ajaybit

Nothing works if the manager wants to track everyting from his xls without any prior knowledge of the scope of work. In the absence of a right person to lead a simple project also becomes a R&D topic. A person infested with errors can only multiply errors.

Tony Hopkinson
Tony Hopkinson

Twenty years and counting still waiting for the Well understood requirement, that does not change. Spotting 'errors' early, well yes. Being able to identify them before you build them and nothing changing, rarer than rocking horse manure. Quality is an ongoing process not an add on dividing it in to three bits is just three add ons. Been there, done that, doesn't work in practice.

sergio.tarzia
sergio.tarzia

No groundbreaking news. I'm sorry. I think Quality starts at the beginning. It applies holistically to the whole process and not just the SDLC - this is a very narrow view. I think this discussion needs to be taken to the next step - you need to test your requirements and the business case as well, before you build, ensure the vision is well understood and have traceability that the requirements are in fact aligned with the vision, are sufficient and will deliver a system that will realise BUSINESS BENEFITS envisaged in the business case. And the team needs to know these! (Hey, this is why the gap between business and IT, right?) The business couldn't care less about your SDLC process (which is what you are outlining here). They only care about getting what they want. As I said, Quality starts at the begining, and runs until the end, not just the SDLC. There are best practice frameworks (Use Case analysis, RTM) that address the very topic I raised here. Hope this helps. Sergio Tarzia

Tony Hopkinson
Tony Hopkinson

Critical is adjusting the devleopment process so you make less mistakes. The plan you state as critical is the one that comes into play when things have already gone nipples up.

Tony Hopkinson
Tony Hopkinson

I'm a big fan of iterative development. Waterfall. agile scrum, prince, qad, rad, jad all miss the point. Set the methodology based on the project, not define the project to use the methodology.

ian
ian

Unfortunately far too many developers still adopt the "fix it when we find it" approach. Sadly, the people who do that are probably the ones least likely to be reading this.....

donstrayer
donstrayer

True. But you still need this plan to deal with problems when they arise, as they will. A proper quality plan includes causal analysis. And part of the resolution may be to adjust the development process to eliminate the root cause.

Tony Hopkinson
Tony Hopkinson

But the purpose of this pile of paper is to reduce and preferably eliminate. In practice most of these systems are merely a printed excuse for screwing up again. They are backwards, documenting mistakes becomes more important than preventing them. Sometimes you can't, some times you have to plan that you may not, but your plans should get better, you should attack part of it and kill it. When you get to insurmountable and in our business you often do there's always something cheap that you could do to make it less likely. I reduced the incidence of one particular mistake by knocking up two bitmaps to use as wall paper one had Primary on it the other Backup. We'd swapped over for maintenance and some one decided to use the server on the left to edit an image twice the size of it's memory. If I knew who, I could have come up with some extra responses as well.

Editor's Picks