Project Management in Life Sciences - Notes from the field.
By Richard Wood, Director of Program Management

PART - 1 “Oh, by the way…”

It’s done.
One hundred and fifty million dollars spent.  Twenty-one months of planning and construction.  Nine separate IT vendors’ managed.  One hundred and fifty staff now working in a brand new 200,000 square foot state-of-the art bio-tech manufacturing facility.  And MUSA ran the IT portion of this effort utilizing our MPMA methodology specifically designed for rapid deployment of IT projects for life sciences.  Although geared toward application and infrastructure projects for our chosen vertical, we were able to quickly adapt our methodology for a validated manufacturing facilities project. Yay team.

So how did we get there?

I’m writing up my notes from the Post Mortem we just completed.  It’s 11 PM and I’d be lying if I told you I didn’t have a glass of celebratory wine in hand while tidying up the paperwork loose ends.  ‘How did we get there’ is a great question.  At this particular client, projects seem to start the same way:

“Hey Rich,” asks the Director of Infrastructure for our Bio-tech client

“Yes?” I ask, knowing the tone of voice.

“So I just found out we’re building a new manufacturing facility at the new campus.  Got a minute?” Says the same Director.

Project Initiation had begun.

Pack up a lunch, and strap yourself into the Delorean.  With the Flux Capacitor using 1.21 giga-watts, we approach 88 miles per hour…

January, 2008

Our client just put the finishing touches on their second building at a new campus designed to bring the entire Massachusetts business unit into the same location.  MUSA is working through the details of a new Roller Bottle system (if you don’t know, Roller Bottle is a manufacturing method for cell culture growth).

My job at this particular client is running the global infrastructure PMO.  At MUSA, we firmly believe in practicing what we preach, so everybody in management also tend to have gigs as consultants.  It’s how we refine ourselves as a consulting organization and keep in step with the Life Science’s industry as a whole.

Anyway, the Roller Bottle project is humming along when I get the call into the Director’s office.

He’s got a set of architectural site plans for the new campus and I notice a big rectangle taped on it in between two existing buildings.  He points at it.

“We’re building a new Manufacturing facility. And we need to ramp up a project right now as they are in the design phase. Talk with Facilities Planning.”

So I did.

MUSA works with many partners.  We have a simple philosophy that the client needs work done and, especially in Life Sciences where outsourcing is the norm, there tends to be a lot of consulting companies working in an organization at any given time.

Two years beforehand, I met a seasoned Project Manager (Not with MUSA, but with a company we’ve worked with many times in the past) that I knew would be perfect for this new manufacturing facility project.  He’s an ex Army Ranger, and currently in the reserves.  Which means for two weeks out of every year this man willingly jumps out of airplanes.  His credentials are amazing, he has military discipline when it comes to running a project, he knew that our client had adopted MUSA’s  MPMA methodology and was very familiar with it (having trained him myself). And he’s a little crazy.

Perfect.

He and I met with Facilities Planning and proceeded to setup the project.  Within two hours, we had the charter written, the Project Initiation documentation to the IT group, a kick-off meeting scheduled and were pouring over the plans for the new building.

We were working in silence over those plans for an hour, occasionally making comments.

“We’ll need a second IDF closet on the second floor.  The cable runs are out of spec.”

“Yep.”

“They’re putting in a completely separate manufacturing system.  The Network guys are gonna have to put in a new firewall.”

“Uh-huh.”

“Those clean rooms near the bio-reactors have high ceilings.  We’ll have to run a wireless survey simulation”

“I know.”

“The building is going to be one big Faraday Cage.  Did they budget for a cell repeater system so the push-to-talk will work?”

“Yep.”

And so it went.  The move-in date was scheduled for end of Q4 2009.

Our Army Ranger partner Project Manager left the conference room with plans and I was alone to think about the big picture.  We’d developed the MUSA MPMA for Life Science system deployments.  Would it work for an entire validated facilities project as well?

When MUSA originally used a PMI model (and a Prince2 model in Europe) we found very quickly that we PMs were getting in the way of real work.  In bio-tech, where applications used in production can sometimes be only a step or two removed from the ‘basement development model’ or where scientists throw an application on a Linux PC under their desks for Mass Spectrometer analysis, there isn’t a lot of tolerance for what was perceived as project management ‘bureaucratic overhead.’

But we all know, especially in a highly regulated environment, that the PM process is critical for success.  So how to eliminate even the perception of ‘overhead?’

By using a sophisticated blend of  collaboration, task management streamlining and a unique dash-boarding system for online real-time reporting while maintaining the relationship touch necessary to get the job done.  Our PM’s manage the process and let the engineers’ just get on with it.

The process was developed for system-based projects.  Would it flex enough for a large-scale building initiative?

The short answer was yes; with some minor tweaking to our standard communication plan templates and our vendor management plan.  But more on that later.

To be continued... PART 2 - SOP Hell

Closing The Gaps in Open Source - The Latest on the Open Source Revolution
By Josh Campbell, Senior Solutions Engineer

Recently at MUSA Technology Partners we've been upgrading; we've upgraded our office, increased our staff, and decided to redesign our infrastructure to better support the pace at which we've been expanding over the last few years.  In the past we had made a conscious decision to avoid building out too much of an infrastructure, we were an extremely mobile group and tended to live on our Blackberries, so we didn't have a need for it.  Time goes on.  We've doubled and doubled again (and then some) and we now need internal support for a much larger group of people, including non-technical office staff, which means we need IT infrastructure.

Since we're a consulting shop with a major focus on Open Source software, we decided to build our entire infrastructure using Open Source products.  The goal was to take some of the available products, get them running, and then make them all work together in harmony.  The first two steps were completed relatively easily.  I'm actually quite impressed with the strides the community has made with regards to documentation and product offerings since the last time I undertook an Open Source project of this size.  While there's been great individual advances, it seems that a familiar problem arose when I tried to knock step three off my list, weaving together all the individual projects into a coherent infrastructure.  Don't get me wrong, I didn't expect this to be the easy part, I was just surprised at how little had changed since my last trip down the road less traveled.

There are a number of extremely valuable products in the community that would only benefit from improved interaction with other projects, why this hasn't really happened yet I'm not sure.  The Open Source community has done an incredible job creating polished products to serve just about every niche, however it's time to focus some resources on bringing the individual products together in a more meaningful manner.  While I'm not suggesting the forward motion of feature development should stop all together, it would be nice to see some of the more refined projects move some of their development effort into increasing compatibility and building a framework to allow more meaningful interaction with each other.

There are many excellent projects out there for building intranets and web sites (CMS), managing client data (CRM), and managing the resources of an enterprise (ERP), but these products would be exponentially more useful if they could be meshed together by non-developers.  By improving compatibility and focusing on closing the functionality gaps inherent in each individual offering, CMS projects could serve as an accessible and easy to use entry point for CRM and ERP systems.  Using the strength of CMS systems to serve content to users, CRM/ERP developers could stop focusing  development resources on client applications, leaving them free to strengthen the core of their offering and add additional features, further increasing the value of their project.  Leveraging a web based CMS system also provides the added benefit of being compatible across a number of platforms with minimal development overhead.  This is just one example of how better collaboration between projects can help to improve the experience for the user base as well as provide developers an opportunity to free themselves from spending development time on the more peripheral parts of their software.

With so many high quality individual projects in the community the future of Open Source may well be determined by the ability of many projects to work together to close the gaps,  producing  a cohesive environment, and providing a real challenge to some of the commercial suites.