TECHNIQUES TO QEHS
SUMMARY
This paper documents the use of the project management (PM) methodology to implement QEHS in an organi-zation. A quick overview of PM is presented, and its application to a QEHS program is discussed.
KEY WORDS
ISO 14001, project management, work breakdown structure
INTRODUCTION
Project management is a technique to take a complex project and break it down into smaller tasks that can be tracked and managed to successful completion. This paper will explore how to use these tools and apply them to qual-ity, environmental, health, and safety (QEHS) projects, including registration to the ISO 14001 standard.
HISTORY
Project management has been considered a formalized methodology in engineering and defense industries for almost half a century. Project management, or PM, has been used to manage a variety of projects including small, almost task-level assignments, as well as complex, multi-stage, multi-timeframe programs. The most famous use of PM in recent years is the Mars Explorer, where the unmanned vehicle maneuvered around the surface of Mars with-out mishap as a direct result of issue and problem elimination, risk mitigation, and redundancy planning.
PROJECT MANAGEMENT DEFINITIONS
The following definitions are taken from the project management body of knowledge (PMBOK). These are gen-erally recognized definitions in the industry and have not been formally accepted by the CE/ PM Council at this time.
Project: Temporary endeavor undertaken to create a unique product or service. Temporary: Definite beginning and end.
Unique: Different in a distinguishing way from similar products or services.
135
Mary F. McDonald, CQA President/Principal Consultant Individual Solution Options/Quality
Services (ISO/QS), Inc. Austin, TX 78739
Tel: (512) 282-0181
Project Management: The application of knowledge, skills, tool, and techniques to project activities in order
to meet or exceed stakeholder needs and expectations from a project.
Stakeholders: Individuals and organization who are actively involved in the project, or whose interests may
be positively or negatively affected as a result of project execution or successful project completion.
Project Manager: Individual responsible for managing a project.
Program: Group of projects managed in a coordinated way. Programs usually include an element of
ongoing activity.
Process: A series of actions bringing about a result.
Project Management processes: Processes concerned with describing and organizing the work of projects,
generally falling in one of the following groups: initiating, planning, executing, controlling, and closing.
PROJECT MANAGEMENT METHODOLOGY
How can this powerful tool be used in QEHS? This first step is to understand PM itself. It is broken down into various phases that ensure no critical steps are missed. These can be categorized into opportunity selection, defini-tion, planning, execudefini-tion, and closure.
The zero phase, opportunity selection, involves review of the proposed project at its outset to ensure that • The opportunity is identified.
• An analysis team is put in place.
• The analysis is done (with information available to date).
• Opportunity selection is accomplished via review of the market, company strategy, financial commitment required, resources, risks, and technology.
The first phase, definition, includes definition of the project organization to undertake the project, as well as whom the stakeholders of the project are. The project sponsor, team leader, and core team are all identified in the def-inition phase. The project objectives should be clearly defined, which may include establishing a stakeholder list, deriving the needs/purpose statement, establishing deliverables and benefits, and defining the project approach and timescale. All risks should be identified to determine what these risks are, and they should be quantified by appro-priate means. The output of this exercise is the development of a risk management plan. The scope of work for the project is laid out with all information to date, including project constraints, a specification list, and critical success factors, as well as the benefits, skills required to implement and maintain. Risks, costs, and scope are all laid out in the definition phase.
The second phase, planning, involves the detailed work list, generating as a work breakdown structure, or WBS. From this WBS, a detailed project schedule is laid out (typically in a Gantt or PERT chart format, often as a Microsoft Project file). Resource and cost analysis is performed, and trade-offs that are necessary to achieve the critical success factors are optimized. Based on these decisions, the risk assessment is updated, and the project plan is signed off as preparations to implement the plan are undertaken.
The third phase, execution, includes plans to organize and implement the product launch, regular progress reports to the sponsor and key stakeholders detailing any variances, including analysis of how these variances occurred and if there is a recovery plan. Problem solving and issue management are critical skills at this stage, and are used to keep the stakeholders, sponsor, and team apprised of any changes to the plan. Status reporting and risk assessment updates are the key mechanisms for keeping all interested parties involved, as well as regularly scheduled meetings to moni-tor and track progress. These meetings often include updates to the schedules, plans, and project timelines, as new information becomes available, and review of the risks to assess whether they require update. Problems are identi-fied, mitigated or solved where possible and issues are resolved based on knowledge, testing, or experience.
The fourth phase, closure, starts with the derivation of the handover procedure. How the handover will be accom-plished should be clearly documented, including who has what responsibility, and whether those responsibilities are shared at all or not. Both the group handing over the project and the group who receives the project should agree on the timing, deliverables, and assignment of responsibilities. Identification and staffing of follow-on projects is also detailed at this time, as well as customer sign-off. A closeout meeting is held to document all closures, and a final report is prepared that includes evaluation of the project and recommendation for future projects (lessons learned).
PROJECT MANAGEMENT APPLICATION
PM applications are as varied as the practitioners who use the tool, but for the purposes of this discussion, we will limit ourselves to the QEHS discussion. What is the best way to use this technique for QEHS implementation, and what are the resulting benefits?
QEHS implementations typically do not start from ground zero. Most companies integrating their systems have various rules, regulations, codes, standards, and laws that they are already complying to; they may have procedures in place that define how certain aspects of their QEHS systems are run; and they may have a system in place infor-mally already. So how can we use this methodology to formalize our system?
To begin with, let’s look at the system we have defined above, and modify it for our uses. We will consider both a system in its infancy, and a system that is somewhat developed by not fully formalized (no ISO14001 registration yet, as an example).
FOR SYSTEMS JUST STARTING OUT
The opportunity has probably already been defined for you; QEHS is often “mandated” by stakeholders, man-agement, customers, or government. Once this is done, the rest of the methodology can be implemented (team iden-tification, analysis, and opportunity selection).
The stakeholders for QEHS are varied. They can be the local communities where your company does business; the final consumers of your product; your customer (if they are different than the final consumers); local regulatory and law enforcement agencies, as well as state and national agencies; your stockholders, board of directors, or own-ers; the employees of the company; and perhaps others that are unique to your industry or sector.
How can you serve all these stakeholders, especially when their wants and needs are almost certain to be in con-tention with each other? This is where the opportunity selection tool comes in handy. By reviewing the market, and company strategy for penetrating that market, as well as other objectives defined in the strategy, the financial com-mitment can be determined in order to understand the resources, risks, and technology necessary to implement the strategy fully.
The definition phase is an ideal point to define the organization of the project that needs to be put in place to implement the QEHS system fully. What types of skills do you need for your project team? What percentage of their weekly time? How long will you need them for (duration)? How about the sponsor(s) and core team members? Who are they and what function do they perform in this project? The stakeholders need to be defined at this stage; and their reason for being listed as a stakeholder should be evident or documented.
Once this is in place, the needs/purpose statement is drafted. This statement should lead to establishing the ben-efits of implementation, and the deliverables that are a result of the project implementation. For QEHS, these bene-fits and deliverables may include:
• A reduction in emissions • Registration to ISO14001 • Improved community relations • Improved product quality
• Improved use of raw materials (pollution minimization) • Improved safety for the employees, community, or company • Better controls on processes from a health/safety perspective
The project approach (how you plan to implement this project) and timescale is derived, based on who the core team is, how it will be done, and what the time constraints will be.
The risk management plan, which is a summary of all the identified risks of the project, is derived to quantify the risks associated with the project, to minimize or mitigate them wherever possible, and to determine if the risks are acceptable. An unacceptable risk is defined as one that has a medium to high probability of occurrence and a high impact on the project. If there is an unacceptable risk, it must be mitigated (reduced in either impact or probability of occurrence) before the project can go forward.
Once the risks have been mitigated to acceptable levels, and reduced where feasible, the Scope of Work (SOW) is derived. This SOW defines the project constraints, derived or applicable specifications, critical success factors, and assumptions on one document. This SOW is reviewed periodically to ensure timeliness of the document.
Some of the project constraints may include:
• Insufficient manpower to complete on expedited basis • Competing priorities for implementation
• Budgetary considerations
• Inadequate space to implement completely Some applicable specifications may include: • Government or regulatory requirements • Internal product or process specifications • Standards requirements
Some critical success factors may include: • A% reduction in emissions
• B% reduction in accidents • C% increase in yield
• D% increase in awareness of safety Some assumptions may include:
• All assigned personnel are available for the duration of the project • All necessary funding is approved
• Regulatory/governmental regulations will not change during project timeline • All personnel will receive training on new initiatives
For the second and largest phase, planning, major activities include the derivation of the work breakdown struc-ture (WBS), definition of the initial schedule, costs analysis, risk assessment update, and sign-off of the Project Plan. One of the first things that a QEHS professional should do is to set up the project files. These files will be the location of “master copies” of all aspects of the project. These files can be physically located in several different areas so long as we have a listing (table) of the location of each document. In addition to the work derived as part of this project, the project file should include all of the information presented to the program steering group (PSG).
Planning the WBS requires that an initial meeting be held to get the input from the various responsibilities, such as the sponsor, core team, leader, and any other experts who can make relevant contributions. The planning meeting is a good time to define the project timescale, business need deadlines, and management support. This meeting is crit-ical to ensure that the project objectives are clearly understood, the measurables and benefits are defined, and that the risks have been adequately defined.
One of the mistakes that a QEHS professional may make is to try to rush this activity. The only way to effectively plan this project is to devote the necessary time to it to make it a useful plan for follow-on activities, as well as pro-vide a solid base for the project to be built upon.
Two different methods may be used to derive the WBS: top down planning, or bottoms up planning. Each methodology has its advantages and drawbacks, but bottoms up planning is usually recommended although it is more time consuming since it is likely to be more accurate and less apt to lead to serious omissions or errors in estimating. The first step is key stage identification (KSI). KSI involves the entire team, who use their collective experience to identify the work as a list of tasks. Once all the tasks have been identified, they are grouped and titled in order to identify subgroup headings. The subgroup headings become the key stages, from which everything else is derived.
The second stage is to establish the project logic. This is done by organizing the key stages into a logical sequence (What must be completed before I start this work? What can be done next now that it is completed?) and getting agree-ment from the team. The result is the key stage dependency list. The list includes dependency and successor activi-ties. Once this list has been generated and agreed to, it becomes the fundamental data for the computer scheduling program.
The work breakdown structure, when complete, may look like the following: Project
• Key Stage AA • AA-1 • AA-2 • AA-2.1
• AA-2.2 • AA-2 . . . • Key Stage AB • AB-1 • AB-1.1 • AB-1.2 • AB-2 • AB-2.1 • AB-2 . . . • Key Stage AC • AC-1 • . . .
At this stage, it is useful to remember that the WBS does not yet have tasks assigned to specific personnel, and it is not time-based. The WBS must be updated as new information is discovered or as assignments are carried out. The WBS is now ready to have responsibilities assigned for each Key Stage (but not the sub-stages yet). The pro-ject leader is responsible for ensuring that the “right” people are assigned the stages; that there is no imbalance of work whenever possible, and that the employees accept the role of key stage owner. There can only be one key stage owner assigned, even if the KSO assigns someone else to manage the stage with him/her.
Once the tasks have been defined and assigned, the QEHS professional now needs to ensure that durations for each key stage is assigned. These key stages may have dependencies (cyclical or periodic filing requirements, prede-cessor assignments, etc.) that will need to be taken into account when laying out durations. Durations should take into account the size of the task, the effort required to complete, the duration of the effort with no predecessor assign-ments, and the schedule. Each KSO should keep a record of their estimates for all tasks in their key stages, and a copy should be filed in the project file.
Once the schedule has been initially laid out, you can start laying out the critical path via critical path method (CPM) or the program evaluation review technique (PERT). CPM can either be
• Finish to start • Start to start (paired) • Finish to finish (paired)
The critical path is defined as the longest path, or the least flexible path. Any slippage extends the total project time (TPT).
Ensure that your project does not have any loops (one assignment always lead back to a previous assignment) or any dangles (an assignment has an output that is not used by any other assignments, and does not signal completion of any tasks).
Once this is complete, then the GANTT chart can be generated. The chart should actually be a family of charts, to assure that the schedule is easy to understand. One method is to list only the key stages on one chart, and each key stage is listed, with its sub-tasks, on a separate chart. The family of charts, taken together, is the completed GANTT. Once this is done, the project costs are estimated, the resources requirements are listed, and trade-offs are opti-mized. Information is updated in the GANTT to include these new inputs, and the project initiation document (PID), the risk log, and project issue log (from Phase One) are reviewed to determine if updates are necessary.
Once this is complete, we are ready to prepare to implement the project. Preparation includes the definition of project milestones and phase gates. These are defined by significant task completion, or completion of all require-ments of a phase.
How do we apply this to a QEHS project?
Once the project file has been set up, the team must work on implementing the WBS. The WBS planning meet-ing is scheduled, and the key stages are defined. Remember to allow enough time to complete this work thoroughly! Once the key stages are identified, the WBS is begun.
The WBS key stages may include, in no particular order: • Implement ISO14001
• Determine interfaces for ISO14001 and existing regulatory/ legal requirements • Etc.
Once this is complete, the project logic is derived and the work is scheduled based on the logic. Detailed sched-ules are put in place, including the Critical Path and GANTT charts, and these are used to identify, monitor, and track progress toward key stage completion.
It is important for the QEHS professional to keep the project sponsor informed of progress and any difficulties that may be encountered in implementing this project. It is key for the project sponsor to feel ownership of the pro-ject from an overall standpoint, and to work with his/her peers to remove roadblocks and pave the way for a success-ful team implementation of this project.
Phase Three, project implementation and management, is where the project is formally launched and imple-mented. Although it may seem that we have spent a lot of time in preparation, this time was critical in ensuring that we have a carefully thought out and comprehensive plan.
The team leader, who could be the QEHS professional, is responsible for ensuring that: • The project is closely monitored and reported on
• The team performs to the highest possible standards
• The stakeholders remain committed to the success of the project • The team responds to changing needs of the project
• Plan vs. actuals are documented • Variances are identified
• Action plans to address deltas are derived
The QEHS professional should start with a baseline of the project. This is the initial project outline and timeline, and includes all assumptions made when deriving this baseline. The baseline includes methods of measurement of progress against any defined standards that are part of the control system. These may include measurements that are required from a regulatory/ legal standpoint. These measurements provide inputs for regular team meetings as well as day-to-day monitoring by the project leader.
The project baseline includes six basic elements: • Work content • Measurement • Time scales • Quality • Teamwork • Changes • Stakeholders
As modifications are made, the baseline is preserved, and updates are made via revisions to the schedule. You are now ready to organize the launch. To maximize the chances of success, you should confirm and validate the key work stage plans, the resource commitments, and the meetings schedule. Once this is done, the launch meet-ing can be held, which should include the project sponsor and key stakeholders as well as the project leader and core team. This is a milestone in the project, and can be used to energize the core team into action. The result of the launch meeting should be a clear understanding, by all involved, of what will be accomplished, by whom, and when.
Regular meetings are scheduled to track the progress of the action items being worked on. These meetings can also serve as a monitoring tool to check on overall progress, collect data, and look forward to identify risks that may be uncovered.
When tracking progress, it may be useful to: • Analyze the variance
• Define the cause • Establish the impact • Evaluate the options
• Plan the corrective actions (and document it for ISO!) • Resolve the issues
• Update plan documents • Report the progress
How often do these meetings need to be scheduled? It largely depends on your deliverables, data collection fre-quency, plan updates, status reports, and project reviews. Remember to document all meetings, including one-on-one meetings, informal meetings, stakeholder meetings (which may be part of a larger or broader review), and any infor-mal meetings which resulted in decisions.
Problem solving is a key skill required of the project leader. This professional must be able to understand and explain not only why a task or stage is doing worse than the plan, he/she must also be able to describe why a task or stage is doing better than the plan. Critical learning may result and be applicable to other phases of the project that could speed the completion date, or avoid future delays. Some of the tools used by QEHS professionals include the Fishbone (Ishikawa) diagram, the 5 why methodology, trend analysis, etc. Once the causes of variance have been established, the impacts of variance then need to be defined. Will these cause resources to be reassigned? Will the mate need to be revised? Do we need more effort? Do we need more resources? Ensure that you validate your esti-mates before presenting them to management.
From here, the corrective actions can be put in place. The options for these actions should be discussed with and agreed to by the core team to ensure that the best solution is chosen and that there is buy-in from all parties. When these actions are agreed to, the project leader then checks to see if
• Critical path has changed • Workloads are adversely affected • Milestones are affected
• New HIGH risks are exposed • Cost over-runs are introduced • Schedule slippages are controllable
And escalates outstanding issues as appropriate.
Project progress meetings are held when appropriate. Care must be taken to ensure that meetings are not being held simply because the schedule called out for one to be held; it must have a purpose and provide useful informa-tion to the attendees. One good way to ensure this is to ask each key stage owner to provide status reports for their key stages before the meeting. If no stages are ready to present significant checkpoints, perhaps the meeting is unnec-essary and status can be sent out via e-mail. If the meeting is held, ensure that an action item list is generated chart-ing what the action is, who will implement, and what the estimated completion date will be.
The project leader also has to keep the Stakeholders aware of project status. They may or may not choose to invite key stakeholders to the program steering group status meetings. If they choose not to, a defined communication method and schedule should be in place to ensure that they are being kept informed of status on a frequent (if not real-time) basis. The report to stakeholders should include:
• Project status report • Risk log
• Issue log
• GANNT chart for key stages
During this phase, the risk log should be reviewed on a regular basis, and the risk management form should be updated as required. The issue log is also reviewed at this stage to highlight unresolved issues on the status report. When all interested parties agree, the project exits Phase Three.
Phase Four deals with project phase-over and closure. It includes derivation of the handover procedures, defines follow-on projects, closes out the present project, evaluates it, submits a final report of the project, and includes a final sign-off.
The handover procedures should include definition of: • The completion criteria
• The handover checklists
• The customer acceptance process. At this stage, the project leader should check: • Completion criteria are still agreed • Deliverables are completed • Expected benefits are unchanged • Measurements are identified
• Limits of acceptability are agreed upon • Hand-over checklists exist
• All key stage level work has been completed, down to task level • Follow on activities agreed to
The actual completion of the project should only be a formality; if all key stakeholders have been kept up to date, no surprises are expected at the formal sign-off.
Follow-on projects may or may not be defined if this project has broader applicability. For the QEHS profes-sional, this most often takes the form of expansion of a pilot study to larger proportions, or broader applications.
FOR SYSTEMS THAT ARE IN PROCESS
The first step is to determine where you are in the project management methodology process. From there, it is highly recommended that the previous phases, stages, and tasks be reviewed. If you did not pull together the docu-ments required in Phase One, although you are in Phase Two, it is advisable to generate the docudocu-ments when starting since they are integral to this and later phases.
Some projects do not require the entire methodology to be implemented. For example, some projects are imple-mented based on executive decisions, and no analysis of ROI, costs, etc. needs to be done since it is approved based on other factors (such as compliance with regulatory/ legal requirements). In this case, the reason for excluding this stage is documented in the project file.
CONCLUSION
Project management is an excellent methodology for use in large, complex projects that require close coordina-tion of tasks, phases, and stages. Implementacoordina-tion of QEHS system, including registracoordina-tion to ISO 14001, lends itself well to this methodology, and can be integrated into a company’s present system with a minimal addition of process steps.
REFERENCES
Project Management Institute (PMI). 1996. A Guide to the Project Management Body of Knowledge (PMBOK). Individual Solution Options/Quality Services, Inc. (ISO/QS, Inc.). 1999. Project Management Overview Course
