PROJECT MONITORING AND EVALUATION AND ITS

IMPORTANCE

MONITORING

This is the regular systematic collection and analysis of information to track the
progress of program implementation against pre-set targets and objectives. It
aims to answer the question “did we deliver?”

Monitoring Clarifies program objectives, Links activities and their resources to

objectives, Translates objectives into performance indicators and sets targets,
Routinely collects data on these indicators, compares actual results with targets

And Reports progress to managers and alerts them to problems

Monitoring gives information on where a policy, program or project is at any

given time (or over time) relative to respective targets and outcomes.
Monitoring focuses in particular on efficiency, and the use of resources.

While monitoring provides records of activities and results, and signals

problems to be remedied along the way, it is descriptive and may not be able to
explain why a particular problem has arisen, or why a particular outcome has
occurred or failed to occur.

Evaluation deals with questions of cause and effect. It is assessing or estimating

the value, worth or impact of an intervention and is typically done on a periodic
basis – perhaps annually or at the end of a phase of a project or program.

EVALUATION
This is the objective assessment of an ongoing or recently completed project,
program or policy, its design, implementation and results. It answers the
question “What has happened as a result?”

Evaluation Analyzes why intended results were or were not achieved, Assesses
specific casual contributions of activities to results, Examines implementation
process, Explores unintended results, Provides lessons, highlights significant
accomplishments or program potential and offers recommendations for
improvement

Evaluation looks at the relevance, effectiveness, efficiency and sustainability of

an intervention. It will provide evidence of why targets and outcomes are or are
not being achieved and addresses issues of causality.

THE IMPORTANCE OF MONITORING & EVALUATION

Monitoring and evaluation (M&E) helps those involved with any type of
projects to assess if progress desired is being achieved.

M&E benefits the key actors involved in community development in the

following ways:
For project executors (i.e., a company Community Relations Team, a
company/NGO partnership, or a company foundation), M&E can improve
management. By monitoring progress against defined goals, a project manager
can assess what is working and what is not, and from there can determine what
changes should be made to a project. This inturn makes it possible to improve
the way things are being done in the project organization.

For companies, whether executing a project or supporting it through

partnership or funding, M&E can be used to demonstrate progress to internal
management and to external stakeholders. Internally, measurable results can
justify continued funding and clarify the return on investment of community
development efforts to managers and shareholders. Externally, the results of
M&E can demonstrate commitment to and competence in community
development, and thus help a company maintain its social license to operate.
This makes the companies to make sound decisions concerning major projects
undertaken and to know where to invest.

For community members and NGOs, participating in M&E is an opportunity

to influence the design and execution of community development projects.
Furthermore, by providing feedback on whether programs are achieving aims in
line with community needs and desires, M&E is a powerful accountability
mechanism.

(Our next article on challenges in monitoring and evaluation

coming soon…)
 Acceptance testing
From Wikipedia, the free encyclopedia
Acceptance testing of an aircraft catapult

Six of the primary mirrors of the James Webb Space Telescope being prepared for acceptance testing

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if
the requirements of a specification or contract are met. It may involve chemical tests, physical tests,
or performance tests.
In systems engineering it may involve black-box testing performed on a system (for example: a piece
of software, lots of manufactured mechanical parts, or batches of chemical products) prior to its
delivery.[1]
In software testing the ISTQB defines acceptance as: formal testing with respect to user needs,
requirements, and business processes conducted to determine whether a system satisfies the
acceptance criteria and to enable the user, customers or other authorized entity to determine
whether or not to accept the system.[2] Acceptance testing is also known as user acceptance testing
(UAT), end-user testing, operational acceptance testing (OAT) or field (acceptance) testing.
A smoke test may be used as an acceptance test prior to introducing a build of software to the main
testing process.[not verified in body]

Contents
[hide]

 1Overview
 2Process
 3User acceptance testing
 4Operational acceptance testing
 5Acceptance testing in extreme programming
 6Types of acceptance testing
 7List of acceptance-testing frameworks
 8See also
 9References
 10Further reading
 11External links

Overview[edit]
Testing is a set of activities conducted to facilitate discovery and/or evaluation of properties of one or
more items under test.[3] Each individual test, known as a test case, exercises a set of predefined test
activities, developed to drive the execution of the test item to meet test objectives; including correct
implementation, error identification, quality verification and other valued detail.[3] The test
environment is usually designed to be identical, or as close as possible, to the anticipated production
environment. It includes all facilities, hardware, software, firmware, procedures and/or
documentation intended for or used to perform the testing of software.[3]
UAT and OAT test cases are ideally derived in collaboration with business customers, business
analysts, testers, and developers. It's essential that these tests include both business logic tests as
well as operational environment conditions. The business customers (product owners) are the
primary stakeholders of these tests. As the test conditions successfully achieve their acceptance
criteria, the stakeholders are reassured the development is progressing in the right direction.[4]

 User acceptance test (UAT) criteria (in agile software development) are usually created by
business customers and expressed in a business domain language. These are high-level tests
to verify the completeness of a user story or stories 'played' during any sprint/iteration.
 Operational acceptance test (OAT) criteria (regardless if using agile, iterative or sequential
development) are defined in terms of functional and non-functional requirements; covering key
quality attributes of functional stability, portability and reliability.

Process[edit]
The acceptance test suite may need to be performed multiple times, as all of the test cases may not
be executed within a single test iteration.[5]
The acceptance test suite is run using predefined acceptance test procedures to direct the testers
which data to use, the step-by-step processes to follow and the expected result following execution.
The actual results are retained for comparison with the expected results.[5] If the actual results match
the expected results for each test case, the test case is said to pass. If the quantity of non-passing
test cases does not breach the project's predetermined threshold, the test suite is said to pass. If it
does, the system may either be rejected or accepted on conditions previously agreed between the
sponsor and the manufacturer.
The anticipated result of a successful test execution:

 test cases are executed, using predetermined data

 actual results are recorded
 actual and expected results are compared, and
 test results are determined.
The objective is to provide confidence that the developed product meets both the functional and non-
functional requirements. The purpose of conducting acceptance testing is that once completed, and
provided the acceptance criteria are met, it is expected the sponsors will sign-off on the product
development/enhancement as satisfying the defined requirements (previously agreed between
business and product provider/developer).

User acceptance testing[edit]

User acceptance testing (UAT) consists of a process of verifying that a solution works for the
user.[6] It is not system testing (ensuring software does not crash and meets documented
requirements), but rather ensures that the solution will work for the user (i.e., tests that the user
accepts the solution); software vendors often refer to this as "Beta testing".
This testing should be undertaken by a subject-matter expert (SME), preferably the owner or client of
the solution under test, and provide a summary of the findings for confirmation to proceed after trial
or review. In software development, UAT as one of the final stages of a project often occurs before a
client or customer accepts the new system. Users of the system perform tests in line with what
would occur in real-life scenarios.[7]
It is important that the materials given to the tester be similar to the materials that the end user will
have. Testers should be given real-life scenarios such as the three most common or difficult tasks
that the users they represent will undertake.[citation needed]
The UAT acts as a final verification of the required business functionality and proper functioning of
the system, emulating real-world conditions on behalf of the paying client or a specific large
customer. If the software works as required and without issues during normal use, one can
reasonably extrapolate the same level of stability in production.[8]
User tests, usually performed by clients or by end-users, do not normally focus on identifying simple
cosmetic problems such as spelling errors, nor on showstopper defects, such as software crashes;
testers and developers identify and fix these issues during earlier unit testing, integration testing, and
system testing phases.
UAT should be executed against test scenarios.[citation needed] Test scenarios usually differ from System or
Functional test cases in that they represent a "player" or "user" journey. The broad nature of the test
scenario ensures that the focus is on the journey and not on technical or system-specific details,
staying away from "click-by-click" test steps to allow for a variance in users' behaviour. Test
scenarios can be broken down into logical "days", which are usually where the actor
(player/customer/operator) or system (backoffice, front end) changes.[citation needed]
In industry, a common UAT is a factory acceptance test (FAT). This test takes place before
installation of the equipment. Most of the time testers not only check that the equipment meets the
specification, but also that it is fully functional. A FAT usually includes a check of completeness, a
verification against contractual requirements, a proof of functionality (either by simulation or a
conventional function test) and a final inspection.[9][10]
The results of these tests give clients confidence in how the system will perform in production. There
may also be legal or contractual requirements for acceptance of the system.

Operational acceptance testing[edit]

Operational acceptance testing (OAT) is used to conduct operational readiness (pre-release) of a
product, service or system as part of a quality management system. OAT is a common type of non-
functional software testing, used mainly in software development and software
maintenance projects. This type of testing focuses on the operational readiness of the system to be
supported, and/or to become part of the production environment.

Acceptance testing in extreme programming[edit]

Acceptance testing is a term used in agile software development methodologies,
particularly extreme programming, referring to the functional testing of a user story by the software
development team during the implementation phase.[11]
The customer specifies scenarios to test when a user story has been correctly implemented. A story
can have one or many acceptance tests, whatever it takes to ensure the functionality works.
Acceptance tests are black-box system tests. Each acceptance test represents some expected
result from the system. Customers are responsible for verifying the correctness of the acceptance
tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests
are also used as regression tests prior to a production release. A user story is not considered
complete until it has passed its acceptance tests. This means that new acceptance tests must be
created for each iteration or the development team will report zero progress.[12]

This section needs

expansion. You can help by adding to
it. (May 2008)

Types of acceptance testing[edit]

This section does not cite any sources. Please help improve this section by adding
citations to reliable sources. Unsourced material may be challenged
and removed. (March 2015) (Learn how and when to remove this template message)

Typical types of acceptance testing include the following

User acceptance testing
This may include factory acceptance testing (FAT), i.e. the testing done by a vendor before
the product or system is moved to its destination site, after which site acceptance testing
(SAT) may be performed by the users at the site.[13]
Operational acceptance testing
Also known as operational readiness testing, this refers to the checking done to a system to
ensure that processes and procedures are in place to allow the system to be used and
maintained. This may include checks done to back-up facilities, procedures for disaster
recovery, training for end users, maintenance procedures, and security procedures.
Contract and regulation acceptance testing
In contract acceptance testing, a system is tested against acceptance criteria as documented
in a contract, before the system is accepted. In regulation acceptance testing, a system is
tested to ensure it meets governmental, legal and safety standards.
Alpha and beta testing
Alpha testing takes place at developers' sites, and involves testing of the operational system
by internal staff, before it is released to external customers. Beta testing takes place at
customers' sites, and involves testing by a group of customers who use the system at their
own locations and provide feedback, before the system is released to other customers. The
latter is often called "field testing".

List of acceptance-testing frameworks[edit]

This section does not cite any sources. Please help improve this
section by adding citations to reliable sources. Unsourced
material may be challenged and removed. (March 2015) (Learn how
and when to remove this template message)

 Concordion, Specification by example (SbE) framework

 Concordion.NET, acceptance testing in .NET
 Cucumber, a behavior-driven development (BDD) acceptance test framework
 Capybara, Acceptance test framework for Ruby web applications
 Behat, BDD acceptance framework for PHP
 Lettuce, BDD acceptance framework for Python
 Fabasoft app.test for automated acceptance tests
 Framework for Integrated Test (Fit)
  FitNesse, a fork of Fit
 iMacros
 ItsNat Java Ajax web framework with built-in, server based, functional web
testing capabilities.
 Mocha, a popular web acceptance test framework based on Javascript and
Node.js
 Ranorex
 Robot Framework
 Selenium
 Specification by example (Specs2)
 Watir
 Gauge (software)

The difference between

TESTING and EVALUATION
They are not the same thing!

Testing is a method of finding out whether a solution is working as it should,

e.g. giving correct output, working fast enough, handling expected loads,
responding to user inputs properly.
Testing takes place during development as the solution is being built.
Testing is carried out by the solution’s developers.

Evaluation is a process of judging how well the system’s original intended goals
have been achieved.

Evaluation happens after the solution has been developed, and its users have
used it long enough to become familiar with it and can use it effectively.
Evaluation usually is carried out the by the solution’s owners and users.

CRITERIA
Testing and evaluation can use the same criteria, which are the qualities or
attributes you want to test or evaluate.
Sample effectiveness criteria:
  accuracy
 robustness
 security
 enjoyability
 completeness
 readability
 attractiveness
 clarity
 accessibility (for those with disabilities)
 timeliness (being available when it’s needed)
 communication of message
 relevance
 usability

Efficiency criteria include:

 ease of use
 cost (purchase price
 speed
 the amount of labour required to make it work

METHODS
Evaluation and testing methods are the actions taken to measure the chosen
criteria.

SOME TESTING METHODS

 Manual recalculation
 Penetration testing of networks
 Stress testing – deliberately working the solution hard to see if it fails
under pressure
 Testing that validation rules work properly
 User acceptance testing by a typical user
 Using typical, unusual and invalid test data to test the solution’s behaviour
 Integration testing – to see if components of the solution interact properly
 performing all available user actions to check that the system responds
 appropriately

TYPICAL EVALUATION METHODS

 Interviewing users to get their opinions about the solution’s ease of use
 Questionnaires
 Surveys
 Analysis of records and data to find differences between the old system
and the new one
 Observation of the system in actual use

Evaluation usually involves conducting interviews, surveys, looking at logs,

observing the system in use, looking at the solution’s recent performance over
time.

A comparison of testing and evaluation:

CRITERION TESTING EVALUATING

Accuracy Manually recalculate a value and Count the number of complaints
compare the result with the output of about inaccurate payslips over the
the solution’s formula past 3 months
Speed Use a stopwatch to time how long it Use logs to count how many invoices
takes to process and print a batch of have been issued in the past month
invoices
Security Conduct a penetration test to find Refer to security logs to find how
whether security can be bypassed many successful and thwarted
intrusion attempts were recorded.
Communication Give the solution to a typical user and Count the number of queries posted
of message test them on their understanding of it. to the help desk or website forum
relating to what the solution is trying
to say.
Reliability Pull out the power plug to see if there Refer to system logs to count how
is major data loss many times the solution has failed
over time

With software - testing would mean to ensure that the program doesn't give
any errors by looking at the internals. Evaluation occurs post-production and
deals with customers to make sure that software you develop complies with
their requirements.

Example – a company wants to increase their sales. They decide to create a fun
website to attract young people who may buy their products.
They create the website and test all of its links, menus, readability, relevance,
usability, accessibility.
They test every page in the major browsers and every test is 100% successful.
They put the website online and wait for the money to pour in.
They want to evaluate whether the site is successful in achieving their aims of
popularity and profit.
What criteria should they evaluate? Popularity with young people. Increased
profit because of the site.
So they look at the site statistics: they find large numbers of young visitors.
They find zero profit.
They realise that none of these young visitors have credit cards or Paypal.
So testing showed that the site was fully functional and 100% accurate.
The evaluation showed it was a complete failure.

In conclusion: Evaluation is not meant to prove that the

solution works. That’s the job of testing.
Evaluation is meant to measure how well the solution is meeting the user’s
needs.

Assess Test and Evaluation Plans and

Procedures
inShare

Print

Definition: Test and evaluation is the set of practices and processes used to determine if the product
under examination meets the design, if the design correctly reflects the functional requirements, and if the
product performance satisfies the usability needs of personnel in the field.

Keywords: acceptance test, integration test, operational test, peer reviews, system test

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be familiar with
different kinds of tests and know which group conducts the tests, how to evaluate test documents, and
what the developer's procedures are for test control. MITRE SEs are also expected to analyze test data.

Background
Testing is the way a product, system, or capability under development is evaluated for correctness and
robustness and is proved to meet the stated requirements. Testing is done at each stage of development
and has characteristics unique to the level of test being performed. At a macro level, testing can be
divided into developer testing conducted before the system undergoes configuration management and
testing conducted after the system undergoes configuration management. Testing done before
configuration management includes peer reviews (sometimes called human testing) and unit tests. Testing
done after configuration management includes integration test, system test, acceptance test, and
operational test. Government testing agencies normally conduct an operational test. The developer
conducts other tests; in some cases, such as an acceptance test, government observers are present.

Assessing Test and Evaluation Plans and Procedures

Assessment normally begins with the Test and Evaluation Master Plan (TEMP), which is the driver for
much of what follows. The government develops the TEMP; the developer creates detailed test plans and
procedures. The nature of the program, the life cycle, the user needs, and the user mission drive the
TEMP's scope, direction, and content. For example, testing software developed for the program is quite
different from testing systems that are largely based on, and require considerable integration of,
commercial off-the-shelf (COTS) products. The TEMP influences the testing documents that the
developer produces, but the developer's documents are largely driven by what it produces and is working
to deliver.

The government program management office (PMO) is tasked with assessing the developer's test and
evaluation plans and procedures. Often MITRE plays a central role in helping the PMO perform this
assessment. The requirements on which the developer's test plans and procedures are based must be well
crafted. A valid requirement is one that is measurable and testable. If it is not measurable and testable, it
is a poor requirement. Developer test plans and procedures should be based on the functional
requirements, not on the software design. Both the test community within the developer organization and
the development community should base their products on the functional requirements.

Assessing the developer's test plans and procedures should focus on the purpose of the test—that is, to
assess the correctness and robustness of the product, system, or service. The tests should first prove that
the product can do what it is intended to do and second that it can withstand anomalous conditions that
may arise. This second point requires particular care because there are huge differences in how robustness
is validated in a COTS-based system versus software developed for a real-time embedded system. The
environment in many COTS-based business systems can be tightly bound. A name or address field can be
limited in terms of acceptable characters and field length. In a real-time embedded system, you know
what the software expects to receive if all is going as it should, but you do not always know what possible
input data might actually arrive, which can vary in terms of data type, data rate, and so on. Denial-of-
service attacks often try to overwhelm a system with data, and the developer's skill in building into the
system a robustness that allows it to handle data it is not intended to process has a great deal to do with
the eventual reliability and availability of the delivered product. It is not unusual for the error protection
logic in complex government systems to be as large as, or larger than, the operational software.

Assessment of the test plans and procedures must take all of these issues into account. The assessor must
understand the nature and purpose of the system and the kind of software involved, and the assessor must
have the experience to examine the test plans and procedures to ensure they do an appropriate job of
verifying that the software functions as intended. The assessor must also verify that, when faced with
anomalous data conditions, the software will respond and deal with the situation without crashing. The
test conditions in the test plans and procedures should present a wide variety of data conditions and record
the responses.

For software systems, especially real-time systems, it is impossible to test all possible paths through the
software, but it should be possible to test all independent paths to ensure that the tests exercise all
segments of the software. There are software tools to facilitate this, such as the McCabe suite that will
identify paths as well as the test conditions needed to put into a test case. However it is accomplished, this
level of rigor is necessary to ensure the requisite reliability has been built into the software.

Unlike the unit test, the integration test plans and procedures focus on the interfaces between program
elements. These tests must verify that the data being passed between program elements will allow the
elements to function as intended, while also ensuring that anomalous data conditions are dealt with at
their entry point and not passed to other programs within the system. The assessor must pay particular
attention to this when assessing the integration test plans and procedures. These tests must be driven by
the functional requirements because those drive what the software must do in order for the sponsor to
accept the system.

Test and Evaluation Phases

Pre-Configuration Management Testing

The two primary test practices conducted prior to configuration management are:

 Peer Reviews: Peer reviews are performed to find as many errors as possible in the software
before the product enters the integration test. Peer reviews are one of the key performance
activities at Level 3 of the Software Engineering Institute's (SEI) Capability Maturity Model. The
SEI accepts two kinds of peer reviews:
o Software inspections (SEI preference)—have a well-defined process understood
throughout the industry. Done properly, they can remove as much as 87 percent of the
life-cycle errors in software. (They are sometimes called Fagan Inspections after their
developer, Mike Fagan.)
o Code walkthroughs—have no standard process. They can have widely differing levels of
rigor and effectiveness and at best will remove about 60 percent of the errors in software.
 Unit Test: The developer conducts the unit test, typically on the individual modules under
development. The unit test often requires the use of drivers and stubs because other modules,
which are the source of input data or receive the output of the module being tested, are not ready
for test.

Post-Configuration Management Testing

Testing conducted after the product is placed under developer configuration control includes all testing
beyond unit test. Once the system is under configuration management, a problem discovered during
testing is recorded as a trouble report. This testing phase becomes progressively more expensive because
it involves integrating more and more modules and functional units as they become available; the system
therefore becomes increasingly more complex. Each test requires a documented test plan and procedure,
and each problem encountered is recorded on a trouble report. Each proposed fix must be validated
against the test procedure during which it was discovered and must also verify that the code inserted to
correct the problem does not cause another problem elsewhere. With each change made to respond to a
problem, the associated documentation must be upgraded, the fix must be documented as part of the
configuration management process, and the fix must be included in the next system build so that testing is
not conducted with patches. The longer it takes to find a problem, the more rework is likely, and the more
impact the fix may have on other system modules; therefore, the expense can continue to increase. Thus
performing good peer reviews and unit tests is very important.

 Integration Test: This is a developer test that is successively more complex. It begins by
integrating the component parts, which are either the modules that have completed the unit test or
COTS products, to form functional elements. The integration test progresses from integration of
modules to form entire functional elements, to integration between functional elements, to
software-hardware integration testing. Modeling and simulation are often used to provide an
operational-like testing environment. An integration test is driven by an integration test plan and a
set of integration test procedures. Typically an integration test will have embedded within it a
subset of tests identified as regression tests, which are conducted following a system build. Their
objective is to verify that the build process did not create a serious problem that would prevent
the system from being properly tested. Often regression tests can be automated.
 Test Data Analysis: When conducting peer reviews, unit tests, integration testing, and system
tests, a significant amount of data is collected and metric analysis is conducted to show the
condition state of the system. Significant metric data is produced related to defect density, pass-
fail data on test procedures, error trend analysis, etc. MITRE SEs should be familiar with test
metrics and evaluate the test results to determine the likelihood that the system can meet the
requirements of performance delivered on time and within budget.
 System Test: This is an operational-like test of the entire system being developed. Following a
successful system test, a determination is made as to whether the system is ready for acceptance
test. After the completed system test and before the acceptance test, a test readiness review (TRR)
may be conducted to assess the readiness of the system to enter the acceptance test.
 Acceptance Test: Witnessed by the government, this is the last test before the government
formally accepts the system. Similar to the system test, the acceptance test is often a subset of the
procedures run during system test.
 Operational Test: Performed by an operational unit of the government, this is the final test
before the system is declared ready for general distribution to the field.

Best Practices and Lessons Learned

Examine the reports on the pre-configuration management tests. Examine these reports to evaluate
the error density information and determine the expected failure rates that should be encountered during
subsequent test periods.

Review the peer review and unit test results prior to the start of integration testing. Due to the
expense and time needed to correct problems discovered in the post-configuration management tests, SEs
should understand how thorough the prior tests were and whether there is a hint of any issues that need to
be addressed before the integration test starts. If peer reviews and unit tests are done properly, the error
density trend data during the integration test should show an error density of 0.2 to 1.2 defects per 1,000
source lines of code.

Consider modeling and simulation options. These could support or substitute for some aspects of
integration that are either of lower risk or extremely expensive or complex to perform with the actual
system.
Complete a thorough independent review of the test results to date prior to supporting the
TRR. This is especially true for performance or design areas deemed to be of the greatest risk during the
design phase. After the TRR is passed and the program enters acceptance testing, correcting problems is
extremely expensive and time consuming.

Involve the government Responsible Test Organization (RTO) early. Involve the RTO (during the
concept development phase is not too early) so they understand the programmatic and technical issues on
the program. Including the RTO as part of the team with the acquisition and engineering organizations
will lessen conflicts between the acquisition organization and RTO due to lack of communication and
misunderstanding of objectives.

Dispute Resolution - Construction Contracts

Introduction
Over the years there has been much research in the subject of dispute resolution. This literature review aims to analyse the
applicability of informal mediation, partnering and framework agreements to avoid disputes. Over the last few years there
is little information to suggest whether the methods are still as pertinent. However, regardless of the issue, the critical
review will analyse other literature in order to support this argument.
In order to attain the aims and objectives of this dissertation the critical literature review will evaluate a number of issues
surrounding dispute resolution and avoidance methods. The literature review has therefore been broken down into the
following sections:
2.2 Conflict & Disputes
2.3 An introduction to alternative dispute resolution
2.4 The applicability of mediation
2.5 Disputes in traditional & partnering based contracts
2.6 An introduction to construction alliances
2.6 Partnering: reducing the incidence of disputes
2.7 Framework agreements

2.2 Conflict & Disputes

A “conflict" is heavily based on when two or more parties lack commonality and they each have a different agenda. An
individual is indefinitely in conflict when a party is asked to pay and the other party refuses. Brown and Marriot (1993)
offer many variations in relation to disputes. They believe that there are many factors which can influence parties to
disagree and not only of them can be amendable in the dispute resolution process. As Mackie (1991, pg 27) points out
“that the nature of the dispute is important, certain matters being better left to the courts".
Most people probably do not realise there is a difference between the term “conflict" and “dispute". However, academics
in construction do draw a variation between the two meanings. Disputes are generally “short-term" difference of opinions
that can be resolved through negotiations and mediation etc whereas conflicts are typically long-term non-negotiable
issues that are opposed to dispute resolution. See diagram 2.2.1

Diagram 2.1.1
.
Disputes are inevitable in construction projects. Skills in dispute resolution should be part of the resources of any
professional in a managerial position. There are various dispute resolution mechanisms and procedures such as litigation,
negotiation, meditation, arbitration and adjudication. With consideration to the main features and characteristics it can be
determined which dispute resolution strategy should be adopted after deliberation of the nature of the dispute.

2.3 Introduction To ADR

Alternative dispute resolution (ADR) is a collective term describing dispute resolution strategies and may be defined as a
range of procedures which serve as alternatives to the legal procedures of litigation and UK adjudication. Brown and
Marriot (1993). Often these are described as ‘flexible’ because strict regulation and legal rules are not applied. Simplified,
the outcome of the dispute more than likely lies in the neutral’s ability to analyse the facts of a case and provide
constructive solutions. In order for this to be carried out, the neutral party will require professional training, experience,
good communication skills. In litigation, the contents and strategies involved are highly regulated by the law, and
therefore flexibility is somewhat compromised.
According to Mackie (1991), alternative dispute resolution is a more efficient way to divert many types of cases from
ordinary litigation, to cheaper, quicker and more efficient “alternatives".
In November 1990 the Centre for Effective Dispute Resolution (CEDR), a non profit making body was set up with the
support of the Confederation of British Industry (CBI) to promote knowledge and use of ADR processes to resolve
commercial disputes in the UK. In the period which has followed the launch, the growth of ADR in the UK has been
steady with a particularly rapid increase in the last five years. The CEDR now report that a total claims value of over
£4billion have been referred to them from a wide range of industry sectors, with the construction industry one of the
largest users being responsible for 6% of the total number of mediations. CEDR (Online).
The use of ADR requires the appointment of a neutral, who does not necessarily have to be a lawyer. Lawyers will often
base their opinion on what the law dictates and the previous decisions made by the courts without taking full consideration
of the situation for individual disputes. This is important as the requirement of the neutral is not to interpret and make
judgements that pertain to the law, but to bring the parties together in order to reach an acceptable agreement even if it
does not conform to previous judgements made. CEDR (Online).
The four main types of ADR are:
Negotiation
Mediation
Adjudication
Arbitration

2.3.1 Negotiation
Negotiation has been defined as “the process we use to satisfy our needs when someone else controls what we want". It is
the most common form of dispute resolution. Brown and Marriot (1993). It forms an important part of everyday life not
only for lawyers but also for all people. It is based on informal discussions, speedy and economical way or resolving
disputes that are not complex in nature. Due to its simplicity, negotiation is often used by the parties as a 1st option before
considering alternative means of dispute resolution or more formal strategies.
Negotiation is also a form of ADR. For negotiation to be successful it is important for both parties to be willing to reach an
amicable agreement, which both parties feel is acceptable and once the process is complete the parties should feel that the
outcome has been beneficial. Mackie (1991).
Bingham (online) illustrates that negotiation is voluntary in the sense that negotiations can be broken off at any time by
simply refusing to continue, and no one can coerce a reluctant party to negotiate. This makes negotiation non-
determinative, as there is no guarantee that it will end with a mutual agreement that resolves the matter at hand.
There are many great benefits of negotiation, from the parties point of view, are firstly that the parties can do it on their
own, thus minimising costs, and secondly they retain control of how the dispute is resolved.
There may be different reasons for entering into negotiation. One may be due to the need to resolve a problematic area
which is accepted by the other party with a degree of understanding, which can then be resolved; this allows the parties to
retain mutual trust. There is also the opportunity for negotiations, which may be based on financial gain, the change of
specification or a change of the contract. Brown and Marriot (1993, pg 89) believe that “the problem solving approach to
negotiation is very helpful to ADR practice".
Before the negotiation process commences each party should know where their strengths and weaknesses lie. Once this
has been identified the others parties position should be evaluated and both arguments compared. This will determine how
the negotiation will proceed, if both parties have the same desire to settle and what the final outcome will be.
Both parties will leave the negotiation with a particular sense of the outcome of the event whether it is positive or
negative. The timing of the negotiation in relation to the project can also be significant in the future relations between the
parties.
It is important that both parties in the negotiation process have all relevant information available to refer to at negotiation
meetings. During negotiation both parties should be clear on their stance with relation to the dispute, stating it clearly and
concisely. This should include explaining the situation and how it arose as well as its affect on the party. The other party
should then provide a response.
Once this is complete the area of contention should be discussed by both parties and any areas of agreement identified. In
the event that neither party is able to reach an acceptable agreement, it is important that the reason for the failure to
negotiate is assessed, in order to pave the way to an amicable solution which satisfies both parties’ requirements.
For a negotiation to be successful the representatives of both parties should have a detailed understanding of the project
and allow for sufficient preparation of the case. Also positions of the party should be made clear and reasonable, with the
aim of ensuring mutual respect. Trust is also necessary for the process to succeed, with a willingness to negotiate, each
party should be able to speak with experience and know the intricate details of the dispute. Brown and Marriot (1993).

Mediation
Mediation is a structured form of ADR, with one respective from each parties side meeting with a mediator to resolve the
dispute. Mackie (1991, pg 87) defines mediation as the “intervention by a third party to assist disputing parties to reach a
settlement".
It is a voluntary, non-binding process in which a neutral party, known as a mediator, helps to guide the parties towards a
mutually beneficial resolution. The mediator plays a facultative role (see diagram below) in the resolution process by
assisting the parties to decide for themselves whether to settle and on what terms. A mediator does not impose a decision
or attempt to judge the case. The mediator’s skills help the parties to move away from trying to demonstrate that they are
‘right’ instead the emphasis is placed on the resolution of the problem. The mediator helps the parties to achieve a
settlement by focusing on what is to be done rather that pointing the blame. Bingham (online).
Mediation gives parties involved much more control over the way their dispute or difference of opinion is dealt with and
over the outcome. If negotiation as previously mentioned has failed, mediation provides alternative to pursuing litigation
etc. The scope for solutions is usually greater than the solutions available in courts and tribunals, or even prolonged
negotiation.

Adjudication
Similarly to ADR, Adjudication is a process of decision making which involves a neutral third party. The neutral has the
authority to determine a binding resolution through some form of judgement or award. Adjudication is commonly carried
out in the form of the court system. Brown and Marriot (1993). Although binding, but not necessarily final outcome to
disputes on construction contracts. It is mainly for disputes that will otherwise hold up cash flow, by obtaining a quick
decision by an impartial third party while the contract is in progress.
Court based Adjudication is found to be significantly more formal than arbitration and the ADR process which may be
used in the settlement of a dispute. Adjudication is not a voluntary process; each party presents their case which results in
a final win lose outcome. Once the Adjudication process commences both parties are obligated by law to participate in the
proceedings. If the case does go to trial each side must present evidence to support their argument and cause for dispute.
Once the evidence of each party has been presented, a judge or jury will then make their decision based on the cases
presented from both parties. Once a decision has been made the losing party has the right of appeal which may be filed and
taken to a higher court. Mackie (1991).
Construction generally offers its clients great flexibility. Changes are inevitable therefore there will be changes in price
and programme. This makes for disputes and if it is not efficiently managed it reduces itself to conflict. All other aspects
in the project will suffer. The adjudicator will quickly identify dodgy claims and the project will not be damaged with poor
relations.
Adjudication offers many advantages including the following:-
Cost Efficient - The parties split the cost of a highly credentialed Adjudicator who efficiently decides the dispute after
zealously researching the law and facts with the assistance of an expert legal staff. Intelligent Justice informs the parties of
the total cost at the very beginning of the process and payment is made through capped monthly installments.
Time reduced - Adjudication will commence immediately with an analysis of the applicable legal authorities and
identification of the evidence that supports the positions of each party to the dispute. The Adjudicator will promptly
examine material witnesses under oath in the locations where they are found. There is no need to repeat the process years
later in an expensive trial.
Adjudicators Experience –The parties jointly approve the selection of their Adjudicator in advance, Intelligent Justice
eliminates the risk and uncertainty that occurs when judges and jurors with unknown qualifications, backgrounds, biases
and abilities are used to decide complex legal disputes in the public court system.
Enforceable - When the adjudication is completed the verdict may be quickly confirmed as an enforceable court judgment
or appealed as permitted by the parties' agreement and applicable law. Brown and Marriot (1993).

Arbitration
Arbitration is a procedure for the settlement of disputes under which the resultant disputants agree to be bound by the
decision of an arbitrator who decision is final and enforced by the law.
Arbitration is a voluntary, binding alternative to court litigation. It is a consensual process based on an agreement between
parties to submit their disputes to an independent person or tribunal for final verdict of the disagreement between the two
parties.
MacRoberts, (2008) states “An arbitration has been defined as the method of procedure by which parties who are in
dispute with each other agree to submit their dispute to the decision of one or more persons, traditionally in Scotland
described as ‘arbiters’, rather than resort to the courts of law."
In Scotland arbitration has played a pivotal role in settling disputes and as a result Scotland has its own highly regarded
and developed body of arbitration law. The Scottish courts have always recognised the right of parties to agree to exclude
the jurisdiction of the courts to inquire into the merits of their disputes and instead to refer any disputes to arbitration.
Traditionally, the means of conflict resolution have been very simple. Construction disputes were resolved by arbitration.
Arbitration could have been regarded as the primary provisional response when in need of a conflict or dispute resolution.
The main purpose of arbitration was to avoid the flaws that litigation along with the court based proceedings had.
Arbitration became popular widely but in recent times has fell into the same bracket as litigation. Brooker & Lavers
(1997). According to Flood and Caiger (1993) arbitration is likely to lead to delays and high costs. The imitation of legal
procedures According to Flood and Caiger (1993) is described as the “jurisdication of arbitration".
According to Brown and Marriot (1993), there are many differences between Arbitration and the “alternatives". Firstly
mediation and negotiation is are both consensual and rest on agreement, similar to arbitration, however arbitration is more
legalistic and enforced by the courts whereas agreements in the ADR process will not be.

2.4 The Applicability Of Mediation

As this review has previously established, mediation is usually one of the first stages of the legal process. However the
main questions the author seeks to answer are firstly when a dispute arises, is mediation today currently the first choice
and how many disputes under the legal process even now go to mediation? And secondly is mediation the best way to
solve disputes?

Strategic Alliances
Alliances In Construction: An Introduction
In the construction industry various forms of alliances are now being offered such as a series of major long term
construction commitments and opportunities. There are various forms of strategic alliances such as partnering and joint
ventures which have allowed separate companies to co-operate in developing new projects. The structure for such schemes
is simple its is wholly based on a risk/award structure i.e. each company sharing each other’s “pain and gain" during the
course of the project. Ngowi and Pienaar (2005). Ingirige and Sexton (2006) point out that alliances on the whole provide
opportunities for individuals and groups to gain mutual benefits such as reducing uncertainties, the product of such benefit
is now providing the concept of alliancing in the construction industry an increased momentum.
Harris and McCaffer (2001) concur with this idea stating that the construction and design team prepare targets and
objectives united to a structure which includes the risks and rewards based on the final outcome. The suggestion being that
further collaborations will be readily available if the final outcome meets the client’s approval.
According to Ngowi and Pienaar (2005) there are many reasons as to why firms form an alliance. Not only do they
provide pulling together the costs and risks they can also “trim product and service development times, penetrate new
markets, and gain access to new technologies and economics of scale." Ngowi and Pienaar (2005, p 268).
Alliances are loosely based on the important factor of trust, something which in practice should alleviate common
conflicts. Coleman (1990, p 78) illustrates trust as “committing to an exchange before you know how the other person will
reciprocate". The foundations of trust being confidence and dependence. Sabel (1993) as cited in Ngowi and Pienaar
(2005, p 268) puts it more pithily believing it be defined as “the mutual confidence that no party to an exchange will
exploit another’s vulnerabilities".
Ultimately the main characteristics of alliances are the combination of cooperation and competition. This combination of
joint reliance between the partners with elements of conflict can add risk and caution to the cooperation. This can be
overcome by the primary factor of trust as illustrated above by Coleman (1990) and Sabel (1993). The trust between
partners helps overcome this threat.
Harris and McCaffer (2004) makes it clear that originally partnering is primarily regarded as the standard form of strategic
alliancing. This form of construction alliance usually provides a long-term commitment between partners to work together
on a series of projects or developments. Fryer(2006) makes it clear that partnering as a process is fully and completely
aimed at prevention prior to a dispute evolving and one of the benefits attributable to partnering is reduced exposure to
litigation through issues being resolved through strategies and communication.

Partnering
For a number of years now partnering has become one of the most practical concepts in dispute avoidance. Fryer (2004)
illustrates that the increased promotion of partnering between the design and construction teams in the industry has
displayed effective tactics for profitability and cost effectiveness.
Egan’s report “Rethinking Construction" in 1998 contained promising developments in Section 12 of the report which
demonstrated “tools" to tackle fragmentation between parties. This was the idea of partnering and framework agreements
which at the time were picking up increased popularity by firms as a substitute for traditional contract based procurement
and project management. The main aspect for this was the opportunity for parties to share in the rewards of improved
performance. The report’s definition of partnering is as follows:
“Partnering involves two or more organisations working together to improve performance through agreeing mutual
objectives, devising a way for resolving any disputes and commiting themselves to continous improvement, measuring
progress and sharing gains".
The aspect of a partnering approach provides a harmonious agreement from the outset. The structure of which purely
focuses on co-operation and teamwork to avoid adversarial confrontation. Fryer (2004) supports this view further by
providing the view that partnering is increasingly becoming acknowledged as a way of addressing the industry’s
fragmentation and confrontation. Harris and McCaffer (2001) believes the way partnering reduces disputes is based on the
fact that problems can be foreseen and mutually resolved i.e disputes and claims. Fryer (2009) concludes that there are
three core principles providing the foundation for the partnering relationship: good communications, commitments and
conflict avoidance and resolution.
Gardiner (2005, p 152) states that “fostering of a mutual interdependence and trust rather than a blame culture" is
fundamentally the concept of the strategy. It is also a methodology for avoiding and resolving disputes, mitigation of
conflict and avoiding litigation.

Framework Agreements
A framework agreement is a general document which suits long-term collaborations between two parties or organisations.
Framework agreements are loosely based on an “umbrella" agreement in which the parties enter into a number of specific
contracts. Harris and McCaffer (2001).
Barr construction currently have numerous framework agreements in place in the retail industry with Tesco stores. The
agreement itself has according to Barr (Online) has resulted in over forty project with the retailer. The main reason
companies such as Barr will enter into framework agreements is to exchange innovations, reduce tendering from project to
project and ultimately improve costs. Fryer (2004).
The framework agreement established and was recommended in Sir John Egan’s report “Re-thinking Construction" and
“Accelerating Change". The JCT contract also contains a JCT 2005 Framework Agreement whereby it is understood that
through the encouragement of collaboration, the main objectives include team working and consideration of others and
also the avoidance of disputes. JCT (2005) acknowledges that “frameworking arrangements are really only likely to pay
dividends on larger, lengthier projects which give the project participants the opportunity and incentive to invest in people,
processes and products and develop as a team".
Klimt (2005) explains that in 2005 the Joint Contracts Tribunal published two versions of the Framework Agreement,
binding and non-binding. These framework agreements are based around the concept of replacing blame with cooperation.
The main purpose being providing “best practice". He explains that traditional contracts in the past have been poor and
impractical in dealing with problems and therefore they have festered unresolved and become more complex. The
Framework Agreement has been published so that identification of problems is early on and resolved. Any disputes or
conflict is recorded on a form. If the problem cannot be resolved it is passed up to the next hierarchical level. If the dispute
is still not resolved then formal dispute resolution procedures will be implemented as outlined in the Project Specific
Order.

Conclusion
This literature review has provided an extensive analysis into the main methods of dispute resolution and avoidance which
are currently available in the construction industry. This conflict resolution procedure is useful for both researchers and
practitioners to better deal with the dispute-prone nature of the construction industry.It would not be a mistake to conclude
that disputes are inevitable in any project and whether it should be resolved at the time through ADR or avoided
completely through Strategic alliances is determined by the scope of the project itself. In recent times negotiation,
mediation, arbitration and adjudication have provided professionals with a procedure which could prevent individuals
from the more formal hearings of litigation.
The literature review also examined the use of strategic alliances in today’s industry. In a construction alliance, there are
cooperation aspects between the parties involved. The study intended to determine the applicability of such alliances in
preventing disputes and conflict through the foundations of long-term commitments and collaborations. Partnering has
long been a proven method of avoiding conflict through the basis of mutual trust and the idea of sharing each other’s “pain
and gain" through the lifespan of their partnership. The author has also studied the use of framework agreements in the
construction industry. It is evident that framework agreements providing yet-again long term collaborations between
parties. The use of framework agreements in retail is immensely popular in today’s industry due to the concept being
loosely based on providing “best practice". Such purposes have allowed framework agreements to replace blame and the
natural “pointing the finger" notion with cooperation and understanding.

Contracts & Dispute Resolution

This group appoints adjudicators and arbitrators.

Adjudication is a simple and inexpensive way of resolving disputes between two parties, which appoints a neutral third party to
investigate the issues and make a decision. We have led the industry move towards adjudication, rather than more costly forms of
litigation, working with other institutions and bodies to set criteria to ensure high standards of competency in adjudicators.

We will identify and appoint the appropriate adjudicator for the particular case, for which we charge a fee of £300.

Arbitration is a more complex procedure, preferred by some for dispute resolution. The Arbitration Act 1996 aimed to address
some of the weakness in this method, giving the arbitrator new powers to speed up the process and save costs.

For a fee of £300, we will appoint an arbitrator who will have the qualifications and experience to arbitrate the matter at hand.

Why Your Contracts Need a

Dispute Resolution Clause
8th November 2016

Share on Facebook

Tweet on Twitter

It is very likely that you have a good relationship

with your clients: they – like you – do their jobs
well, run their businesses well, and go the extra mile
to impress you with their services.
However, it would be remiss to believe that every client you enter into a contract with
will deliver exactly what you expect. In fact, although you may not like to think about it
when you sign a deal with someone new, it is a commercial reality that parties
sometimes disagree – and, if you don’t have a means of dealing with this, it can have
disastrous effects for your business.
Read on to discover why it is imperative to include a dispute resolution clause in all
contracts – and claim a free template that will protect you in a matter of seconds.

What is a dispute resolution clause?

A dispute resolution clause specifies how the parties to a contract will resolve any
questions, misunderstandings, or differences that arise in a fair and agreeable way. It is
essentially a set of guidelines that govern how you and your contracting parties will
settle a potential issue, should something go wrong. Determining what approaches and
processes you will use in such a situation – and drafting these into your contracts – is
highly recommended, and at the start of your relationship too; after all, cool heads and
cooperation make a much better foundation for discussion than the stress and tension
of a dispute situation.

Why is a dispute resolution clause needed?

Though no-one enters into a new agreement expecting issues, all contracts should
contain a dispute resolution clause as a matter of course, just in case. These guidelines
act a bit like a plaster should something need patching up, not only helping to preserve
your business relationship, but also saving you the time and expense associated with
court proceedings. Indeed, a dispute resolution clause will help you to keep a level head
if problems do arise, giving you a clear and considered course of action with which to
deal with the issue. As a result, disputes are likely to be resolved more quickly, cost-
effectively, and in an informal – and amicable – manner, helping you to restore your
relationships and get back to running your business.

How does dispute resolution work?

There are four methods of dispute resolution to choose from, and it’s best to determine
which suits you and your clients at the outset of your contract:

Litigation: This is a traditional method of dispute resolution in which an aggrieved

party files a lawsuit, hires a solicitor, and handles the discussions in a courtroom. It is
formal, expensive, and leaves the decision in the hands of a third party (the court).
Most dispute resolution clauses are drafted with the aim of avoiding litigation.

Negotiation: This is the least costly, and most informal, method of dispute resolution,
allowing the outcome to be agreed upon by the contracting parties themselves. A
lawyer is not required, but it does necessitate both parties entering into discussions
willingly.

Mediation: This is a halfway house between litigation and negotiation. A mediator,

usually a solicitor, is selected to help the parties reach an agreeable resolution, but it is
down to the latter to reach a final outcome themselves. It is less costly and less formal
than litigation, but also non-binding.

Arbitration: This is a more structured method of dispute resolution than negotiation

and mediation, but also a faster, simpler, more efficient, and more cost-effective
process than litigation. It results in a binding, enforceable outcome, overseen by a
lawyer, without any of the hostilities (or drama) of the courtroom. It also gives parties
the option of selecting a solicitor who has technical knowledge in their field, rather than
relying on a judge who may not be familiar with the specific issues.

How do I decide the best form of dispute resolution?

You should determine which form of dispute resolution suits you and your clients best
before you sign a contract with them. Think about whether you want a formal or
informal environment in which to resolve any issues, whether you want to try and keep
the business relationship intact, and whether you want control over the final decision or
if you’d prefer to leave it in the hands of a third party. There’s also the small matter of
costs and timescales to consider; certainly, Ajuve’s arbitration experts would always
recommend starting with the least costly, least time-consuming, and least
confrontational methods first.

What makes an effective dispute resolution clause?

To be effective – or, in legal terms, enforceable – a dispute resolution clause must be
clear, unambiguous, and set out a specific process for both parties to follow. It must
not attempt to prevent parties from commencing court proceedings, however it should
set out an alternative dispute resolution process that will take place before any formal
court action commences. If it fails to provide a clear path via which parties can finalise
their dispute, it risks being rendered void for uncertainty.

A dispute resolution clause will typically include the following guidelines:

 How the aggrieved party will provide notice to the other party about the nature
of the dispute.
 How the parties will commence dispute resolution, such as a formal meeting to
discuss the disagreement and attempt to negotiate a resolution.
 How the parties will continue dispute resolution, if required. The clause should
outline who will act as the mediator or arbitrator, any guidelines as to how
mediation or arbitration will be conducted, and how any costs will be covered.
 How to determine when the alternative dispute resolution has come to an end,
and formal litigation is needed to begin.
 What jurisdiction any such litigation should be commenced in.

The Ajuve arbitration clause: your free dispute resolution

template
If a dispute resolution clause is not drafted with skill and due diligence, it can be
purposeless. Fortunately, Ajuve’s team of expert arbitrators have done the hard work
for you and written a legally sound, internationally-binding clause that can be included
in all your contracts to cover any dispute resolution requirements. Simply add the
following template to all your existing and future contracts and feel safe in the
knowledge that, if the worst comes to the worst, you’ll be able to reconcile any
problems with Ajuve’s unique online arbitration platform – providing fast, simple, and
cost-effective dispute resolution at your convenience.

The Ajuve arbitration clause is completely free until you have a dispute. Just
copy and paste the following into all your contracts:
This agreement shall be governed by and will be construed in accordance with English
Law. The Parties agree to refer all disputes and differences of any kind (including any
dispute regarding the existence of this agreement) to the Ajuve Dispute Resolution
Rules which shall be read and construed as if set out in full herein. A full copy of those
rules is available at http://ajuve.com/dispute-resolution-rules.

United States: International Contract Dispute

Resolution - It Pays To Plan Ahead
Last Updated: June 6 2013

Article by Michael B. Tule

The McLane Law Firm

Your LinkedIn
Connections at Firm

Published in New Hampshire Business Review

Making the decision to take your New Hampshire-based business international is a big step. You’ve found
the right partner, and now you are ready to embark on your international venture. But the long term health
of your international business relationships may depend on how well you plan ahead for trouble. While
deal-making may be the initial priority, providing for dispute resolution when trouble occurs should be just
as important.

Don’t overlook the simple things. Make sure that your international business relationships are
documented with a carefully drawn contract drafted with the help of an experienced lawyer. Moreover, all
international commercial contracts should, as a matter of course, have a dispute resolution clause that
includes an effective agreement to arbitrate.

Why Arbitrate?

Arbitration is the most widely used method of alternative dispute resolution. It is similar in process to a
court, but is private and generally less formal. Like litigation in courts, it is expensive, time consuming,
and distracting. But for most international disputes, there is no satisfactory substitute. There are two
major reasons for this. First, agreeing to arbitrate assures that your dispute will be heard in a neutral
forum, instead of the other party’s home court, where you may face a biased judge and an unfamiliar
language. Second, with arbitration you have a far better chance at having a judgment or award enforced.
Enforcing the judgment of a court (even a U.S. court) in another country isn’t a sure thing. International
arbitration is different. Under a multinational treaty known as the “New York Convention,” 142 signatory
countries have agreed to recognize and enforce foreign arbitration awards. There is no comparable treaty
governing the judgments of U.S. or foreign courts. Therefore, it is almost always to your advantage to
agree to arbitration when you are contracting with an overseas party, provided that each party is located
in a country, or has assets in a country, which is a signatory to the New York Convention. If you are
dealing with a party who is not located in a country that has signed the New York Convention, you must
proceed with extreme caution and take additional measures to protect yourself. Consult an experienced
attorney in such a case.

Arbitration Agreement Essentials

When beginning a commercial relationship, dispute resolution is often the last thing on everyone’s minds.
A principal decision maker might treat the arbitration clause as “boilerplate” and never give it a second
thought. But you ignore it at your peril. You must craft the arbitration clause to fit your business objectives
and accommodate the unique circumstances of your particular deal. Poorly drafted arbitration clauses
pose many dangers, and clever defendants can exploit an imprecise arbitration clause to delay or
completely avoid arbitration.

With that in mind, there are several essentials of any well-drafted arbitration agreement. These essentials
include the scope of the dispute, exclusivity, number of arbitrators, language of the arbitration (English, if
at all possible) and applicable substantive law, among others. In addition, every arbitration clause should
contain a provision referring to and incorporating the rules of a specific arbitration organization to govern
the arbitration. There are perhaps a half dozen pre-eminent arbitration organizations in the world. They
include the International Chamber of Commerce (“ICC”), the London Court of International Arbitration
(“LCIA”), the International Centre for Dispute Resolution or “ICDR”, the Stockholm Chamber of
Commerce (“SCC”) or the Singapore International Arbitration Centre (“SIAC”), among others. All of these
organizations are reputable, but experienced lawyers often recommend using the ICC as the arbitration
administrator in international disputes. It is generally believed that the ICC, although expensive, is the
most widely recognized organization and has the best panel of arbitrators to choose from. In some
situations, you may want to use an organization like the LCIA or the ICDR, which charge a fixed fee for
the arbitration versus a percentage of the claim, like the ICC. It is possible to draft an “ad hoc” arbitration
clause, which calls for the arbitration to he held privately between the parties, without the rules or
administrative oversight of an arbitral organization, but this is generally not recommended.

One of the most important decisions to make is designating the place of arbitration. Generally speaking,
the parties try to pick a place that is neutral. You should take care to choose a country that has a well-
developed body of arbitration law and a modern arbitration statute. The most reliable (and popular)
places of arbitration are London, Paris, Geneva, Zurich, Stockholm, the Hague, New York, Los Angeles,
Toronto, Rome, Brussels, Singapore, and Bermuda.

There are other provisions you may consider other than the essentials listed above. In deciding whether
to include such provisions, you and your lawyer should give a great deal of thought to whether such
provisions are necessary and/or whether they may provide strategic advantage in the context of your
deal. Examples of such other provisions include designating special qualifications of the arbitrators,
nationality of the arbitrators, special discovery procedures, limitations on types of damages, deadlines
and time limits, special summary disposition procedures, shifting costs and expenses to the losing party,
and assessing costs to collect a judgment.

Conclusion

In every international commercial contract a carefully crafted arbitration clause is a necessary part of any
process for resolving international disputes. Putting an effective dispute resolution process in place at the
beginning of the contract will avoid problems later, if the unthinkable happens.
Michael Tule is of counsel to the Corporate Department at the law firm of McLane, Graf, Raulerson &
Middleton, Professional Association.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice
should be sought about your specific circumstances.

Quality Assurance vs Quality

Control – What is the
Difference?
The most frequently asked question Quality
Assurance vs Quality Control:
What is Quality?
Quality is meeting the requirement, expectation and needs
of the customer being free from defects, lacks and
substantial variants. There are standards needs to follow to
satisfy the customer requirements.

What is Assurance?
Assurance is provided by organization management, it
means giving a positive declaration on a product which
obtains confidence for the outcome. It gives a security that
the product will work without any glitches as per the
expectations or requests.

Recommended Reading => Does Quality Assurance

Remove Need for Quality Control?
What is Quality Assurance?

Quality Assurance is known as QA and focuses on

preventing defect. Quality Assurance ensures that the
approaches, techniques, methods and processes are
designed for the projects are implemented correctly.
Quality assurance activities monitor and verify that the
processes used to manage and create the deliverables have
been followed and are operative.
Quality Assurance is a proactive process and is Prevention
in nature. It recognizes flaws in the process. Quality
Assurance has to complete before Quality Control.
What is Control?

Control is to test or verify actual results by comparing it

with the defined standards.

What is Quality Control?

Quality Control is known as QC and focuses on
identifying defect. QC ensures that the approaches,
techniques, methods and processes are designed in the
project are following correctly. QC activities monitor and
verify that the project deliverables meet the defined quality
standards.
Quality Control is a reactive process and is detection in
nature.. It recognizes the defects. Quality Control has to
complete after Quality Assurance.

Difference between quality assurance and quality

control
Many people think QA and QC are same and
interchangeable but this is not true. Both are tightly linked
and sometimes it is very difficult to identify the differences.
Fact is both are related to each other but they are different
in origins. QA and QC both are part of Quality Management
however QA is focusing on preventing defect while QC is
focusing on identifying the defect.
Quality Assurance vs Quality Control
Quality Assurance Quality Control

It is a process which deliberate on QC is a process which deliberates on

providing assurance that quality fulfilling the quality request.
request will be achieved.

A QA aim is to prevent the defect. A QC aim is to identify and improve the

defects.

QA is the technique of managing the QC is method to verify the quality.

quality.

QA does not involve executing the QC always involves executing the

program. program.

All team members are responsible for Testing team is responsible for QC.
QA.

QA e.g. Verification. QC e.g. Validation.

QA means Planning for doing a process. QC Means Action for executing the
planned process.

Statistical Technique used on QA is Statistical Technique used on QC is

known as Statistical Process Control known as Statistical Quality Control
(SPC.) (SPC.)

QA makes sure you are doing the right QC makes sure the results of what
things. you’ve done are what you expected.

QA Defines standards and QC ensures that the standards are

methodologies to followed in order to
meet the customer requirements. followed while working on the product.

QA is the process to create the QC is the process to verify that

deliverables. deliverables.

QA is responsible for full software QC is responsible for software testing

development life cycle. life cycle.

Key Points
 In QA, processes are planned to evade the defects.
 QC agreements with discovery the defects and
modifying them while making the product.
 QA detects weakness.
 QC detects defects.
 QA is process oriented
 QC is product oriented.
 QA is failure prevention system.
 QC is failure detection system.

The Difference Between Quality Assurance and Quality Control

Open dialog article,
By Brett Arthur, Senior Consultant, Dialog IT.,

It is important for an organisation to agree on what the meanings

of Quality Assurance (QA) and Quality Control (QC). Both form an integral part of the organisation's
quality management plan, and the effectiveness of delivery teams relies on the differences being well
understood by all stakeholders, including management.

Effective quality systems can contribute enormously to the success of projects, but the counterpoint is
that, when poorly understood, the quality systems are likely to be weak and ineffective in ensuring that
the delivered system is delivered on time, built by the team within their allocated budget, and satisfies the
customer’s requirements.

This article considers the difference between Quality Assurance and Quality Control. The concepts are
investigated by looking at guidance from key industry players.

Introduction
How many times has it struck you that many practitioners involved in the ICT field lack an understanding
of the difference between Quality Assurance and Quality Control? Often you will hear someone talk about
‘QA’, when what they actually mean is ‘QC’.

This ambiguity consistently throws up problems and is a sure way of undermining a project. Projects are
negatively affected as it tends to lead to strained conversations and makes reaching consensus difficult.

Although QA and QC are closely related concepts, and are both aspects of quality management, they are
fundamentally different in their focus:

 QC is used to verify the quality of the output;

 QA is the process of managing for quality.

Achieving success in a project requires both QA and QC. If we only apply QA, then we have a set of
processes that can be applied to ensure great quality in our delivered solution, but the delivered solution
itself is never actually quality-checked.
Likewise, if we only focus on QC then we are simply conducting tests without any clear vision for making
our tests repeatable, for understanding and eliminating problems in testing, and for generally driving
improvement into the means we use to deliver our ICT solutions.

In either case, the delivered solution is unlikely to meet the customer expectation or satisfy the business
needs that gave rise to the project in the first place.

Understanding the Difference Between QA and QC

So, what exactly is the difference between Quality Assurance (QA) and Quality Control (QC)?

A good point of reference for understanding the difference is the ISO 9000 family of standards. These
standards relate to quality management systems and are designed to help organisations meet the needs
of customers and other stakeholders.

In terms of this standard, a quality management system is comprised of quality planning and quality
improvement activities, the establishment of a set of quality policies and objectives that will act as
guidelines within an organisation, and QA and QC.

In the ISO 9000 standard, clause 3.2.10 defines Quality Control as:
“A part of quality management focused on fulfilling quality requirements”

Clause 3.2.11 defines Quality Assurance as:

“A part of quality management focused on providing confidence that quality requirements will be
fulfilled”

These definitions lay a good foundation, but they are too broad and vague to be useful. NASA, one of the
most rigorous software engineering firms in the world, provides the following definitions
(www.hq.nasa.gov/office/codeq/software/umbrella_defs.htm):

Software Quality Control:

"The function of software quality that checks that the project follows its standards, processes,
and procedures, and that the project produces the required internal and external (deliverable)
products"

Software Quality Assurance:

"The function of software quality that assures that the standards, processes, and procedures are
appropriate for the project and are correctly implemented"

Simply put, Quality Assurance focuses on the process of quality, while Quality Control focuses on the
quality of output.

Quality Assurance: a Strategy of Prevention

QA is focused on planning, documenting and agreeing on a set of guidelines that are necessary to assure
quality. QA planning is undertaken at the beginning of a project, and draws on both software
specifications and industry or company standards. The typical outcomes of the QA planning activities are
quality plans, inspection and test plans, the selection of defect tracking tools and the training of people in
the selected methods and processes.

The purpose of QA is to prevent defects from entering into the solution in the first place. In other
words, QA is a pro-active management practice that is used to assure a stated level of quality for an IT
initiative.

Undertaking QA at the beginning of a project is a key tool to mitigate the risks that have been identified
during the specification phases. Communication plays a pivotal role in managing project risk, and is
crucial for realising effective QA. Part of any risk mitigation strategy is the clear communication of both the
risks, and their associated remedies to the team or teams involved in the project.

Quality Control: a Strategy of Detection

Quality Control, on the other hand, includes all activities that are designed to determine the level of quality
of the delivered ICT solutions. QC is a reactive means by which quality is gauged and monitored,
and QC includes all operational techniques and activities used to fulfil requirements for quality. These
techniques and activities are agreed with customers and/or stakeholders before project work is
commenced.

QC involves verification of output conformance to desired quality levels. This means that the ICT solution
is checked against customer requirements, with various checks being conducted at planned points in the
development lifecycle. Teams will use, amongst other techniques, structured walkthroughs, testing and
code inspections to ensure that the solution meets the agreed set of requirements.

Benefits of Quality Management

The benefits of a structured approach to quality management cannot be ignored.

Quality Control is used, in conjunction with the quality improvement activity, to isolate and provide
feedback on the causes of quality problems. By using this approach consistently, across projects, the
feedback mechanism works towards identifying root-cause problems, and then developing strategies to
eliminating these problems. Using this holistic approach ensures that teams achieve ever higher levels of
quality.

As a consequence of formulating and executing a quality management plan the company can expect:

 Greater levels of customer satisfaction, which will very likely result in both repeat
business, as well as referral business
 A motivated team that not only understand the policy objectives of the quality
management plan, but who also actively participate in executing the plan
 Elimination of waste by eliminating rework arising from either the need to address
bugs, or to address gaps in the solution’s ability to meet customer requirements
 Higher levels of confidence in planning, since the tasks arising from unplanned
rework will fall away
 Financial rewards for the company, which are a consequence of new projects
from existing and referral clients, as well as through the reduction of monies
spent on rework tasks.

As the company’s quality management plan matures, the confidence of all stakeholders will grow. The
company will be seen to be more effective and efficient in delivering an agreed ICT solution to clients.

Dialog Information Technology

Dialog is a Premier Google for Work Partner and Microsoft Gold Partner in Australia and New Zealand,
with over 1,200 full-time consultants and offices in all capital cities.

Dialog Information Technology provides expertise in Quality Control and Quality Assurance and services
range from strategic IT consulting through full lifecycle application development and managed application
services to long-term operational support.

Quality Assurance Is Not Quality Control

I need to get something straight: QA and QC are different.
Why must I point this out? Because programmers don't seem to get it and use these
terms interchangeably.

QA is QualityAssurance
but

QC is QualityControl
The difference is that QA is process oriented and QC is product oriented.
Testing, therefore is product oriented and thus is in the QC domain. Testing for quality
isn't assuring quality, it's controlling it.

 Quality Assurance makes sure you are doing the right things, the right
way.
 Quality Control makes sure the results of what you've done are what you
expected.

Why all the fuss?

There are lots of reasons to ensure the distinction between the two. Easily, the
ones that come to mind are:

 You'll need to know the difference for CMM or ISO-9000

 You don't want to prove you don't do QA by calling the QC testing you do
'QA'
 If you really want to scale your development process you'll need the
real QA and you won't want to confuse it with QC.

-- HillelGlazer

Please assure me that our QA team knows the right things and the right way. I'm
not even convinced they know up from down. And how did they find out the right
things and the right way for software engineering, when even AlistairCockburn is
still trying to figure it out? -- JohnFarrell
The QA team's job is to see that standards, processes, and policies (or other
governing/guiding "writ") are in place and carried out; to recommend and
implement improvements to them, and to ensure that the people that need to know
about them know about them. QA "audits" or "reviews" are intended to determine
the efficacy of these "writs."
It's often easier to understand QA by an example: In one place (a large company
with large projects) I've seen QA's role to help project managers plan their
projects -- so that the projects follow certain organizational procedures; so that
they include the required artifacts, events, and milestones; and so that the projects
know what is expected of them and when in terms of reports, reviews, and
documentation. As the project progressed, QA would conduct "checkpoints"
along the way to see where the project may be developing risks, for example
either by progressing beyond where they've got authorization to go, or where they
may have need to escalate issues to management. These checkpoints would also
be an opportunity to ensure that people who need to be involved are involved at
the right times. This approach to QA isn't one that really suits XP, but there are
easily ways to adapt such an approach to XP.

Maybe mixups like this are happening because ambiguous terms have been given
specific meanings (see: DeGeneralization).
Why would "assurance" mean process-related and "control" mean product-
related?
Because "assurance" means that you know you did everything needed to make
something that works right, while "control" means that you have no idea whether
any or all of your batch o'junk is worth anything until you examine each item.
"Just in time" production requires that you are assured your supplier is supplying
you with exactly what you need as you need it so you don't have to stop to test
each incoming item for defects. See ToyotaProductionSystem or DemingMethod.
(I plan to eventually write a book about how this revolution in manufacturing
could be applied to software.) In the case of software, QA means that you know
that the code you are making fulfills the requirements, QC is discovering that
your process of writing code was not adequate to assure that you didn't create a
lot of bugs along with your features. -- ChrisBaugh
One way to avoid confusion is to use more descriptive names: "Product-QA" and
"Process-QA".
I have always found the term "Quality Assurance" a curious choice. Why would
we want to be assured about quality (made to feel better about it) rather than have
quality ensured (guaranteed)?
Assuring quality is about confidence. It's about the *processes* by which we go
about doing what we do. Part of that is knowing that we're doing the right things
at the right time, and part of it is that we are doing them the right way. This all
should be done or known before we start working, not afterwards.

These terms have been defined for us. While it may be 'more right' to redefine
them so they're no longer 'degeneralized,' we ought to at least try to ensure
everyone has their terms straight when using them.
We may also look at the other areas in which these terms are used. 'Control' is
often a term used with statistics, and processes that can be "controlled" with
applying the analysis of the statistics. 'Control' is also an active term and has a
certain circumstantial connotation. The need to test ("control") is a function of the
circumstance of the existence of bugs or lack of confidence. Whereas 'assurance'
is a passive term with a more universal connotation. The need to "assure" is a
function of building confidence regardless of the existence of bugs and isn't just
about bugs, but of the entire effort.
The difference between QA and QC is largely one of power and control. QC is
usually as service provided to development (i.e. under the control of
development) and is responsible for providing that service. QA expects
development to provide services to it (control development) and is not
responsible for any result.
The above statement is a symptom of one of the biggest problems in the entire
software industry. People don't know what "QA" is supposed to do (as defined in
this page). As a result many that do QA, do it wrongly, and many that work with
those doing QA incorrectly wind up hating QA because of the lousy experience
they had with it.
QA, when done effectively in a project, should not even cross paths with
developers except perhaps at the highest levels of management. Or to teach new
developers the organizational processes, or teach existing developers about
changes to existing organizational processes. And then later QA may interact
with development to figure out whether the processes work and what needs to
happen to make sure they work better. QA should not be causing developers to do
any more work than they need to be doing to develop the work. In fact, most of
QA's role should occur with project managers and leaders of other disciplines
such as SCM, and QC. (In XP, the idea of SCM or a CCB, or CCA, or a QC
"group" doesn't apply in the same way, but there's still a QA role that can be
incorporated.)
Another unfortunate characteristic of poorly executed QA is that often in
organizations that don't know the first thing about QA the people assigned to QA
are rejects from other skills which simply compounds the problem. Again, I'm
talking about QA as described here... not QC.
QA ... should not even cross paths with development.
Anyone care to explain this one? What is the purpose of QA if it does not deal
with development? I'm afraid "QA as described here" leaves a lot to the
imagination.
An edit was made to the paragraph above that may clarify the intent. QA's job is
not to inspect code or run tests or test programmers' know-how. If QA is
"process" centric, QA shouldn't fit in with the work developers are doing. QA
folks should be "process" folks not "product" folks. As such, QA's job should
happen before and in the aftermath of product development, and less to do during
development. The purpose of this page is to separate QA from the concept of
"testing." A discussion of what QA (QualityAssurance) really is seems to be
brewing. Which is something this page is not a good place for. Without proper
definition, QA rightly so "leaves a lot to the imagination."
So, define it already. It is not enough to say QaIsNotQc, you need to also say
what QA is. Also, is there really some deep distinction between the two, or is this
just some nit-picking intended to preserve a QA role when none is needed?

I have to agree with the prior comment that the terms are very confusing. Even
though they are commonly used, I think we'd be much better off if they were not.
Part of the problem is that these terms were taken from manufacturing paradigms.
QA dealt with manufacturing processes, while QC inspected the manufacturing
output to verify that it was acceptable. In the manufacturing environment you
analyze, design, and implement once and then crank out many essentially
identical products. This is very different from the software environment where the
analysis, design, and implementation happen on each product, and then you start
over for the next iteration.
In a software environment, "Quality Assurance" does not assure quality. Rather,
they assure that a process is being followed, which is very different. The process,
if it's a good process, will increase the probability that there is a quality result. It
will, presumably, make sure that requirements are communicated, traced, planned
for, scheduled, etc. The "Quality Assurance" role will likely also collect metrics
that it can then use for process improvement. However, this group could do its job
and still have the organization's product be low-quality. Therefore this function
would be better termed "Process Management."
Similarly, "Quality Control" does not control quality. Rather they measure
quality, by verifying that what was implemented matches the requirements.
Certainly there's a feedback loop, as any defects will be reported and presumably
fixed, thus increasing quality. But this group doesn't really control anything. It
would thus be better termed "Requirements Verification," although I find the term
"Product Test" more concise.
Calling these functions Process Management and Product Test removes any
ambiguity or confusion. And calling them by these names does not impact your
ability to get ISO 9000 certification or achieve a CMM level. Those require
certain things to be done or documented, and require certain functions to be
executed by the organization, but absolutely do not require specific organizational
names.
-- JimSeidman
Well Said!!! -- HillelGlazer

I'm currently performing a quality assurance role on a software project. This has
been a first for me and I haven't spent a great deal of effort find out what quality
assurance is "supposed" to mean, because to me it is clear. I'm supposed to assure
the quality of the product and customer satisfaction. That doesn't mean reassuring
people that quality exists, it means stepping in wherever I see an opportunity to
 add or ensure quality. For this project it has meant a lot of things - clarifying
requirements, documenting new requirements, facilitating communication within
the development team, and yes, testing. But not just testing software, testing
requirements, testing understanding of requirements, testing the schedule, etc.
If it is difficult to define what quality assurance is or should do, perhaps part of that is
because it likely will vary from project to project. If you spend a great deal of effort
trying to apply some "this is what I'm supposed to be doing" process to a project I'd
guess a lot of your effort is going to go into dotting i's and crossing t's that could have
better been spent contributing something useful to the project. Which is not to say you
shouldn't learn QA techniques or processes, only that QA requires the ability to
analyze and respond logically to the needs of the environment and situation in which
it is being performed.

Quality Assurance is process oriented and focuses on

defect prevention, while quality control is product oriented and focuses
on defect identification.

Comparison chart
Quality Assurance versus Quality Control comparison chart

Quality Assurance Quality Control

Definition QA is a set of activities for ensuring quality QC is a set of activities for ensuring
in the processes by which products are quality in products. The activities
developed. focus on identifying defects in the
actual products produced.

Focus on QA aims to prevent defects with a focus on QC aims to identify (and correct)
the process used to make the product. It is a defects in the finished product.
proactive quality process. Quality control, therefore, is a
reactive process.

Goal The goal of QA is to improve development The goal of QC is to identify defects

and test processes so that defects do not after a product is developed and
arise when the product is being developed. before it's released.
 Quality Assurance versus Quality Control comparison chart

Quality Assurance Quality Control

How Establish a good quality management Finding & eliminating sources of
system and the assessment of its adequacy. quality problems through tools &
Periodic conformance audits of the equipment so that customer's
operations of the system. requirements are continually met.

What Prevention of quality problems through The activities or techniques used to

planned and systematic activities including achieve and maintain the product
documentation. quality, process and service.

Responsibility Everyone on the team involved in Quality control is usually

developing the product is responsible for the responsibility of a specific team
quality assurance. that tests the product for defects.

Example Verification is an example of QA Validation/Software Testing is an

example of QC

Statistical Statistical Tools & Techniques can be When statistical tools & techniques
Techniques applied in both QA & QC. When they are are applied to finished products
applied to processes (process inputs & (process outputs), they are called as
operational parameters), they are called Statistical Quality Control (SQC) &
Statistical Process Control (SPC); & it comes under QC.
becomes the part of QA.

As a tool QA is a managerial tool QC is a corrective tool

Orientation QA is process oriented QC is product oriented

Contents: Quality Assurance vs Quality Control

 1 Differences between Quality Assurance and Quality Control
o 1.1 Definitions of QA and QC
 2 Video Explaining the Differences
 3 References

Differences between Quality Assurance and Quality

Control
 Definitions of QA and QC

 Quality Assurance (QA) refers to the process used to create the deliverables, and can
be performed by a manager, client, or even a third-party reviewer. Examples of quality
assurance include process checklists, project audits and methodology and standards
development.
 Quality Control (QC) refers to quality related activities associated with the creation of
project deliverables. Quality control is used to verify that deliverables are of acceptable
quality and that they are complete and correct. Examples of quality control activities
include inspection, deliverable peer reviews and the testing process.
 Quality control is about adherence to requirements. Quality assurance is generic and
does not concern the specific requirements of the product being developed.
 Quality assurance activities are determined before production work begins and these
activities are performed while the product is being developed. In contrast, Quality
control activities are performed after the product is developed.

 WHAT ARE QUALITY

ASSURANCE AND
QUALITY CONTROL?


 By the ASQ Audit Division and J. P. Russell, editor

 Quality Glossary Definition: Quality assurance/quality control (QA/QC)
 Two terms that have many interpretations because of the multiple definitions for the
words assurance and control…. One definition of quality assurance is: all the planned and systematic
activities implemented within the quality system that can be demonstrated to provide confidence that a
product or service will fulfill requirements for quality. One definition for quality control is: the operational
techniques and activities used to fulfill requirements for quality. Often, however, “quality assurance”
and “quality control” are used interchangeably, referring to the actions performed to ensure the quality
of a product, service or process.
 What is quality management?
 Quality has been defined as fitness for use, conformance to requirements, and the pursuit of
excellence. Even though the concept of quality has existed from early times, the study and definition of
quality have been given prominence only in the last century.
 1920s: quality control. Following the Industrial Revolution and the rise of mass production, it became
important to better define and control the quality of products. Originally, the goal of quality was to
ensure that engineering requirements were met in final products. Later, as manufacturing processes
became more complex, quality developed into a discipline for controlling process variation as a means
of producing quality products.
 1950s: quality assurance and auditing. The quality profession expanded to include the quality
assurance and quality audit functions. The drivers of independent verification of quality were primarily
industries in which public health and safety were paramount.
 1980s: total quality management (TQM). Businesses realized that quality wasn’t just the domain of
products and manufacturing processes, and total quality management (TQM) principles were
 developed to include all processes in a company, including management functions and service
sectors.
 Quality management today. There have been many interpretations of what quality is, beyond the
dictionary definition of “general goodness.” Other terms describing quality include reduction of
variation, value-added, and conformance to specifications.
 ISO 9000:2015: Quality management systems—Fundamentals and vocabulary defines quality as
the “degree to which a set of inherent characteristics of an object fulfils requirements.” Simply stated,
quality is meeting customer requirements.
 A system of quality management includes all activities of the overall management function that
determine the quality policy, objectives, and responsibilities and their implementation. As ISO 9000
explains, a management system provides the means of establishing a policy and objectives and the
means to achieve those objectives.
 Difference between quality assurance and quality control
 Quality assurance and quality control are two aspects of quality management. While some quality
assurance and quality control activities are interrelated, the two are defined differently.
 According to ISO 9000:2015: Quality management systems—Fundamentals and vocabulary:
 Purchase ISO 9000:2015
 Published hard copy
PDF e-standard
 See training courses for these crucial quality management functions:
 Quality control training
Quality assurance training
 Quality assurance consists of that “part of quality management focused on providing confidence
that quality requirements will be fulfilled.” The confidence provided by quality assurance is twofold—
internally to management and externally to customers, government agencies, regulators, certifiers, and
third parties.
 Quality control is that “part of quality management focused on fulfilling quality requirements.”
 While quality assurance relates to how a process is performed or how a product is made, quality
control is more the inspection aspect of quality management.
 Inspection is the process of measuring, examining, and testing to gauge one or more characteristics of
a product or service and the comparison of these with specified requirements to determine conformity.
Products, processes, and various other results can be inspected to make sure that the object coming
off a production line, or the service being provided, is correct and meets specifications.
 Industry perspectives on assurance and control
 For some service organizations, the concept of quality control may be foreign because there is no
tangible product to inspect and control. The quality assurance function in a service organization may
not include quality control of the service but may include quality control of any products involved in
providing the service.
 A service may include products that are documents (such as a report, contract, or design) or tangible
products such as a rental car or units of blood. It may be necessary to control product quality in a
service organization to ensure that the service meets customer requirements.
 Quality assurance and audit functions
 Auditing is part of the quality assurance function. It is important to ensure quality because it is used to
compare actual conditions with requirements and to report those results to management.
 In The Quality Audit: A Management Evaluation Tool (McGraw-Hill, 1988), Charles Mill wrote that
auditing and inspection are not interchangeable: “The auditor may use inspection techniques as an
evaluation tool, but the audit should not be involved in carrying out any verification activities leading to
the actual acceptance or rejection of a product or service. An audit should be involved with the
evaluation of the process and controls covering the production and verification activities.”
 Formal management systems have evolved to direct and control organizations. There are quality
management systems (QMSs) as well as environmental or other management systems, and each of
these systems may be audited.
 Excerpted from “Appendix E: History of Quality Assurance and Auditing,” from The ASQ Auditing
Handbook, by the ASQ Audit Division and J.P. Russell, editor, ASQ Quality Press, 2012, pages 299-
301.
 Why did you look up quality assurance vs. quality control?
 Please let us know what resources you would like to see. If you would like a reply, please include an
email address.
 Why is monitoring and evaluation (M&E)
important?
Monitoring and evaluation (M&E) of sport-for-development interventions is of high priority. The
relatively recent recognition of the use of sport as a tool in development requires thorough
assessment of the value of sport in development and humanitarian disaster contexts.

Sport can add value for the development of individuals, of organisations and of whole
communities irrespective of the level of development. Despite this broadly shared conviction,
there is still a lack of substantiated evidence to support the purported potential of sport.
Effective, transparent and (if possible) comparable M&E must therefore take place to further
determine the inherent benefits, risks and limitations of sport and physical activity.

Monitoring and evaluation is important because:

 it provides the only consolidated source of information showcasing project progress;

 it allows actors to learn from each other’s experiences, building on expertise and knowledge;
 it often generates (written) reports that contribute to transparency and accountability, and
allows for lessons to be shared more easily;
 it reveals mistakes and offers paths for learning and improvements;
 it provides a basis for questioning and testing assumptions;
 it provides a means for agencies seeking to learn from their experiences and to incorporate
them into policy and practice;
 it provides a way to assess the crucial link between implementers and beneficiaries on the
ground and decision-makers;
 it adds to the retention and development of institutional memory;
 it provides a more robust basis for raising funds and influencing policy.

Why is monitoring and evaluation important?

Monitoring and evaluation are critical for building a strong, global evidence base around violence
against women and for assessing the wide, diverse range of interventions being implemented to
address it. At the global level, it is a tool for identifying and documenting successful programmes and
approaches and tracking progress toward common indicators across related projects. Monitoring
and evaluation forms the basis of strengthening understanding around the many multi-layered
factors underlying violence against women, women’s experiences with such violence, and the
effectiveness of the response at the service provider, community, national and international level.

This is critically important because while the global evidence base on the proportion of women
having ever experienced various forms of abuse is strong, evidence on what kinds of strategies are
effective in preventing such violence and offering adequate support to victims and survivors is still
weak. This is especially relevant in resource poor areas, where difficult decisions need to be made
with respect to funding priorities.

At the programme level, the purpose of monitoring and evaluation is to track implementation and
outputs systematically, and measure the effectiveness of programmes. It helps determine exactly
when a programme is on track and when changes may be needed. Monitoring and evaluation forms
the basis for modification of interventions and assessing the quality of activities being conducted.

Monitoring and evaluation can be used to demonstrate that programme efforts have had a
measurable impact on expected outcomes and have been implemented effectively. It is essential in
helping managers, planners, implementers, policy makers and donors acquire the information and
understanding they need to make informed decisions about programme operations.

Monitoring and evaluation helps with identifying the most valuable and efficient use of resources. It is
critical for developing objective conclusions regarding the extent to which programmes can be
judged a “success”. Monitoring and evaluation together provide the necessary data to guide strategic
planning, to design and implement programmes and projects, and to allocate, and re-allocate
resources in better ways.

(Adapted from Gage and Dunn 2009, Frankel and Gage 2007)

For initiatives addressing violence against women, monitoring and evaluation is more
than a costing or cost-effectiveness exercise. It is a way of ensuring women and girls are
able to live their lives free from violence and abuse.

What can be learned in general from monitoring and evaluation of initiatives on violence
against women?

What interventions and strategies are effective at preventing and responding to violence against
women and girls?

What puts women at greater risk than others

What services are needed to help women and girls recover from violence?

What could be the role of different sectors in addressing and preventing violence?

What other factors (social, economic, political, cultural etc.) play a role in perpetuating vulnerability to
violence or hindering access to services?
What kinds of investments produce more promising results/ how much do they cost? (Adapted from
Watts 2008)

What can be learned about specific interventions from monitoring?

Are the proposed activities being carried out in the manner outlined? Why/ why not?

What services are provided, to whom, when, how often, for how long, in what context?

Are services accessible? Is the quality adequate? Is the target population being reached?

Are women being further harmed or endangered because of the intervention?

Have there been any unforeseen consequences as a result of the activities?

Are activities leading to expected results?

Do the interventions or assumptions need to be amended in any way?

What can be learned about specific interventions from evaluation?

The outcomes that were observed?

Whether the intervention is making a difference?

If yes, what actual difference the intervention is making; how it is making this difference and for whom.

The extent to which the intervention is responsible for the measured or observed changes.

The unforeseen consequences, if any, that resulted from the intervention?

What are some important questions that an evaluation can help answer?

Is the intervention feasible and acceptable?

Did it have an impact?
Why or why not? How and for whom did it have an impact?

Are the results credible?

Is it affordable and cost effective?

Can the cost be compared with alternatives to investment?

Is it replicable to other settings?

Where is it replicable? Where is it not replicable?

Are the results likely to be generalizable?

Can it be scaled up? That is, can the intervention be adapted, replicated or built on to increase its
reach or scope (for a larger population or a different region)?

If yes, how can it be scaled up? What aspects can be scaled up?