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

There is a time and place for standard operating procedures in pharmaceutical projects, but good project management includes knowing when SOPs might do more harm than good.

By Fernando Portes, Principal Project Manager, Best Project Management

Share Print Related RSS
Page 1 of 2 « Prev 1 | 2 View on one page
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 projects

One 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?
    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 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
    Page 1 of 2 « Prev 1 | 2 View on one page
    Share Print Reprints Permissions

    What are your comments?

    You cannot post comments until you have logged in. Login Here.


    No one has commented on this page yet.

    RSS feed for comments on this page | RSS feed for all comments