Seema Sonkiya: Project Quality Important Notes

This article is based on PMBOK4 and also includes some incorporation from ITIL v3 standard in the definition of Quality. Here my emphasis is only to define Quality definition in detail and to provide detailed interpretation of definitions of Plan Quality, Perform Quality Control and Perform Quality Assurance and defining relationships between all of three quality processes. I used definition of deliverable completeness from AGILE

What is Quality?  PMBOK4 says that Quality is “the degree to which a set of inherent characteristics fulfill the requirements. It can be also defined “fitness for use” or “conformance to requirements” All of these definitions pointing a very important item that quality is defined for the requirements that have been identified. If requirement is not defined then on what basis quality will be defined? We can observe easily that scope baseline (scope statement, WBS and WBS dictionary) is critical input for defining quality.  Requirement gathering effort and the project scope statement is very important to the quality management effort.

Quality is “Fitness for use” because when a product, service and result are developed then there is always a purpose to develop it; we define it “Fitness for purpose”. Fitness for purpose means functionality offered by product / service as the customer views it, it is what the customer gets and it increase performance average. Fitness for purpose is the utility function.

Now Fitness for use means, it is a promise that product service or result will meet the agreed requirements (note the term agreed), whatever customer gets, how it is delivered and it reduce the performance variation. It is Warranty function means it answers the questions like whether service, product or result is available enough? , capable enough? , continuous enough? Or secure enough?

For example Fitness for purpose for a refrigerator is to provide cooling but if it is giving shock then it is not fit for use even though capable enough to provide cooling.

If a website is developed with all the functions but user cannot use it in peak hours due to heavy user load then it is not fit for use.

So Quality is clearly conformance to requirements means whatever we have agreed for the requirements, fit for use and continue to receive utility even if degraded through major disruptions and ensure security for value creating potential of product, service and result.

A product, service or result delivered value to project stakeholders either directly or indirectly and this value is AND functions of both Fitness for purpose and Fitness for use.

If requirement is incorrectly defined then we cannot say that product has poor quality, quality is not disagreement to requirements it is the conformance to requirements. For example if a project is not identified legal requirements applicable for the project then it is not poor quality, it is poor requirement definition.

Quality is defined for project and product, service and result.  For example product quality can be defined as meeting customer requirement by less or no overworking the project team (how customer requirements delivered). Project quality can be defined for example meeting project schedule without excluding planned inspections (how we met the project schedule). So Quality is not just what we get (Fitness for purpose) it is also how we get (how it is delivered).

Quality is also defined as “Zero Defect” because Zero Defect can be viewed as conformance to requirements.

A product, service or result should satisfy the needs for which it was undertaken, mature organizations document the organization way of doing business using quality management which determine the policies, objectives and responsibilities. 

Project quality standard means project processes and product goals, project process are tailored for the specific need of the project. Most of the organizations include customer satisfaction in Quality Policy and Objectives because customer satisfaction is defined as understanding, evaluating, defining and managing expectations (PMBOK4 page no 190) so that customer requirements are met. 

We can observe easily that quality management efforts is direct proportionate with project and product requirements, schedule performance requirements and cost performance requirements as well as threats and opportunities that can impact project and product quality.

PMBOK4 defines 3 Processes for Quality Management:

1.       Plan Quality: Identify quality requirements and/or standards for the project and product. So Plan Quality is all about:

a.       To identify project and product quality requirement.

                                                               i.      We need scope baseline which includes acceptance criteria (processes and criteria) for each identified project and product requirement. WBS is used as input to identify quality both at macro and micro level. It includes the entire project and product deliverables, work packages and control accounts. Quality requirement identified for each components of WBS both at macro and micro level. WBS dictionary defines technical information of the WBS elements.

                                                             ii.      Schedule performance is also important, a project schedule includes planned start and finish dates of project activities, while determining schedule activities LOE and AE are very important to identify and define how schedule is achieved.  For more information about LOE and AE please refer: http://seema-sonkiya.blogspot.in/2012/03/project-schedule-development-important.html

                                                            iii.      Cost performance is also important to identify, if we have achieved project and product scope including schedule performance but we are over budget then quality is not achieved. Cost baseline gives time phase spending plan to identify how much fund is needed at what time. Cost of quality should not be too much compared to benefits. Cost benefit analysis is performed to ensure that we are not spending too much compared to benefits that we achieved.

                                                           iv.      In addition stakeholders are involved to identify quality requirements and risk register is reviewed to identify opportunities and threat that can impact quality.

b.      To Identify Standard that include  processes and product goals, most of the organizations follow quality management methodologies like CMMI, Six Sigma, Lean Six Sigma to define processes to define quality standards.

Note: Here my emphasis is to define: what is Plan Quality, not to describe tools to achieve it.  

2.     Perform Quality Control: Whenever a deliverable is completed it is submitted to quality control process, Main emphasis of Quality Control is to determine causes of poor process and product quality. For example testing and inspection by Quality control is recorded and documented to identify causes of poor work, these documented results are called Quality Control Measurements which is key input of Quality Assurance. I will explain in more detail Quality Control Measurements in Quality Assurance section.  Quality Control mainly determines correctness of deliverables and these validated deliverables is sent to Verify Scope process to formalize acceptance of Customer and/or Sponsor. Quality Control also determines timely implementation of approved changes. So three main objectives of Quality Control:

a.      Causes of Poor process and product quality and result in documented results, known as Quality Control Measurements.

b.      Determine correctness of deliverables, result in validated deliverables.

c.      Determine timely implementation of approved changes and result in validated changes.

Notes:

a.      definition of complete is very important, SCRUM agile methodology emphasis the definition of complete, we define completed deliverable when each team member completed quality test of his/her work(i.e. unit testing as per defined test cases, in agile test cases defined prior to coding). Each team member should be aware of quality specific to his/her assigned work. Only after completion of work as per defined definition, it is submitted to quality control process.

b.      To perform all of these tasks quality control uses quality metrics and quality checklist as a key input, both are key output of Plan Quality process. Quality metrics and checklists are identified to determine correctness of project results which includes deliverables and project management results, such cost and schedule performance. In addition work performance measurements which provide information about planned versus actual technical performance (output of control scope), planned versus actual schedule performance (output of control schedule) and planned versus actual cost performance (output of cost control) and approved change requests are also used as input to perform all of these three major tasks.

3.       Perform Quality Assurance: Purpose of Quality assurance is to determine whether appropriate operational definitions and quality standards are used.

a.      Quality assurance process identify areas where to improve mainly with the help of quality control measurements. Quality Assurance performs detailed analysis of Quality Control Measurements to analyze and evaluate the quality standard and processes.

For example if Pareto Chart is  used as a tool in Quality Control which is bar chart to show how many problems occurred for each cause and arranging them according to the frequency  at which the problems occurred. Example of recorded could be causes:

                                                               i.      Incomplete or erroneous specification (IES)

                                                             ii.      Misinterpretation of customer communication (MCC)

                                                            iii.      Intentional deviation from specifications (IDS)

                                                           iv.      Violations of programming standards. (VPS)

                                                            v.      Error in data representations (EDR)

                                                           vi.      Inconsistent component interface (ICI)

                                                         vii.      Error in design logic (EDL)

                                                        viii.      Incomplete or erroneous testing (IET)

                                                            ix.      Inaccurate or inconsistent documentation (IID)

                                                             x.      Error in programming language translation of design (PLT)

                                                            xi.      Ambiguous or inconsistent human/computer interface (HCI)

                                                          xii.      Miscellaneous (MIS)

These results are analyzed by Quality Assurance process which analyze the pareto chart to identify improvement area using determinations of Vital few, for example suppose IES, MCC and EDR are vital few causes that account for more than 50% of all errors, however that IES, EDR, PLT and EDL would be selected as the vital few if serious errors are considered. Once the vital few are determined the quality assurance team can begin corrective action, for example to correct MCC, the project manager might identify process improvement in “Collect Requirement” process, and process analysis of “Collect Requirement” may be performed to improve the quality of customer and other stakeholder communication and specifications.

It is important to note that corrective actions focuses primarily on the vital fews, As vital few corrected new candidates pop to the top of the stack. So we should spend our time focusing on things that really matter, but first be sure that we understand what really matters!

Here I used pareto chart tool as an example to explain the relationship between Quality Control and Quality Assurance. There are more other tools that can be used in these processes.

b.      Quality Assurance determines whether we are using correct processes means validate quality standards which are identified in Plan Quality. Process analysis is important tool to perform it.

c.      Quality Audit is also an important tool in quality assurance to identify all good/best practice being implemented, shortcomings, proactively offer assistance to improve implementation of processes.

d.      Quality assurance is an umbrella for continuous improvements as we observed in aforesaid pareto chart example.

In short plan quality define quality management plan which explain that how Project Manager will implement Quality Policy and identify Quality Assurance and Quality Control    approaches. Quality requirements and standards are identified in Plan Quality and Quality Assurance ensures that we are using these standards and we are successful in meeting quality requirements after analyzing quality control measurements and process definitions, in addition identify improvements in standard and quality requirements that’s is basis of continuous improvements. It use outcomes of Quality Control process which is documented results of causes of poor process and product quality and also performs process analysis to identify improvements.

As we observe that as Quality Assurance use documented results of Quality Control, it means this process use all of the tool of Plan Quality and Perform Quality Control because Plan Quality set up and define all the tool and Quality Control use these tools to identify causes and Quality Assurance use these results to identify improvements. For example control chart is set up in Plan Quality and Quality Control is performed in which actual appropriate data is collected and analyzed to indicate quality status of the project processes and products. These results are analyzed by Quality Assurance.

Seema Sonkiya

Seema Sonkiya: Project Procurement Important Notes

This article incorporates PMI best practices on Procurement. PMBOK 4 defines procurement knowledge area from Buyer point of view, my articles bring forth the Seller point of view for a Project Manager.

Why Project Manager should gain knowledge of procurement Process: Main objective of project manager is to integrate project elements into cohesive whole to attain project objectives; many project managers are less interested in the procurement process. This is misinterpretation that only procurement managers need to be involved in procurement, yes it’s true that procurement managers are accountable for successful procurement but project managers are also responsible for the same. I believe readers understand difference between accountability and responsibility. Project Manager is accountable for the project for which he/she authorized through signed project charter and Procurement manager is accountable for the successful completion of Procurement. In case of decentralized procurement system Procurement Manager owns the procurement processes and project manager is part of procurement team.

1.     Why a project manager need to understand the procurement process, following are the important reasons:

a.      Project Manager Involvement with procurement manager in conduct procurement process (Pre Sale): Project Manager In service based organizations need to understand how sales enquiries flow in the company and need to understand whole process that is performed in the company before project formal initiation. Project manager involvement started when any sales enquiry come to the company. Buyer provides the procurement documents including PSOW, terms & conditions and contract type.

                                                               i.      Every project has associated business needs aligned with strategic plan, project manager may need to review and analyze the business need of project (included in PSOW). For example a sales enquiry has come where customer’s objective is to enter new area of business, and customer asked to provide the cost estimates. Project manager is needed to research PSOW along with proposed contract details, and provide the feasibility report of project whether it is possible to achieve business need under the given constraint specially budget constraint. At this time budget and other constraint detail is found in procurement documents provided by buyer.

                                                             ii.      Many times contract type are fixed fee. I have mentioned in my estimation article that range of estimates at this stage is +_50% but if contract type is fixed then PSOW must be complete and clear and range of estimates cannot be ROM. Services of project manager become critical in fixed fee type of contract. High risks are not acceptable in this situation.

                                                            iii.      Many times bidder conference conducted prior to proposal development to discuss the details of project with buyer, project manager services may be needed to either ask or answer technical queries. Seller side questions are asked to clarify details of PSOW or sometime buyer ask question to get acquaintance technical expertise and project management approach of seller.

                                                           iv.      Most of the time buyer decides the type of contract and procurement documents, Seller procurement manager may need assistance of project manager to review these details. RFP is suggested in performance or functional PSOW and cost reimbursable contract type, IFB (Invitation for Bid) is suggested in design PSOW and Fixed price contract type. RFQ is suggested in any PSOW when contract type is T&M. Seller procurement manager may need project manager to review correctness of Procurement documents, for example when contact type is fixed price then seller need to review whether PSOW conveys precisely what work is to be done including details of project management approach like details of meeting, communication and reports.

                                                            v.      Review of procurement documents (PSOW, contract type & terms & conditions) completed to get a full understanding of what the buyer wants and assess the risk involved in the project.

                                                           vi.      Now seller procurement manager decides whether to submit a bid or proposal to try to win the work. Seller need to prepare a response to the procurement documents. Proposal is developed with the help of project manager. While preparing proposal document, if technical team lead by the project manager have difficulty understanding the project they get back to the client. The co-ordination with the client is done normally through co-coordinator who is deployed at client side. This can be exception also where the technical team directly coordinates with client. Client can be contacted in the following ways :

·         Telephonic conversation

·         Email.

·         Through Business analyst or coordinator appointed at client side.

·         Client himself comes to company to clarify doubts.

                                                         vii.      During this clarification small technical samples can also be prepared to ensure technical feasibility of the project. Example the project has requirement to send reports to mobile. Now is that possible so for this small code samples can be run and seen. This is called as POC [Proof of

Concept]. If the technical department says it’s not possible then probably again coordinate with the online client coordinator or client himself to clarify things.

                                                        viii.      Technical department starts prepare estimates which will involve estimating effort using Function Points (FP), Use Case Points (UCP), and WBS or ADHOC methodologies. My recommendation is to use FP and analogous estimation at this stage. For more details please refer my estimation article: http://seema-sonkiya.blogspot.in/2012/03/project-estimation-important-notes.html

                                                            ix.      After technical department finishes the effort estimate it passes it to procurement manager and other key stakeholders may be included like the board of directors, or senior members of the company for final approval. They review the estimated amount once before sending to the clients.

                                                             x.      Finally the estimates are sent to the client. If client gives a positive feedback then proposal document is signed off, initial payment given (if in the terms and conditions) and the project is started. If the client is not happy with the quotation pricing amount it moves to negotiation table. So probably client will remove some functionality and ask for a fresh estimate or will stress the company management to minimize the estimated amount.

                                                            xi.      Care need to be taken to include the estimates for the following:

·         Technical and procurement manpower engaged to send the estimates.

·         Client co-ordination investment

·         Telephonic conversation. In short telephone bills can be high when its international client.

·         Business analyst appointed at client side if any.

·         Traveling charges to client location especially can be problem if the client is international.

·         Preparing POC and prototype screens to understand project better will also need quiet an effort.

                                                          xii.      A good proposal should at least take the company to a negotiation table. So that company at least does not lose the project.

                                                         xiii.      In addition project manager is required to tailor the contract for the unique need of the project. Project manager is involved in procurement negotiation to protect the relationship with the buyer; this negotiation is lead by the procurement manager.

b.      Project Manager Involvement with procurement manager in administer procurement process: Project is awarded and project manager is still required in procurement process that is Administer Procurement along with other project management activities. Project manager work with procurement manager in administer for:

                                                               i.      Protect the integrity of project and get the work done as per the defined procurement process.

                                                             ii.      Manage interface with the buyer.

                                                            iii.      Report procurement performance. For example in case of T&M, provide hours spent report.

                                                           iv.      Monitor performance against the contract

                                                            v.      Submit cost submittals with the procurement manager.

                                                           vi.      Maintain records of everything, each phone call, each email etc.

                                                         vii.      Help to make sure with procurement manager that all work in the contract is done, including the release of lines and ownership of materials not just the technical scope.

                                                        viii.      Work with the procurement manager to manage changes in the contract.

c.    Project Manager involvement with procurement manager in close procurement process:

                                                               i.      Involved in lesson learned.

                                                             ii.      Complete final contract performance reporting to submit buyer.

                                                            iii.      Verify the product with buyer

                                                           iv.      Create a procurement file.

                                                            v.      Get financial closure.

I believe after reading this article project managers will understand their importance in procurement also, including presale and will contribute in its whole success.

Seema Sonkiya

Seema Sonkiya: Change Management Important Notes

This article is based on PMBOK 4 and ITIL V3. My article is detail interpretation of PMBOK 4 and some incorporation from ITIL v3 standard.

Objective of change management is to respond changing environment, plan, and business requirements.  It is an effective response to a business and IT requests to align product, service and result with business needs.

Changes should be managed with standard process, which may be tailored to the specific need of the project. A centralized system for the project should be present to record all changes.

Change management ensures that changes introduced in controlled manner. Every change request must be made formal.  Every change request that is made verbally, directly, indirectly, externally, internally; it must be recorded in RFC document. All changes are recorded.

Change management plan defines how integrated change control process will work whenever a change request come. This change management plan should be formally developed for each project and approved. It’s project manager responsibility to get buy-in from all especially from key stakeholders for the approved change management plan and  in case if project is initiated due to external customer request then customer should be educated about the integrated change control process

Change management is closely related with configuration management. Configuration management record and report the list of all configuration items. CI is basically defined as any asset and component of service, product or result which is under control of configuration management system. Configuration management system also records relationship of CI with other CI (A change can affect multiple CI). According to ITIL V3, configuration management stores relationships between CIs, and also relationship with incidents, problems and change records. All CIs are subject to change management control.

 What is a change: It is addition, modification or removal of any service, product, or result or addition, modification or removal of configuration item.

In PMI terms change is defined any addition, modification, or removal in the baselines, project documents especially project charter, contract, policies, procedures, SOW, and it may also change in environment which does not make changes in above documents.

ITIL defines three categories of changes:

1.                            Normal Change: Generally managed by CAB (CCB in PMI), PMI says that project managers has authority to approve some minor changes without CAB/CCB meetings as per the authority defined in change management plan.

2.                            Standard Changes: Pre authorized with an established procedure, task are well known, documented and usually have low risk like upgrade PC.

3.                            Emergency Change: When there is insufficient time for normal handling. In these types of changes we should use normal process but we need to speed up because impact can be high, more prone to failure, and our focus is to kept them minimum. E-CAB members selected as per need of the change.

I observed sources of changes:

1.                            Agile methodology says that it is difficult to predict in advance which requirement will change and which will persist. When design and construction are interleaved so that models are proved as they are created. It is difficult to predict how much design is necessary before construction to prove the design. Analysis, design, construction and testing are not as predictable as we might like. So to manage these unpredictable environment works is performed with small duration releases. So rapid changes in environment is primary driver in agility. Agile methodology is adaptable to rapidly changing project and technical conditions. As per PMI phase to phase relationship is iterative in undefined, unpredictable environment and scope is managed with frequent small increments.

2.                            In ITIL other processes like Incident management problem management trigger changes.

3.                            As per PMI executing and monitoring & controlling processes trigger change request. It includes defect repair, corrective or preventive actions and changes to baselines, project documents. Example like change request identified when we meet up with customer to gain acceptance of completed interim deliverables, measuring performance against baselines, when we are doing project audit to make sure that we are using correct processes and identify improvements in policies, procedures and processes. When creating performance reports, when working with project team and discover that project team member is not performing, when we notice that there are many unidentified risk occurring, when we identified that seller performance is not meeting expectations, when we are doing quality control of completed deliverables, when we are communicating with stakeholders to resolve issues and manage their perceptions about the project. All are example of either executing or monitoring & controlling processes.

Care should be taken by the project manager that changes should not come due to poor planning, approach should be proactive. Example of poor planning can include lack of stakeholder engagement, rolling wave planning used as an excuse and scope is not defined clearly, lack of risk management efforts, lack of stakeholder buy-in, gold platting, estimates are padded and reserves had not established, lack of clear role and responsibilities  etc. In other words if we do not have realistic project management plan and we have not defined complete product or project scope either for whole project   or for current release in case of iterative phase to phase relationship then large number of changes will come, that’s why project manager must analyze sources of change request.

Integrated change control process is integrative process because a change request can impact all other knowledge areas and impacts are analyzed for all aspect of project like scope, cost, schedule, quality, risk, human resource, communication and procurement.

In addition to control changes we need to have process to control changes, define roles and responsibilities for CAB/CCB members including project manager/change manager and we should have templates to request changes. In ITIL incident, problem and change record are referenced each other.

 Steps to process a change request:

1.                            Assess the change: When change request created it should be evaluated, if we have already a reserve for a change then this is managed by a risk management as it is already identified risk and has occurred.  We should have contingency plan for most of problems to create hassle free environment. We need to evaluate complete impacts and we need to see effect on other project constraints like scope change need to be evaluated for impact on schedule, cost, quality, resources, risk, communication, procurement etc. It may be needed to use suppliers if change request approved. ITIL recommended analysis of 7 R’s of change like:

                                                               i.      Who RAISED the change?

                                                             ii.      What is the REASON for the change?

                                                            iii.      What is the RETURN required from the change?

                                                           iv.      What are RISKS involved in the change?

                                                            v.      What RESOURCES are required to deliver the changes?

                                                           vi.      Who is RESPONSIBLE for the build, test and implementation of change?

                                                         vii.      What is the RELATIONSHIP between this change and other change?

If we are working for a customer then my recommendation is to provide impact analysis to customer first because if impacts are high then it may be possible that customer will reject the changes, considerably time will be saved before looking options. Customer may be involved in impact analysis. We provide customer list of effected CIs.

2.                            Create options:  Basic objective is to balance the competitive constraints. It may include compressing the schedule, adding resource to project, adjust quality, add scope etc. If change is logical and correspond to new scope added to the project by the customer then project should get extension in normal circumstances.

3.                            Get the Change request approved internally first then get customer buy-in.

4.                            Adjust the project management plan, project documents baselines.

5.                            Manage stakeholder’s expectations by communicating the change to stakeholders effected by change

6.                            Manage the project to the revised project management plan and project documents.

Project Manager make sure that process is followed, either he/she coordinate or authorize change manager (if change manager appointed for project) to facilitate CAB/CCB meetings; make sure necessary information is available to evaluate change. Key challenges of effective change management may include pressures of “just do it”, inaccurate and incomplete configuration management system, misunderstanding of emergency changes, vendor/contact compliance and adhoc nature of people.

Seema Sonkiya