Project Management: Know When to Use SOPs, and When Not To

All pharmaceutical companies have hundreds of written standard operating procedures (SOPs) for manufacturing operations and the controls of those operations. Process and product variations can never be eliminated, only controlled, and SOPs that define what operators and technicians must do, how, and when they must do it, are critical to operational consistency, efficiency and regulatory compliance. The phrase “document what you do and do what you document” is widely accepted and practiced throughout the industry.These same organizations must also execute regular and defined projects to change suppliers, introduce new products, optimize processes, change raw materials, build facilities, implement software, reduce costs or cycle times, improve customer service, improve compliance, increase manufacturing capacity and more.While SOPs are well-suited for operational activities because they are structured, repeated hundreds of times, and have no end, they may not be so for projects, which are by definition unstructured and temporary activities. The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service or results” [1]. Projects end when they accomplish their objectives and the team is disbanded. No two projects are ever alike. Even two projects to manufacture the same pharmaceutical dosage in two facilities will always be different.One might expect to find hundreds of SOPs for operational activities and no SOPs for project activities, but in reality, some (though not all) manufacturers have dozens of SOPs for projects and project activities. Why? Is it better to have detailed SOPs for project activities, as in operations? Or is it better not to have project SOPs as projects are by definition unstructured and temporary activities?Or is there a middle ground where only some project SOPs would be beneficial? I believe there is. There are situations in which SOPs can positively influence a project, but also those in which SOPs can limit a project and create frustration for team members.The problem with SOPs for projectsOne might argue that following SOPs for project activities is a low price to pay for reducing regulatory risks and ensuring project quality. But the price may be higher than that. Projects are difficult undertakings even without the restrictions of SOPs. Anywhere on earth, when an object is thrown in the air, it will always fall back to earth. Projects are not so predictable. There is no principle that dictates that a group of individuals will succeed when they are assembled as a team to execute a project and given strict instructions to follow.No public statistics are available that detail the success or failure of projects within the pharmaceutical industry. However, it has been established that all over the world, in all industries and in all types of projects, delays, cost overruns and project failures are the norm [2, 3]. Furthermore, data from information technology (IT) projects, including projects from the pharmaceutical industry, show that in the U.S. during the year 2000, 74% of the IT projects were either late, over budget, or had to be cancelled. Only 28% of those projects were on time, on budget, and met their objectives [4].One of the reasons for projects failing to meet objectives may be that project teams are unrealistically expected to follow SOPs. In my experience, not having to comply with unnecessary procedures would help many projects.A major complication is that it is simply not easy to comply with project SOPs. Project leaders and team members typically work under very tight deadlines, move at a fast pace and make quick decisions. Under these conditions, it is not hard to see how SOP requirements could be forgotten, or how teams might have to make conscious decisions not to follow SOPs for the sake of meeting their deadlines.When this happens, the project may stumble or break down and the organization may become exposed to criticism from regulatory agencies for not adhering to their own SOPs. In the last several years, not following procedures has been the leading reason for manufacturers to receive FDA observations [5]. It is not known how many of those observations were related to project-related SOPs, but it is safe to say that more SOPs make it more difficult for manufacturers to follow their own procedures.In most organizations, operational departments are well-defined and have clear power and authority structures. The roles of Manufacturing, Quality Control, Technical Services and other departments are usually well-established though organization charts and job descriptions. On the other hand, project management roles are usually either embedded into functional organizations (such as Technical Services or Engineering), or have separate organization (such as a Project Management office) with less visibility and authority than their operational counterparts. Therefore, the practice of having SOPs for most everything, which is fully justified in the operational areas, is often inadvertently extended to project areas, where they may add unnecessary restrictions and risks to projects.Finally, it is useful to note that CFR documentation requirements are intended for “production and process control” [6]. Both production and process control are operational, structured and unlimited. Projects are unstructured, limited and unique.To SOP, or not to SOP?Therefore, most project-related SOPs are not necessary within regulated organizations. Project managers must determine when SOPs are appropriate and useful, and when they are not (Table 1, below).

Table 1: When Should Project SOPs Be Used?

NOT INCLUDED	INCLUDED
Day-to-Day Activities How to obtain stakeholder buy-in How to account for change management How to execute the project	Requirement or Best Practice Testing FRSs in the OQ Performing risk analysis at the beginning of the project to identify and mitigate risk factors Validating all assays before finishing the transferring of one API Listing titles of individuals who must authorize project funding
How How to transfer one API from one facility to another How to implement a software application	What the Project Will Produce Project scope and BOD for all capital projects above a certain level Site SOPs in compliance with corporate Quality Standards Project charter

There should not be SOPs that deal with day-to-day project activities, and with how projects are executed. For example, most organizations have capital execution processes to build new facilities, or to expand existing ones. The first stage of those processes is usually a conceptualization stage in which engineers define the project scope, costs, limitations and assumptions through documents called project scope and basis of design (BOD). I believe SOPs are not beneficial for preparing a project scope or a BOD. There are dozens of variables (process, location, cost, timeline, manpower, etc.) to consider in conceptualizing a capital project. It is impossible to predict in one SOP how all of those variables will play out.Each BOD and each project plan involves tradeoffs between these variables. The project team is responsible for analyzing variables and incorporating them into its project plan, and it can do this better without the burden of SOPs. Each team should be able to define its own hows.As an example, there should not be SOPs to detail day-to-day activities on how to transfer one API from one facility to another. There are also dozens of variables (process, specifications, limitations, impurities, etc.) that the project team must take into account to execute an API transfer, and each API transfer will be different from others.But SOPs can be helpful for project activities, when they are used to convey a requirement (or best practice) or to describe what the project will produce. For example, a project-related SOP might specify that User Requirement Specifications (URSs) be translated into Functional Requirements Specifications (FRSs), that the FRSs be converted into Detailed Designs, that the Installation Qualification (IQ) test the Detailed Design, that the Operational Qualification (OQ) test the FRSs, and that the Performance Qualification (PQ) test the URSs. Those are best practices [7] that organizations might want all of their projects to follow, and SOPs would ensure that those best practices are adhered to.By the same reasoning, organizations might decide that all of their capital projects above $1 million will have project scopes and BODs and that those documents will contain mandatory sections A, B, C, D, etc. (i.e., what to do). This can be done through SOPs.Note that the above recommendations are independent of the type of system on which the projects are being run. Direct impact systems (WFI, SIP, reactors, etc.) have, as their name implies, a direct impact on product quality. Indirect impact systems (elevators, office space, etc.) do not affect product quality. There is always some overlap and the classification of what systems are direct impact and indirect impact is determined by the project teams on a case-by-case basis [7]. For both direct and indirect impact systems, pharmaceutical manufacturers should have no SOPs describing day-to-day project activities or how projects are executed. Instead, also for both direct and indirect impact systems, SOPs should only describe best practices, requirements, or what the projects should produce.It could be argued that requirements, best practices and what the projects will produce are best included in organizational guidelines, where they can be changed more easily and can be followed with more flexibility. I disagree. Usually, guidelines are not subject to the same strict oversight as SOPs (regular revisions, approval cycle), and because guidelines are followed less frequently and less enthusiastically than SOPs, their impact may be minimal. Add to this the fact that, most of the time, project managers have no formal authority over team members, and hence limited power to compel individuals to follow guidelines.SOPs can put project teams on the path to success. They just need to be used wisely, and in limited situations.About the Author

Fernando Portes, MEng, MPS, MBA, PMP, CQE, is Principal Project Manager for Best Project Management (www.bestpjm.com), which provides hands-on project managing services in the U.S. and internationally. Mr. Portes has 17 years of experience in the pharmaceutical and medical device industries, and has managed technology transfer, validation, capital, process improvement, compliance, Six Sigma, and procurement projects for 14 years, mostly at Fortune 100 pharmaceutical companies. He has M.Eng. and MPS degrees from Cornell University, and an MBA from Catholic University, Santo Domingo. Mr. Portes also has B.Eng. (Chemical Engineering, Magna Cum Laude) and B.S. (Chemistry, Magna Cum Laude) degrees from the Autonomous University of Santo Domingo.Mr. Portes is also a Project Management Professional (PMP), a Certified Quality Engineer (CQE), and a member of ISPE and PMI. He is also an Affiliate Professor and teaches graduate level project management at Stevens Institute of Technology (Hoboken, N.J.). He can be reached at 201-617-9240, or at[email protected].References

1. Project Management Institute. A Guide to the Project Management Body of Knowledge. Third Edition, 2004. 1.2.1, 4.6.
   
   
2. Morris, Peter W. The Anatomy of Major Projects. A Study of the Reality of Project Management. 1990. John Wiley & Sons, p. 7.
   
   
3. Morris, Peter G. The Management of Projects. 1997. Thomas Telford, 2nd page of Preface to hardback edition.
   
   
4. The Standish Group International. Extreme Chaos. 2001, p. 1.
   
   
5. The Gold Sheet. Vol. 38, Num. 5, May 2004, p. 1.
   
   
6. U.S. Code of Federal Regulations. 211.100(b).
   
   
7. International Society of Pharmaceutical Engineers (ISPE). Commissioning and Qualification Guideline, First Edition, March 2001, Sections 2.2 and 2.5.