I'm a PM with a background in implementing IT projects, programs and PMO's in the financial services and federal government industries. I've recently been hired to work at a biotech firm to upgrade their pm framework, train pm's and implement a global PMO.
There are some similiarities between the IT divisions I've worked with and Biotech in that people (scientists) have been promoted to Project and Program Manager roles without really any formal training in project or program management. This was also my experience early in my career where developers or business systems analysts were promoted to project manager positions without having any real pm experience or education. Also obvious similiarties are that you need both a project plan and a project schedule. Where I would like some help than is maybe not necessarily in the project lifecycle but the biotech equvilent of the SDLC... Know what I mean? I'm guessing that a biotech team's requirements are not going to be as detailed or as long as say ERP requirements (do you think that is a stupid assumption?) but their DESIGN and DEVELOPMENT phase are going to be different - I mean, it's not like you can just write the code for the cure to cancer... Aside from this obvious difference, what am I missing?
I wanted to see what was out there on the web as far as helping scientists transition into the PM role and also get some lessons learned from training scientists to be PMs, implementing PMOs at biotechs, etc... however - my google search has not turned up much. The closest I could find was the pharmaceutical group on this site... Anyone have any ideas on where I could go? If not, any input from your own experiences is apprectiated.
You can find standard phase-based guides for many different types of pharma projects. For FDA approval, there is a standardized language for Phase I, Phase II, Phase III, and Phase IV testing. Each phase has a specific meaning, expected milestones and regulatory meetings, and so on. If the company does not have something like this defined already, you should work with your regulatory experts to document what they expect from each phase. If they do not know what you are talking about, mention to them the testing for First in Man, side effects, efficacy, large-scale testing, and post-approval testing. Someone at your company should know about these phases.
You might be working with "phase 0" development, which is the theoretical research phase, done with testing in animals or sometimes just computer modeling of different compounds. This work is much less structured, and can be very hard to plan end-to-end.
Give us some more background on your problem area, and we might be able to give more detailed information.
(I also came from an insurance, brokerage, and IT background, and recently began teaching project management to audiences that include clinical trial managers. It is a fascinating practice; I am sure you will get a great education from your new job.) Saving Changes...
So even though we are biotech, the FDA approval process may be an overkill. In the majority, we do not create items that need to be FDA approved. Think reagents, tools, tests, etc...
The company has created (IMO) an overly complicated process (consultants came in years ago, rolled it out but since then, not much support, no training to speak of, some "upgrades" but done by people that maybe didn't have a strong pm background?) that is similiar to an SDLC. Compounding the situation is that in general, most of the folks here do not understand the difference between an SDLC (I don't know the biotech equivelent name) framework and a project lifecycle framework.
I'm guessing that a biotech team's requirements are not going to be as detailed or as long as say ERP requirements (do you think that is a stupid assumption?) but their DESIGN and DEVELOPMENT phase are going to be different - I mean, it's not like you can just write the code for the cure to cancer... Aside from this obvious difference, what am I missing?
I wanted to see what was out there on the web as far as helping scientists transition into the PM role and also get some lessons learned from training scientists to be PMs, implementing PMOs at biotechs, etc... Saving Changes...
Yes, the FDA-based stages would be overkill. The whole purpose of those stages is to take a known compound through different approval stages. You are doing true product development, without the need for such extensive controls.
I would recommend putting aside the SDLC concept, putting aside the pharma stages, and using straight deliverable-based WBS. When people come to project management from software, they tend to want there to be some sort of standard for the top-level of the work breakdown structure. They want an SDLC.
In reality, an SDLC is only useful if
1. It describes the work you do accurately
2. Everyone standardizes on it
I really like doing all my project planning based on deliverables, not phases.
If you are doing reagents, tools, and tests, you might wind up with a very different breakdown structure for each one.
For reagents, there might be the following major deliverables:
-Candidate Reagents List
-Required Outcome Spec
-Reagent Tests
-Final Reagent Selection
For tools you might have something more like an SDLC, with requirements, design, specification, construction, and production. Unlike software, most physical design and production does not go through a test-and-fix phase, because that would be too expensive. Testing is usually built into each stage (requirements, spec, production, etc.).
If you want more guidance about how to do this, take a look at the PMI Work Breakdown Standard. It has some good examples and good measures of quality for a WBS. I have a copy and I refer to it regularly when I am working on projects that do not have standardized SDLC or phase names.
I recommend getting away from the SDLC analogy. It sounds like it is just not working. I worked in IT areas that did a lot of hardware deployment and off-the-shelf software deployment, and they also found that the SDLC framework was more trouble than it was worth. They moved to deliverable-based planning, and then they slowly built their own phases and standard methods, based on what actually helped them manage their projects better. Saving Changes...
