Have you ever read project management standards or taken a project management course?  On paper and in a classroom, projects make a great deal of sense. There are phases and paths and deliverables and roles and responsibilities – and they all fit together snugly in diagrams and charts.  Then, you look at the pieces of your own project and think, “OK, we can do this!” Then, you find that those pieces – people, challenges, resources, business drivers – don’t fit perfectly Sometimes when you change your plans and pieces not only does your project no longer closely resemble the ideal you were shooting for…but it all starts to feel out of control.

The ideals include standards such as the stage (or phase) gate process, engineering and testing standards such as ASTM E2500-07, quality standards such as ICH Q9 and Q10, automation standards such as S88.01, and others.  These standards do have real value and are filled with real substance. Still, they are not rigid rules and require some interpretation. As Father Guido Sarducci says about commandments 11 through 20, they are really more like guidelines.

Each project is different from the start.  For example, let’s take a typical conceptual design 🡪 basic design 🡪 detailed design engineering flow and think about how it might be applied differently to different projects.  First, consider a project that entails building a manufacturing plant for a product that is in high demand with demand projected to grow for ten years and your company has a lock on the market because it owns the intellectual property (a cure for cancer or a chocolate bar that causes the eater to become healthier.)  In this case, the capital is approved for the entire project, the land is purchased immediately, permits are pulled, and your project places orders for long lead time equipment before the conceptual design phase is even complete. In this first case, you have hired engineers who are already working on each process unit’s deliverables – P&IDs, instrument specifications, electrical one-line drawings, etc.  – even though some deliverables properly belong in the basic and detailed design stages of your project. In short, while you understand your stage-gate process well, you have largely abandoned the distinctions between stages. Instead, you are focused on generating the deliverables you need to construct and test as quickly as possible. And that is OK. You are doing the right thing.

On the other hand, let’s say your company has a different project in mind that involves a product that seems promising…but there is still considerable commercial risk involved.  For example, a refinery using a process that is profitable only when the price of oil is greater that $60 per barrel or a manufacturing facility for a drug that showed good results in early testing but not good enough that there is not still some concern that it will fail late-stage trials.  It is possible that oil prices will drop and building the facility will not make sense. Or it is possible that the phase 3 trials for your drug will exceed expectations and you will need a plan in place to build quickly (or that the trials will fail…) In either of these cases, your company is only committing to conceptual design: it wants to understand costs and schedule and de-risk budget and cost issues.  In these cases, your project plan will hew very closely to what the textbook prescribes for methodically executing the conceptual engineering stage of a project: you will be just at the brink of basic design but commit nothing more until the business agrees it is important to do so.

So, two projects, two different approaches to stage gate.  The first lesson is: everything is driven by business needs.  A typical stage-gate project process, for example, that described by the ISPE Project Management Best Practices Guide, is all about spending small amounts of money in order to de-risk the efforts that will be funded by a larger amount of money first.  The degree of risk that a business is willing to tolerate and the urgency that a business feels around a given project fundamentally changes how closely a company follows the stage-gate process or a variant thereof.

The more certain a company is that a project is required, and the more urgent the requiring, the more a plan becomes driven by a “bottom-up” strategy than by theoretical standards.  “Bottom-up” means that you emphasize starting at the end and working backward. For example, if you know you have a winning industrial enzyme that has a massive market and you are definitely committed to building a new purification facility, then you focus entirely on what construction needs to successfully build from day one without regard for stage-gate (stage-gate shown in brackets):  

  • Process Flow Diagrams (Conceptual)
  • Equipment specifications (Basic)
  • A sequence of operations (Basic)
  • Civil/structural supports (Detailed)
  • Piping isometrics (Detailed)
  • Instrument specifications (Detailed)
  • Electrical one-lines (Basic)
  • Drive panels and layouts (Detailed)
  • Wiring drawings (Detailed)
  • Instrument index (Detailed)
  • P&IDs (Basic)
  • Unit boundary definitions (Basic)
  • Network architecture (Detailed)
  • Fieldbus diagrams (Detailed)
  • Loop diagrams (Detailed)
  • Piping schedule (Detailed)
  • Etc. etc.

By unit, you would focus on the whole list of deliverables for each unit from the start and probably treat the building (or buildings) as a separate unit, including HVAC.  That means that from day one you have a list of all the design deliverables, regardless of stage-gate, listed on the task list in your “war room”. It is much more efficient to do related activities together with a dedicated team that knows they have a 12-18 month mission than it is to consciously pause at stage-gate boundaries while waiting for the business decision regarding whether or how fast to proceed.

On the other hand, inefficiency is preferable to spending money that may never provide a return.  If the business requires more discipline and deliberation, then being methodical is important. It is the responsibility of a company and their project steering committee to decide whether commercial risk requires caution and adherence to practices designed to mitigate financial and technical risk or to proceed with technical rigor but a greater focus on schedule and budget efficiencies.

Similarly, ASTM E2500-07, ICH standards, and S88 and S95 require context in order to choose how best to implement them.  Other blog posts will cover these specific choices and how to make them in the next future!