I love reading Dilbert and subscribe to the daily RSS feed. So many of strips by Scott Adams are so true. Here is one about project planning from November 9, 2008:

I provided some links about multi-tasking in a previous post. I’ve worked in project management and planning for nearly 10 years now. Just about every project in this time has relied on multi-tasking as a way of doing business. If evidence supports that pitfalls of multi-tasking, why is it done so often?

I think the main reason is the illusion of progress. The perception is that the more parts of a project that are underway, that more of the project is getting done faster.

I believe multi-tasking has its place and could lead to faster results–if executed properly. If one project resource attempts to tackle many task simultaneously—this is bad and will likely cause delays for all the tasks. The “trick” is to have a cross-functional team and multiple resources. Tasks should be assigned by function. Multiple functions can do multiple project tasks at the same time. Maybe this interpretation does not fit the multi-tasking definition. The caveat remains, though, that each function should only tackle one task at a time.

This suggested parallelism could work very well for all project resources–all except the project manager. But maybe that’s okay. The life of a project manager should be somewhat hectic, right? Beware: it will be easy to overload the project manager and force multi-tasking by this resource. An ineffective project manager does not bode well for project progress either!

Another “trick” could be to split the project into several mini-projects and to use outsourcing to help manage this smaller efforts. But again, the overall project manager needs to be ready to handle a new set of challenges with this type of arrangement.

I tried to say this in an earlier post but these articles say it better:

• Even Simple Multi-Tasking Can Make a Project 30% Late

“. . . multi-tasking is not only a bad mindset to have, but it can actually make projects up to 30% late, with only one instance of multi-tasking going on . . .”

• Multi-Tasking: Why Projects Take So Long and Still Go Late

“In most project environments multi-tasking is a way of life. This seemingly harmless activity, often celebrated as a desirable skill, is one of the biggest culprits in late projects, long project durations, and low project output. At the same time it is one of the least understood factors in managing projects.”

 

 

Be sure to check out the Theory of Constraints site too.

I want to share some recent events from my personal life that have helped me better understand project management and planning. I enjoy how life lessons can be applied throughout my career (“enjoy” is not the term I used at the time the events below took place).

We recently moved to a beautiful new home and 5+ acres. We’ve been in the home just about one month. The house is around 10 years old. The previous owners built the house and took great pride in their results. From the first moment my wife and I saw the home, we fell in love. Eventually, we were able to agree to terms and purchased the home.

So next, we needed to coordinate a move. I approached the moving process as an opportunity to plan a project. A project has a defined beginning and an end. We knew our tentative start date, and while all our stuff is here, I’m not sure I would say this project has officially ended. For the planning process, I considered the following:

• Who is willing to volunteer?
• Should I rent a truck or can the contents be transported via pick-ups and trailers?
• How long will it take to move the contents from the old house to the new house?
• How should I “pay” volunteers? What’s in it for them?
• What about the weather? What if it rains?

I started to seek answers to these questions and formulated a mindmap and plan:

• Resources:
• 10 – 15 willing volunteers.
• ~6 pick-ups and three flatbed trailers.
• Timeline: Considering the resources available, moving majority of contents (the big stuff) should take 3 – 4 hours.
• Payment: Food and beverages.
• Contingencies: None really. Constantly watching the weather forecast for the entire week leading up to the move.
• Other points:
• Prepare contents at the old house and organize ahead of the move date. 
• Move contents room by room and put in place at the new house.
• Manage the process at the old house and the new house; act as a foreman.

For the most part, the plan I developed was executed as I had hoped with a couple of exceptions:

• Not all resources were available at the same time.
• No rain but it was damn hot!
• 75% of the contents were boxed and organized at the old house.
• Some of the remaining 25% required the attention of my wife (one of the project managers).
• With the rest, the project resources took initiative and packed and moved the contents. This was not supervised or known by either project manager. (I still do not know where some stuff is at the new house).

Could things have gone more smoothly? Probably not. The project was short in duration and did not require mid-stream contingency planning. I’m not one to doubt the need for thorough planning and think this process can be applied to life projects and professional projects. This experience and my preparation only reinforced the following:

• Planning does not yield results until execution. Execution of a project, though, is as good as the planning efforts. To borrow the cliche, “fail to plan and plan to fail”.
• It is impossible to plan for everything. But enough time and effort should go into the process to ensure the best possible results.
• Sometimes things go wrong or not as planned due to lack of oversight.
• Project resources are often willing to go above and beyond their assignments. Channel this energy and the project efforts can be strengthened dramatically.

Project management is largely about managing risks–technical risks, end-user risks, schedule risks, etc. The least risky approach is to execute project activities in series. For example, a project may comprise of tasks A, B, C, and D. The lowest risk for this project is:

Usually a project will have limitations or “rules” regarding what can be done in parallel and what can’t. This is especially true with medical device product development. For example, design inputs and acceptance criteria must be defined prior to execution of design verification.

I’m managing a product development project for a medical device start-up. The product involves a disposable, software, and hardware–all of which are being done in parallel. We are also building a quality system in parallel. It has been challenging and is very risky. If one item slips, then all are compromised.

And this has happened a few times. Are the project risks worth taking this path? For this project, it’s too late. We now have to develop contingencies to get things back on track.

I “inherited” this project mid-stream. Had I started project management at the beginning, I probably would not have planned everything in parallel. Food for thought for the next project.

Okay, this post is not specific to medical device planning. However, it definitely applies.

Enjoy “How To Be Happy: Productivity and Finding Time” from the Personal Development Blog. Some very good points that can help with just about anything we do–including medical device product development projects.

In my previous post, I touched on a few differences between “urgency” and “emergency” with project management. Project that are in a state of emergency are dangerous and can have long-term effects. Here are five negatives that can likely result when managing projects with this style:

1. Bridges are burned. Emergency projects and tasks often alienate team members and critical project resources. Team members are asked to meet ridiculous deadlines for tasks. The “solutions” are given to those executing tasks and usually band-aids at best.
2. Critical thinking and innovation are stifled and discouraged. Team members become disenfranchised and begin to offer fewer and fewer ideas. The mood of the team turns somber and passive.
3. More bricks are put into the “walls” of the organization. It’s tough to build a cohesive, cross-functional approach to project management. Many organizations have natural walls or ties that align with functional reporting structures. A mission of good project management is to cross these barriers. Projects in a state of emergency do just the opposite. The walls turn into fortresses. Various functional groups begin finger-pointing and assigning blame to other functions.
4. The project is elevated to a pedestal only for others to knock it down. Projects in a state of emergency often get the attention of many people throughout all levels of the organization. Team members and by-standers are all waiting for that moment when they can say “I told you so!” Every action will be placed under a microscope by management.
5. Luck is chosen over being prepared. Plans are usually afterthoughts and viewed as a deterrent to progress.

Have you worked on project teams with a sense of urgency? Or did your teams act as if everything was an emergency? There is a difference.

I’m working as a consultant for a medical device company where the client acts as though every task and activity associated with the project is an emergency.

• “We need those test results yesterday!”
• “Let’s go ahead and build those OQ parts at the same time we route the OQ protocol.”
• “I think we can build five pilot parts from the same raw material lot to define the process parameters.”
• “We don’t have time to find the root cause. Let’s go ahead and fix this step–it may just do the trick.”

No, these aren’t exaggerations. Statements like these have been made quite often during the past few weeks of this current project. But the project has no real plan–at least not one that the project team members are aware of. There is a timeline (due date: yesterday) that the team did not help develop. The timeline was crafted by management and has not been fully communicated to the actual team members who will be responsible for completing.

It may seem obvious, but in my opinion, this is not the way to run a project. I’m all in favor of operating with a sense of urgency. This can only happen if the team members are actively engaged in defining the work breakdown structure (WBS) and project plan. The team members have to take ownership and buy in before a sense of urgency can take hold.

Sure, there will be times when some tasks become emergencies. But it can’t be every single task for the project.

Okay, I’ve vented a little in posts “Ready, Fire, Aim” and “Did We Hit the Target?“. Thanks for understanding. But those posts don’t offer solutions or advice to help you avoid “Ready, Fire, Aim Syndrome”.

Here are a few tips and advice:

• Planning and foresight (and often hindsight) are your friends. Figure out what you are getting into before taking too much action.
• Ask lots of questions: What is the intended use of the device? Who are the intended users? Was the device designed with the primary users in mind? What are the current issues with the current and competitor devices?
• Determine root causes of problems. Understand what changes to a process / design may affect downstream.
• Utilize your resources. The team members likely don’t know everything or the right things about the process / product. Find the people who do.
• Build bridges. It’s amazing what people can and will do if they are given a chance to help.
• If you’re bull, stay out of the china shop. Stepping on toes and making rapid, brash decisions rarely works out well.
• Listen. Listen to the people on the line making the product every day. Listen to the users of the device. Listen to ideas from as many people as possible.
• Speed kills. Trying to fix a problem in a ridiculously short period of time seldom leads to quality results.
• Give the team time to rest. Asking people to work long hours and weekends will lead to burnout quickly.
• Don’t be naive. Don’t assume that improving a manufacturing process will fix design issues with the product.

I can go on, but you get the point.