Tag: Project Management

Current Project: The Return of…

I am engaged by a client who manufactures, markets, distributes, and services medical devices. My current project involves the identification, retrieval, and destruction of pumps the client has deemed at End of Life (EOL) and wishes to retire from the marketplace. While the program scope is worldwide my project management responsibilities are scoped to US based customers. All of the work we do, from customer contact to return of the pumps and updating the tracking system, is done under in an FDA regulated environment using Good Documentation Practices (GDP). This is a reverse logistics project that involves product/customer identification, use of a Third Party Logistics (3PL) provider to collect and recycle the pumps, and completing the FDA required documentation to provide the audit trail of documentation and objective evidence that pumps are indeed out of clinical use.

This project combines scope planning (how many customers, how many pumps, where are the customers and pumps), communication planning (how do we initially contact customers, how do we get them to cooperate to return the EOL pumps), and customer service skills along with KPI tracking and status reporting. It’s a Supply Chain / Reverse Logistics project, a discipline I’ve been involved with before. This is also a client I’ve worked with before so being called back a second time to help out provides a measure of satisfaction of a job well done the first time around. Clients remember you when you do a good job for them – repeat business is the best measure of that.

 

Project Staffing – Can We Get it Right?

For organizations that perform projects (which ones don’t?) there’s a question that invariable is asked at some point: “Do we use our own people for the project or do we bring in consultants and temporary workers?” While there are a few different ways to answer this question ultimately the answer has to be made in the best interests of ALL the people involved. I’ve seen many a project go quickly off course because staffing, communication, and planning weren’t seriously considered. Companies usually fall into one of three categories when making this decision:

  • Use consultants/contractors to perform the project work and let the employees handle the day-to-day tasks
  • Use employees to perform the project work and have consultants/contractors do the day to day work
  • Use the project as an opportunity to have employees lead project teams with consultant Subject Matter Experts (SME’s) to guide them.

In the first instance companies engage a consulting firm with most if not all the necessary project resources. The consulting firm leads the project, performs the requirements gathering, development, testing and, at the end, (maybe) trains the client personnel on how to use their shiny new software tool / process / upgrade, hands over any documentation, and leaves. Any “institutional knowledge” they may have picked up leaves with them. Ideally the documentation they leave behind and the knowledge transfer they perform are adequate for the client to use the new tool they have. Many times the success of the project is solely determined by how well the knowledge was transferred.

In the second scenario employees are thrust into roles they may or may not be familiar with: Project Manager, Business Analyst, Requirements Manager. Most projects initiated by business users depend heavily on their IT staff to move the project forward. Business users often do not have formal project management or project documentation training, leaving those duties to already overly-burdened IT staff. Business users have ideas of what they would like to see or how the new product should function but these ideas get lost in translation between their vision and the reality of well-defined functional specifications. As they attempt to perform their project duties they are constrained by the temporary replacements doing the day to day work.

The third situation requires much more planning and broader, enterprise level buy in for the project. Project training for employees has to happen before the project formally commences. Planning and communication of project management and documentation basics, as well as expectations for phases and milestones, must be clearly laid out before the project begins. Ample time must be allotted for employees to train replacements before they move to the actual project. The enterprise must be willing to invest not only in the project itself but the time and resources necessary to back fill for employees while they embark on the project journey. Once properly equipped, replacement workers and employees are ready to devote their full attention to their new roles.

Which approach is best for your project? It depends on your circumstances, budget, timeline, and level of urgency. I’ve seen the third approach work the best in practice. It requires much more thought, time, money, and resources but, in the long run, it is best for everyone involved. Employees are shown they are valued when the organization takes the time to train them and then allows them to apply their new skills right away. Temporary workers are trained in a new corporate environment, increasing their skills and adding to the professional backgrounds. Learning and professional growth happen all across the organization with much more engagement by everyone involved. Everyone knows their role and has a support network to engage should they need. It may take more effort but in the long run many more people benefit from this type of approach.

So what are your thoughts? What is the best way to staff a project?