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.