Defining the Quality

Project quality planning is about setting the right expectations on how the outcomes to be produced. Before we can plan how to obtain the result, we must define the quality expectations of the results. So in summary, quality planning involves two steps:

1. Defining the Quality Expectations
2. Defining How the Quality Expectations [satisfaction] To Be Met

Quality Expectation

Quality Expectation is about - what does the customer want. It should reflect how should the customer's satisfaction can be achieved after he/she gets what we give (the delivery of the quality expectation). In general term, quality means "specified functionalities that are fit to use". This means that, when they are fit to use, then the satisfaction is achieved.

For an example on an Internet Infrastructure Setup Project, the requirements are:

1. Scalability
2. High Availability
3. High Performance

Once the high level requirements are defined, we can now specify the quality expectations. The quality expectations should be measurable:

Scalability - The infrastructure can be expanded. This means that we can add additional web servers, additional licences, etc.

High Availability - The infrastructure has to be "on" all the time. At least the total down-time allowed in one year is X hours.

High Performance - The performance of the system should be fast (efficient). This means that when a user opens a web-based reports, the response should be within ? seconds. Or, when the user open a web-based public page, the response should be within ? seconds. Of course, the performace can be affected by many factors, but there should be a measurement of various types of pages.

Once we have specified the measurable quality expectations, the planning of how to execute them will be easier. For example, to use purchase what types of equipment, how many servers, etc will be easier to plan. Another example can be like the scheduled down-time in a year, and which resources assigned to solve the problems, etc will be easier to plan when the quality expectation is measurable.

Quality Control Processes

How the outcome is to be tested against the quality defined is subject to the nature of the product or service. For example, how to test whether the outcome delivered is according to the quality expectation for a software system will be totally different from a project building a disaster recovery center (DRC).

When the quality definition is done properly then the testing part will be easier. Testing is one of the means for us to find out if there is any defects in the outcome so that we can control the quality. The testing methods must be carried out according to the plan. The plan is in regards to how the quality is defined and by meeting what conditions then the quality is met. So, the testing is "planned" when you define your quality definition. It is the starting point of the testing.

In my early days when I was a software developer, I started planning the testing only after the system is completed. But, how it should be tested, I didn't really know. Why? Because the customer didn't define how it is to be tested and my supervisor (the manager) didn't tell me how to define the quality in the first place ... What happened then? The customer hesitated in accepting the system as per it is "fit" to be operated in the production environment. What was the consequence? The payment was delayed. How it was delayed? The customer bargained with my manager for how it should be considered fit for them to accept only during User Acceptance Test! There were 5 testers that tested the system and these 5 testers had their own "expectations" which were conflicting with what the quality expectations "created" by us (the supplier). Crap! Work done! No money! All complaints here and there!

So, in summary, these problems can be avoided if in the first place the "fitness of use" is defined properly :-(

R&D on Project Performance Tracking

I have created some files to demonstrate the project performance tracking by using Ms Project 2003 and Ms Excel 2003.

All the files are zipped. The Ms Powerpoint file contains the scenario and sequences of the demonstration.

Please feel free to test it out and let me know if you have any better ideas or ways in doing it. Let's share our problems and solutions :)

The following is the summary of the R&D:

I create two projects. Project A and B. The mission of both projects is to install 100 units of PCs within 8 days. For every 20 units of PCs intallation, we assume 20% completion of the project. So, the following is a summary of the plan:

Day 1 - 20 units, Day 2 - 20 units, Day 3 - 20 units, Day 7 - 20 units and Day 8 - 20 units. For

Project A, I allocate these individual units across one single task row while Project B I break down the milestones into 5 task rows.

Then I enter the actual value - the actual units of PCs installed on individual days. I enter 20 units for day 1 and 40 units on day 2. Now the problem comes: Project A doesn't reflect the correct % complete accordingly. So, it is better if we breakdown the milestones into individual task rows. Check the presentation file for details...