Quality Archives - PM Certification: Recent Episodes

View Details

https://ia801508.us.archive.org/29/items/10TotalQualityManagementVFinal/10-Total%20Quality%20Management_vFinal.mp3 “A customer is the most important visitor on our premises; he is not dependent on us. We are dependent on him. He is not an interruption in our work. He is the purpose of it. He is not an outsider in our business. He is a part of it. We are not doing him a favor by serving him. He is doing us a favor by giving us an opportunity to do so.” – Mahatma Gandhi

Introduction to Quality With ever evolving market dynamics, every manufacturer in each product category is trying to fuse in all possible attributes in a product/service. It is also necessary to maintain competitiveness by generating a steady stream of new products. To succeed firms try to respond to changing customer needs and the moves of their competitors. But all these efforts are leading the consumer to a dilemma because of not so distinguished products/ services. For example all mobile phones with each passing day are becoming synonym to one another in terms of technology within a specific price range.

The number of new products and processes has increased while the model lives and life cycles have shrunk. Thus what makes a product/service stand out from the cluster or define the impact and profitability of the new product can be answered by a term -Quality- in general can be defined as a standard against which similar kinds of things are measured. Quality is more of a perceptual parameter to judge than a concrete set of rules. It can vary from consumer to consumer on the basis of fulfilled requirements and the satisfaction obtained.

As per American Society for Quality: “A combination of quantitative and qualitative perspectives for which each person has his or her own definition”; examples of which include, “Meeting the requirements and expectations in service or product that were committed to” and “Pursuit of optimal solutions contributing to confirmed successes, fulfilling accountabilities”. In technical usage, quality can have two meanings: a. The characteristics of a product or service that bear on its ability to satisfy stated or implied needs; b. A product or service free of deficiencies.”

This leads us to find what it takes to maintain the level of quality which leaves the clients asking for more not because of deprivation but because of satisfaction. Till few years back the term quality was used either in context of manufacturing of a product and customer’s conditional views after using that product. Production and operation activities like process, capacity, inventory and workforce still represent the large chunk of an organization’s human and capital assets but with digital transformation of enterprises, quality is no longer just producing less defective items. It has swept into each vertical of the business like sales, manufacturing, advertising and customer service and decides the fate of the product and the business as a whole.

Total Quality Management Total quality management or TQM may be defined as managing the entire business so that it excels on all dimensions of products and services that are important to the customer. There are two essential goals for TQM:

1. Careful design of the product or service
2. Ensuring that the organization’s systems can consistently produce the design.

How to achieve TQM is no secret anymore. Companies like General Electric and the Motorola have used the philosophy and methods of Six Sigma to eliminate defects in their products and processes. The methods installed in this step seek to reduce the variation in the processes that leads to these defects.

The challenge is to make certain that a quality program really does have a customer focus and is sufficiently agile to be able to make improvements quickly without losing sight of real time needs of the business.

There is also a need for sustaining a quality culture over the long haul. As Tom Peters has said, “Most quality programs fail for one of the two reasons: they have system without passion, or passion without system.”

Arpit VaishnaviThe post Total Quality Management (TQM) Foundation appeared first on PM Certification.

View Details

https://ia601506.us.archive.org/24/items/6QualityAssuranceInProjectManagementVFinal/6-Quality%20Assurance%20in%20Project%20Management_vFinal.mp3 Quality assurance and quality control (QA/QC) in project management is much misunderstood. People tend to associate quality with particular methods, when they should really be focusing on results.

A ‘quality’ deliverable is one that’s fit for the purpose specified by the customer. A quality toaster for the home is likely to be completely different to one for a hotel, because of the volume of use each endures. Producing a domestic toaster to catering appliance standards is likely to result in a large and very expensive toaster with few benefits for the home user; do it the other way around and the hotel will end up with cheap toasters that soon break down.

The two major elements of quality assurance in project management are:

• Review and sign off
• Testing

Review and sign off A review is the single most effective means of maintaining quality.

It also provides a forum to encourage creativity and ideas: ‘That’s good, but have you thought about doing it this way instead.’ Creative thinking comes more easily from groups than individuals. One person’s idea can spark off a new, even more exciting thought in someone else.

So let your hair down. Review IT code, documents and processes – in fact, review everything you think you have completed. It isn’t just a useful exercise but a cost-effective one. Devoting a relatively short time to a review removes errors early on and reduces the need for expensive re-working later.

All major requirements, deliverables and designs should be reviewed and signed off by the person who is going to use the deliverables or someone they’ve delegated to do it in their absence. This ensures that there are no arguments down the line about exactly what was required.

Consider how you carry out reviews. Although it’s become the norm to send documents by email, it’s more involving and interactive to get interested parties together at a meeting to review the document.

It isn’t hard to organize. All you’ll need is:

• A chairperson
• A scribe to document agreed actions
• The author(s)
• Reviewers, including whoever’s responsible for signing off.

Remember to instruct attendees to read the relevant document(s) before the review, and to come armed with their comments.

Testing If you do nothing else well on your project, do the testing well.

You need to be 100% certain that what you’ve built conforms with what was specified in the Requirements (or Product Backlog if you’re involved in an Agile project). If it doesn’t – and depending on the severity of the faults and their implications to your customer and theirs – you’re going to find yourself with egg on your face and maybe with a lost client.

The most important stage Get testing wrong and you potentially end up wrecking your productivity, your reputation, your legality or possibly all three. People tend to associate testing with IT, but an untested process can have disastrous results if opened up to the public.

It should go without saying that you should always formally walk through changed processes before implementing them. It should be as unthinkable as opening an untested road bridge or launching an untested plane.

You have to be exceptionally lucky for anything to work well on its first exposure to the real world, so going live without testing is a very risky strategy. Don’t do it.

Be thorough The other rule with testing is to be thorough; it should be obvious that there’s little point in testing something unless you do it properly. The risks of cutting corners always outweighs the benefits and the costs of fixing something after go-live are much higher than they would have been earlier in the process.

That said, there’s a difference between being thorough and being ridiculously over-cautious. There are reasonable limits to testing!

Phases of testing You should anticipate covering some or all of the following phases:

• System testing (does what’s been built conform to the specified requirements?)
• Acceptance/user testing (does it work operationally?)
• Performance/stress testing (does it work under load and meet performance requirements?)
• Security testing (for example, are you sure that an IT system can’t be breached or that a process isn’t open to internal or telephone fraud?)
• Model Office Testing (simulating usage in a real working environment – usually this is only carried out in big or complex implementations, such as a call centre set-up where systems, telephony and processes are new and staff have been recruited and trained).

Test automation Testing of IT systems is, to an ever-increasing degree, carried out using automated test tools. With an automated test tool, you write the test once and can then run it many times.

Another advantage of automated tests is that they remain after you’ve delivered the system, so if you need to make changes later you’ll be able to re-run the original tests to make sure that you haven’t broken anything. This is commonly referred to as regression testing.

The number of test tools available is expanding rapidly. As I type, QTP by Hewlett Packard is the most widely used automation tool. Selenium is popular, free and can be used to automate the testing of browser-based software, while Axe from Odin and eggPlant from TestPlant are also capable tools with a significant following.

Outsourcing If you’re outsourcing any aspect of the project, don’t trust the external company to do all the testing. You should always carry out final user/acceptance testing in-house, as a quality check on their work, and may find it advantageous to attach a stage payment to them successfully passing the acceptance test. It’s a great incentive for them to work to a high standard, and without cutting corners.

Finding and fixing You should maintain a fault log throughout testing, showing both open and closed faults, and noting their severity as well as what action is being taken to resolve them. A spreadsheet should be sufficient for this, but there are also bespoke software tools that will do it for you.

HP’s Quality Center is very popular, but isn’t cheap. You might want to have a look at Bugzilla, which is free and widely used but lacks the professional support of paid for packages. The latter provides the functionality to allow you to manage all testing, so it’s worth a look.

As testing progresses, particularly if you have a supplier involved or when the project is substantial, you may want to organize and run regular test review meetings, based around the fault log. I usually run these on a daily basis when I’m a few weeks away from the deadline to complete testing.

Gren GaleThe post Quality Assurance in Project Management: Review It, Test It and Have a Far Happier Life – How’s That for an Offer You Can’t Refuse? appeared first on PM Certification.

View Details

https://ia601500.us.archive.org/28/items/94ProjectManagementQualityFocusesVFinal/9-4%20Project%20Management%20Quality%20Focuses_vFinal.mp3 Quality Should Be a Core Attribute in Project Management Quality is not just about the final product. In project management, it is applicable to almost anything and everything involved in a project’s life cycle. One well accepted quality guidepost to adopt throughout a project’s progression is SMART – Specific, Measureable, Attainable, Relevant, and Time-bound. In other words, a quality project is one that have SMART fused in every phases, actions, and outcomes. In principle, quality should be ubiquitous inside a project; it ought to be as much about how the project is planned, controlled, and executed as what the project finally delivers.

To Project Managers, the bulk of quality benefits can be realized by weaving quality in four project action constituents called psst! This catchword stands for planning, scoping changes, signing off milestones, and terminating a project. These four are the key focal areas that collectively contribute to the lion share of the overall project quality and they are therefore where quality can be carefully ingrained into a project’s fabric to lead a rewarding high quality project journey.

Quality Planning is Pivotal to Achieving Project Success The first critical move to hike a quality project management trail is to embrace quality at the start, i.e. kick off project planning in a quality fashion. That means that all objectives, actions, and plans should be SMART. Quality project planning can be accomplished by knitting quality – the SMART protocol – into risk identification and mitigation, scheduling, resourcing, budgeting, determining communication protocols, deciding milestones and deliverables, and designing project closure and retrospection.

The more SMART protocol these plans entail, the more likely a project will execute close to its charted course. Nonetheless, deviation from a plan is needed at times to acclimatize the project to changing market demands or to compensate for any mishap during planning or any other project phases.

Since departure from plans is not completely avoidable, quality planning should be treasured as the immunization to minimize their ill-effects like higher cost, longer schedule, etc. As Benjamin Franklin famously said “By failing to prepare, you are preparing to fail”, everyone, particularly project managers, should abide by this doctrine; plan as much and as far way out as possible, and map out what-if situations (risks and remedies) to diminish perils from surprises or changes.

Quality Scoping is Key to Maintaining Project Alignment Although a project scope is most desirable to be worked out before a project starts, market dynamics, flawed project plan, and many other factors could warrant a scope tailoring after a project begins.

That means no matter how scrupulous a project has been outlined at the onset, unanticipated forces may necessitate a scope change that may affect anything or everything put into a project plan. Therefore a scope revision must be taken with great care to ensure that every alteration and adjustment will be meticulously strategized, executed, and integrated into the project roadmap complemented by realignments on resource, schedule, and budget when needed.

Rushing to amend a project scope might turn an otherwise symphonized project into chaos which might result in a capability gap, a budget shortfall, a schedule overrun, or other threats to the project. Hence when a scope moderation is prescribed, every activities must be methodically thought out and implemented in a SMART mode so that corresponding adaptations in resource allocation, budgets, deliverables, schedules, and customer expectations can be concertized to keep the project elements in harmony.

Simply put, if planned activities are not specific and time-bound, there will be no way to keep resource, schedule, and budget in harmony.

Quality Signoff is Crucial to Keeping a Project on Course Milestones are intermediate stages when project status and accomplishments are gauged against the pre-determined stage goals.

When milestone deliverables and schedules fall out of synch for whatever reasons, a quality milestone signoff review inspects the intermediate deliverables and the schedules, and examines if the remaining resource and budget are sufficiently adequate to fulfill all remaining milestones and final project objectives. Should they be incompatible, hopefully it is not too impactful to make SMART adjustments.

It is hard to steer a complex project to success without devotedly executing milestone signoffs on the project’s evolution path. A milestone signoff is a mechanism to validate if the project is running on course, thus each should be architected in a SMART way. A well-designed quality milestone map would enable project teams to recover from any misstep easier and quicker than they would otherwise without intermediate milestone checks.

From experience, setting up four to five milestone stages along a project cycle is a good practice when they are administered evenly across a project’s timeline. This arrangement limits fruitless efforts and/or futile intermediate results to 20 to 25% at most should they miss their intended targets and thus the loss might be absorbable and reconcilable.

Project Managers should be mindful that too many milestone signoffs could arouse team resistance whereas too few could put the project in jeopardy because a bigger percentage of work could have gone off course and been wasted.

Quality Termination is Critical to Learning and Customer Satisfaction Project postmortem are often forsaken when the next project is hard pressed to start or when most team members become unavailable because they have been immediately assigned to other projects. This is not a good practice.

After a project ends, a retrospection should be run to identify the wrongs versus the rights, the bad versus and the good, and the should-not versus the should-have so that the project team can learn from this experience, and be able to share and pass along their lessons to the rest of the company to help improve and enrich overall corporate project capability and culture.

Besides, a follow-up meeting with the customer to share the revelation and improvement plan will usually enhance customer satisfaction and relationship as well. Running projects without learning from the bygones is missing out on the benefits that can be reaped easily and most economically.

Coda Everyone wants quality. In project management, quality should be lived and breathed in every aspect throughout a project’s life cycle. Although a project involving five phases with numerous activities should all be quality driven ideally, project practitioners need only focus on melding SMART into four project areas to yield laudable quality results. These four focus zones are planning, scoping, signing off, and terminating; they constitute the four most important components to project quality. Hence to heed a quality project management path without actuating a full-fledged quality implementation, project teams can enact SMART in these four regions to cover the most vital parts of quality project management to enjoy commendable quality effects and outcomes.

Chi-Pong WongChi-Pong Wong is a seasoned thought leader in program management, customer experience, and supply chain strategy. He is an influencer on several LinkedIn groups and has published on leading online magazines including Project Times, PM Hut, Project Management, Customer Think, ServiceDirectors.org Business Review, UX Matters, Supply Chain Brain, and other popular journals. He earned a MA in Economics at SUNY @ Stony Brook, and a MS in Computer Science at Duke University. He has worked previously at Arrow Electronics, IBM, STMicroelectronics, NEC Electronics, and is currently with Hewlett-Packard. He can be reached at Linkedin

The post Psst! 4 Project Management Quality Focuses appeared first on PM Certification.

View Details

https://ia801508.us.archive.org/4/items/1PlanProjectQualityVFinal/1-Plan-Project-Quality_vFinal.mp3 At the beginning, it will be useful to emphasize what is understood from the concept of quality. In two different sources, quality is defined as follows:

• Quality is the degree to which a commodity meets the requirements of the customer at the start of its life. (ISO 9000)

• Quality is the degree to which a set of inherent characteristics fulfills requirements. (PMBOK Guide)

As a Project managers, We shall think of two types of quality: The first is project deliverables (product/service) quality and the second is process quality.

Project deliverables quality is highly affected by the process quality. Therefore, applied processes in the project should be defined very clearly and improved regularly. ISO 21500 can supplement ISO 9001 for quality management, especially in the area of continuous improvement: Fulfilling the necessary and wanted improvement processes in operations with minimal disturbance of the production and service processes.

Quality is an important subject group, applied at planning, implementing, and controlling process phases during the Project Life Cycle.

Projects aim meeting quality objectives like scope, time and cost objectives. Generally, at the planning phase, quality requirements needed to meet the project objectives are clearly defined under ”Plan Quality” title. But the same importance is not given to the clear definition of customer quality needs.

At the planning phase of project, Quality Management Plan should be prepared and then, executed as the project progresses.

Quality management plan is a part of Project management plan, consolidating all the quality information.

A quality management plan should contain the following parts:

• All steakholders’ roles and responsibilities should be defined in the project quality activities

• Standards and relevant documents, checklists, processes, organizational quality policies and processes, environmental factors (regulations, ethic rules etc.) should be used for meeting the quality requirements

• Tools, techniques and resources necessary to achieve the relevant standards

• Methodologies, techniques and resources to implement the planned systematic quality activities

• Detailed definition of activities for controlling quality, such as tests, reviews

• Detailed definition of activities for assuring quality, such as internal or external audits

• Timetable of quality activities, e.g; reviews, tests before end of phases

• Quality control measurements e.g; number of defects, review findings trends

Quality Management Plan is prepared with plan scope process (define scope, create wbs and define activities) simultaneously, thus quality activities can be handled together with subsequent planning processes which are time and cost planning. At the end of the planning phase, Quality Management Plan as a part of the Project Management Plan is approved by sponsor and shared with all relevant steakholders.

At the subsequent phase of project, If changes occur in the project plans, the quality management plan should be updated as well.

Finally, planning quality is major step for assuring quality, consequently, project success, customer satisfaction, and reputation.

References:

ISO 21500 Guidance on Project Management a pocket guide

PMBOK® Guide 5th Edition

CMMI® for Development, Version 1.3

Filiz EserThe post Plan Project Quality appeared first on PM Certification.

View Details

https://ia601503.us.archive.org/12/items/3DeliveringQualityInProjectsPartIIVFinal_20170216/3-Delivering%20Quality%20in%20Projects%20Part%20II_vFinal.mp3 Project Process Quality Managing qualitatively a project is, like said in the introduction of previous article (see article Delivering Quality in Projects – Part I), important for the success of it. The Project Manager has to make sure he/she understands and makes proper use of the project management processes, the best practices, standards and tools as used in the organisation, he/she is working for.

In a project it’s the responsibility of the Project Manager to manage it qualitatively on a day to day basis. Nevertheless we must not forget the importance of the role of the executive / steering committee in all of this. They have to take care that the Project Manager remains in line with the prescribed processes and standards and that proper tools are used. Proactively and objectively they must judge, amongst others things, the project achievements, the management of the project, the quality of products and the project risks. If discrepancies are found, they have to steer the project and the project management. This is known as quality assurance.

The executive / steering committee can take the responsibility to keep an eye on things themselves, or they can delegate it to one or more persons. These persons must be independent of the Project Manager and they must report directly to the executive / steering committee. It is obvious that quality assurance cannot be delegated to the Project Manager.

Although it’s a very important part of an organisation, quality assurance isn’t implemented in many organisations yet. And where it is implemented, it’s mostly restricted to checking if the project management documents are created or not. This is a pity, because the actual effort should be in verification of the quality of the content in those documents and thus it’s a missed opportunity to improve the quality of the process.

Can we blame the people whom are part of the Quality Assurance team? Probably not. Possibly they were promoted into this function because of a certain expertise, but most of the time they aren’t proper trained in order to be able to fulfil the job correctly.

So to increase the success rate of the project, each company will have to invest properly in a well-developed quality assurance and staff training in order to perform this function. Otherwise, the problem will continue to occur.

Conclusion No matter how you look at it, one thing is for sure, even nowadays still too few projects are finished successfully. This is also stated in the Chaos report published by the Standish group. And as long as the management of an organisation doesn’t put the focus on the quality of the management processes of a project and on making sure that the delivered products have obtained the agreed quality, projects will keep on failing over and over again. Improving the quality of both, of course, requires well trained people. And now we are finally touching the biggest problem in many organisations. Training people or employing qualified co-operators are in lots of organisations considered as a too high cost. This attitude is actually very narrow minded, because on the contrary, the reality is that on the long term, it will save lots of money for the organisation.

Danny VandeweyerThe post Delivering Quality in Projects (Part II) appeared first on PM Certification.

View Details

Perspectives of quality As a Project Manager you must be aware that, in order to achieve quality in projects, there are always two perspectives to it. And both of them must be taken into account. The first one is all about the quality of the product to be delivered (the tangible result or service). The goal here is to identify which quality the customer’s exactly expects and how the customer will accept the product(s) at delivery (i.e. what are the acceptance criteria). Knowing this, the project should be set up in such a way that these expectations can be achieved.

The second perspective relates to the quality of the process used to manage the project. Figures, that we can find in the Chaos-report created by the Standish Group, shows us this is of utmost importance for the success of the project. This annual study however shows us that, time after time, less than one third of all projects are successfully completed (within the agreed time, within budget and with the agreed scope). This implies that more than two third of the projects either fail completely (not completed) or are delivered but not within the agreed time or are over budget or are delivered with a decreased scope. According to the report, poor quality of the project management process is one of the main reasons for this. Therefore this needs attention.

In this part we’ll dive into the first perspective namely the quality of the product.

Product quality For what reasons do we conduct projects? Well, the simple answer here is that a project is aiming to make a change within an organization. This is accomplished by creating or purchasing new products or by improving existing products. These will help the organization to achieve certain benefits. We should consider ‘products’ in the broad sense of the word though. In addition to tangible products, such as for example a document, a software package or a packaging machine, we also consider non-material things, such as a modified process, etc.

Each of these products are linked to certain quality expectations. Expectations, understandably, from the customer’s point of view.

This means that we initially should, together with the customer, decide upon the scope of the project and the quality expectations. These we will translate into acceptance criteria, which will serve as a quality guideline during the production of the products and as a regularity tool to check that the final products meet the expected quality.

It is beyond doubt that the sub-products which we have to create or purchase, also must meet certain quality criteria. These are ultimately expected to contribute to the overall quality, as expected by the customer. It is also important to take into account that during the project, the scope can change and hence possible changes to the quality expectations and acceptance criteria are necessary.

In order to fulfil and control expectations and acceptance criteria, we best make a product descriptions for the final product to be delivered and for all sub-products. It should include the quality related issues (criteria, control methods, tolerances, responsibilities, etc.).

Eventually a quality register will be drawn up. Its primary aim is to have a list of the products and their planned quality-related activities. The second objective is to monitor if these activities actually were performed or not. For the different stakeholders of the project this register provides key audit and assurance information (what was planned and what was actually agreed upon and executed?):

• for the team leader or team members as input for the quality activities
• for the project manager as control whether the activities were performed or not and what the results were
• for quality assurance as means of control towards the processes and methods
• for the steering committee that the quality, the customer expects, is actually achieved

Not to be forgotten in all of this is that at the start of the project even so a quality strategy needs to be determined. In many cases, this can simply be taken over from the quality plan of the organization. However, not all organizations hold such a plan yet. In that case, it’s up to the Project Manager to work with the steering committee to determine the appropriate strategy for the project. Such a quality management strategy describes, amongst other things, the quality standards, procedures, techniques, and tools that will be used in order to guarantee the quality of the products.

Before delivery of the final product. The acceptance criteria, determined at the start of and possibly changed during the project, will be used to acquire the customers’ acceptance, meaning that de customer confirms that the delivered end product fulfils the expectations.

In the second part of the article, the quality of the project process will be discussed.

Danny VandeweyerThe post Delivering Quality in Projects (Part I) appeared first on PM Certification.

View Details

https://ia601506.us.archive.org/6/items/5QualityProcessesAndProcessControlForInterfacingBetweenDifferentPartiesVFinal_201702/5-Quality%20Processes%20and%20Process%20Control%20for%20Interfacing%20Between%20Different%20Parties_vFinal.mp3 In large-scale EPC (Engineering, Procurement, and Construction) projects, civil and facilities works and systems works are usually under different contract packages. It creates a lot of interfaces, which need to be coordinated between, the different parties. Examples:

Civil structures, access, wholes and penetrations, manholes, raisers, cableways, M&E interfaces, centralised AHU, SCADA, CCTV etc.

In large-scale EPC projects, the contracts with its scope and specifications may be not accurate or detailed in all the points. Changes occur in the course of the project. Remaining questions during the design and construction phase about “who is doing what,” or “is it a VO or should it be covered in the original contract scope,” may have changing answers over time. The better the coordination during the contract and design phase, the fewer the VOs and problems during the construction phase. These open issues and questions are usually coordinated and answered during regular interface meetings between the concerned parties.

However, these meetings require a strong and impartial facilitator. This is to ensure the interface problems are clearly identified and understood. Eventually a solution is agreed upon and the party is nominated for implementation. May be a VO is required and an instruction to the responsible party has to be issued. It requires further close monitoring on the implementation of the solution to ensure it is done on time and as agreed. This process from identifying the problem until the solution is implemented to all stakeholders’ satisfaction, is a key performance indicator and is most of the time on the critical path. In other words, if this quality and change process is not closely monitored with management attention, it will delay the project and is used to excuse LADs.

The Consultant and/or the Engineer of the project usually plays this facilitator role and has to provide clear fast instructions and pick up the issues if not solved. Even if one contract party is appointed with the responsibility for the overall integration, it still requires the facilitator due to the fact that the individual contractor cannot issue instruction to another party. It is also questionable how impartial the nominated party for the integration really is. Hence, the consultant and Engineer has to step in and take the lead to resolve the issues.

So how does one do that? Here some ideas and best practices to coordinate such interfaces:

• Because it concerns different contract packages, a detailed issue list or database is required. It must be possible to print and officialise the topics under discussion. The database should include pictures or drawings to clarify the topics and reduce ambiguity.
• To measure the time from the day of the problem discovery until the final resolution as a KPI, the date of record, due date and completion date has to be included.
• The facilitator must ensure that due dates are kept to avoid slippages in the overall project timeline.
• Interfaces identified during the contract and design phase should have a written and signed interface coordination form – ICF.
• Each party should nominate a single point of contact for clear communication channels. Otherwise it is too easy to give excuses of data or information not received.
• It is important for the facilitator to be impartial and to keep the same standards for all parties.
• The facilitator needs to have strong leadership skills, knowledge of all contract packages and the empowerment from the employer to make technical and commercial decisions during the meetings.

In summary, if you can accomplish this list, you can be sure to enjoy more smooth communication and processes between parties.

Peter WyssThe post Quality Processes and Process Control for Interfacing Between Different Parties appeared first on PM Certification.

View Details

https://ia601501.us.archive.org/29/items/7HowToSuccessfullyHandleProjectSnagsVFinal/7-How%20To%20Successfully%20Handle%20Project%20Snags_vFinal.mp3 We are currently doing the final tests of our new Open Item Database. This is a feature-rich, yet simple tool for EPC (Engineering, Procurement, and Construction) projects to record and manage open items, and more specifically, project snags.

Why do you need this database? From our experience in EPC projects, snag management can be very painful. This happens especially towards the end of the project when relevant stakeholders have gone and some severe project snags need closure, but keep in mind that it may be difficult to find the exact root cause. But wait… there is more!

A typical EPC project is complex and usually consists of a large undertaking. Most of the time all work packages and activities are planned using professional tools and the project teams carry out the activities in the work packages. However, during the project, there will be issues, comments, project snags, or even faults and defects. The question is how can these managed? What is the best way to manage these issues? Usually the traditional first thought is to manage it in an excel-sheet where somebody updates it regularly. As issues and snags are cleared the excel sheet will reflect this. Typically this person managing the excel sheet will be the QA/QC department or person. The management of these items are essential and it shall not disturb the ongoing project activities. Clear categories are the key for managing these items besides a clear detailed description.

How do we differentiate open items?

• Comment
• Issue
• Snag
• Fault
• Defect

In general for each open item, the most important part is a clear description of the topic and where it originated. The worst thing is to have an open item list at the end of the project without a clear description. That’s when it becomes really difficult to close items because assumptions may be made, people involved aren’t clear on what is needed and the client may not be willing to sign-off on the project due to all the pending issues.

In many cases, the open item is a comment which may be one or more of the following:

• stakeholder opinion which needs to be addressed
• a drawing or document
• or just to say “yes sir” with an answer “noted”

If this is completed the item can then be closed. Comments are important to record, but note that it may be just an opinion or an idea but not more. Ideally, comments should be dealt with in the regular meetings and in meeting minutes. It can also help to include comments in the database for active management and closure of the comment.

If it is a major issue that requires more than a simple “noted” from a stakeholder, then it is more serious and has to be resolved. An issue on the table has to be analysed carefully to understand the the root cause. An action plan needs to be initiated and executed to close the issue. Issues are typically internal open items, which need follow-up. Again, active management and issue closure is vital so that the remainder of the project is not effected.

How and when do you spot snags? A snag is typically raised during an inspection either from installation inspections, FATs, SATs or other Client inspections. In EPC projects, the collection of snags it is called a snag list or punch list. With this database system for open item management, these so-called snags will be analysed when entered into the database and given the right category. Is it really a snag or is it just a comment? This may simplify the follow-up and sign-off on the open item. It looks better in the statistics if you have 7 comments and 3 snags out of 10, instead of 10 snags in your report.

What is the difference between “fault” and “snag?” The definition of fault is similar to snag, but a fault carries more weight and it clearly indicates a mistake, either as a single incident or a more complex system fault. A fault has to be fixed. Faults typically arise during system integration:

• if interfaces do not work together,
• software faults are linked,
• a cable fault needs to be managed to make the system work again.

For instance a cable fault can have a severe impact if it is a long and substantial cable and due to contractual requirements it is not permitted to join cables. Hence the whole cable needs to change. It requires a clear follow-up and fault management with the database.

What is a defect? A defect can occur before project completion, but it can be an effect of an issue, a snag or a fault that causes a defect. During the defect liability period, (DLP), a defect needs immediate follow-up by the contractor. Under normal circumstances, the defect is to be fixed by the contractor free of charge during DLP. If the contractor can prove that the defect is caused by wrong operation or other influences not within the contractors control, the contractor can still fix it, but it can be charged back to the Employer.

All the above incidents and open items need proper documentation and follow-up. The better it is managed, the faster things can be closed and the cost reduced. For a large-scale EPC project the amount of open items easily exceeds the 4 digit numbers. Therefore, to manage it in a database with clear references, evidence based on pictures, videos and other records will be of tremendous value.

If you are a new Project Manager, it would be great to start making this process a habit to better set yourself and your team up for success!

Peter WyssThe post How To Successfully Handle Project Snags appeared first on PM Certification.

View Details

https://ia601507.us.archive.org/22/items/4IntegratingQualityPlanRequirementsIntoYourTimelineVFinal/4-Integrating%20Quality%20Plan%20Requirements%20into%20Your%20Timeline_vFinal.mp3 Integrating Quality Plan Requirements into Your Timeline.

In many projects I have the honor of working as a PMC (Project Management Contractor) and System Integrator with my team.

I am currently working on a project where I fill these roles and as this particular project unfolded, I noticed something interesting: this was a large scale and complex project which needed to be delivered on a specific date (as with most projects). It must be fit for the purpose and safe to operate while be ready to turn over to the end users within a stipulated time period.

In order to achieve that quality requirement, a comprehensive quality plan was established to define the procedures for design submissions and approvals.

To date, all is going well. However, in the planning of the activities and the daily work plan, the quality plan has been almost completely neglected. This can happen in projects especially when great significance is put upon the timeframe; we get so involved in the timeframe we can forget about the quality plan that has already been completed!

The timeline in this project incorporated the time to execute the individual working packages and its tasks, but the time in advance to submit the design documents and drawings (including the necessary review meetings with the consultants and the end-user) were not calculated at all!

In order to perform a task, a design document and a methodology statement is required which of course is approved for construction by the consultant.

Even if the task is just one or two days, the documents are required to fulfill the quality statements, as well as to obtain access to sites which are in operation already. However, to draft a document and a drawing and to create the method statement, this task requires somebody who has the necessary skills to do that.

Additionally it takes time for the submission to the consultant, the end-user and obtain the approval to proceed. Depending on the job size, it can take about 2 weeks to even a few months. AND this wasn’t calculated in the timeline. What may look like a small oversight can really add up in the final stretch of a project. If this time is not included in the project timeline, it can be assumed that the project will be delayed or will have some difficulties and challenges.

In large projects, the design has typically its own design phase and implementation comes as soon the design is approved.

However, different design packages have different completion times and due to the approval process, the original planned sequence might be jeopardized. With that, new documents need to be written and then need approval to accommodate this new sequencing. Adding a time cushion to your projects can be a wise thing to do, but also knowing WHAT, WHERE and HOW LONG a time cushion should be is of the upmost importance.

Quality is important and for EPC (Engineering, Procurement, and Construction) projects, proper procedures are required. However, it takes time and knowledgeable resources to support that process.

For example, having engineers who are the specialists for the job but do not follow the quality process (perhaps because they are not familiar with the quality process or simply overloaded with design/engineering) may be something you need to look out for.

Another example is also having a project where there is not a systems engineer who is nominated to facilitate the engineering process with the consultant and end-user to obtain the approval, then issues and challenges in the project is predictable.

The experienced Project Manager will raise this issue and include time and adequate resources for this engineering and design approval facilitation throughout the project. So what can you do to ensure that quality plan requirements are included in your timeline?

Make it a practice in every project you do to double and cross check your work so that your project goes as smooth as possible while within the stipulated time frame. Again, not everyone in the team will look out for this, and may not even know to look out for this, so it is your job as the PMC and the systems integrator to set everyone up for success…including the timeline!

Peter WyssThe post Integrating Quality Plan Requirements into Your Timeline appeared first on PM Certification.

View Details

https://ia601505.us.archive.org/31/items/8TimeVs.QualityInProjectsVFinal/8-Time%20vs.%20Quality%20in%20Projects_vFinal.mp3 Time vs. Quality in Projects.

As a Project Manager, I am sure you have dealt with this issue before. To either get the project completed on time with a few kinks in it or finish a bit later but with little-to-no kinks. While many people would generally say quality is more important, there may be instances where time is actually more important. Why? Well each project gives rise to it’s own unique set of issues and challenges. Here I relate one of my projects currently ongoing and why quality does indeed work best for this particular project. But again, each project is different and knowing which one applies better for the situation at hand is important. How important? Choosing rightly can greatly effect the continuity of a project.

Currently I am in a project where the as-built drawings have to be completed by a specific date as per the contract. While there is nothing wrong with having an end-date in mind for completing the as-built drawings, in this project we are talking approximately 25 thousand drawings not including the Operation and Maintenance manuals. That’s a lot of work. And while it can get done, getting it completed in the stipulated time-frame is a feat in and of itself!

To deliver this magnitude of as-built drawings within a period of a few weeks, including the review and submission process, it is a tremendous burden to the process control teams who perform the updates of the drawings. Typically the drawings which are used for construction are just re-numbered into as-built drawings without the actual checking in the field if the system has been installed as per drawing or if there are changes, hence we call these drawings ‘built.’

In my opinion, the quality of the as-built drawings should have the priority before the delivery to the client or end-user. Even if it takes one month longer to produce quality as-built drawings, it is and will be worth the wait. It is in the Client’s interest that these drawings are reflecting the system as it is built and performing in the field and not necessarily as it is designed. Here, it is my opinion that quality should come before time. After all, these drawings are sort of like the foundation of the project!

Every project is different, but with something as important as this, it is critical to have it done rightly first. Why I am stressing this so much is that when there is an extension to the current project, i.e. phase II, or upgrade of the current system etc, if the as-built documentation is not correct, the new project is already planned to fail as there are wrong assumptions and interface issues. In addition, the maintenance and trouble shooting of the operational system is difficult and will cost the Client a lot of money to correct the as-built drawings. Money that they may or may not have.

Concluding the above, I suggest that the operation and maintenance manuals are essential before project completion to train the Client or operator for revenue operation of the system. However, at the end of a project there are so many parallel activities ongoing, that it is almost impossible to provide good quality as-built drawings. In other words, we need to take care of the as-built drawings now!

A drawing master-plan is required to reflect the essential drawings which are required for operation and maintenance and to be completed at the practical completion of the project, while the other drawings can be finalized after the practical completion within a specified time of course, but without negative impact to the certificate of practical completion or penalties as the quality of the as built drawings is more important than the delivery date for it.

The work package of as-built delivery even after the practical completion means that there will be resources required which need to be calculated as costs of the project including the required infrastructure to deliver the drawings. However, this typically goes together with the Defect Liability Period which need to be factored into the project anyway.

That being said, for this particular project and the phase I am in within this project, quality trumps timeliness. I am starting from the foundation of this project, and if the foundation isn’t set right there will be a lot of problems with the rest of the project. However, I would love to hear your opinions. Each project gives rise to new challenges and issues~ what are your thoughts? Is quality or time more important here and why?

You may be asking yourself, “Where would time ever come before quality?” Well I do have an example, but that is an article for a later date!

Peter WyssThe post Time vs. Quality in Projects appeared first on PM Certification.