Every few months someone comes to me and asks for help with the same problem. They don't know it's the same problem. In fact, it manifests differently each and every time. Fortunately a wise old man once taught me the difference between principles, methods, techniques, and results, so I can tell the difference between a hawk and a handsaw. Most days anyway.
The problem, stated as a principle, is this:
How do I determine which activities and events will interact with my project?
It's easy to come up with a snap answer when I state the question this blandly. We can build charts. We can use project management software to schedule resources and "manage time". We can use something as basic as time-boxing and a calendar spreadsheet to work out our resource timing. These are all certainly useful techniques. I use them myself and urge everyone who spends any time as a project manager to at least experiment with them on occasion.
However, snap answers often miss a critical step. It doesn't do any good to apply a technique if the person using it does not understand what they are doing and why. I can teach someone how to time-box, but until they understand the basic concept it doesn't do any good.
Therefore, before I start chatting with people about which of the myriad techniques we might use to resolve their specific issue, I generally ask them to engage in one of the following basic envisioning exercises.The Project in Time
Imagine for a moment that the project is a string of pearls connected by a thread. This thread connects the pearls (the project activities) in an unbroken line. It splits out, winds around, and sometimes loops back on itself, but remains relatively untangled. Now imagine that we throw the string into a large box full of other such strings, close the lid, and shake as hard as we can.
This unbroken string of pearls is the project's critical path. The other strings are other projects. The box is how we generally manage time on multiple projects - just shake as hard as we can and hope for the best.The Project in Action
Imagine for a moment that the project exists as a black box. Into the project we feed something (e.g. money, schedules, information resources of various kinds). Out of it comes...what? What outputs does the project produce, where do they go, and how do they initiate or impede other activities?
In order to control our project's impact we have to know how it will affect the systems, projects, and people in the environment. Understanding the inputs (your demands) and the outputs (your effects) allows you to do this.
There are obviously other ways to envision the project, each a method supporting specific techniques. These two work well for problems related to resource contention (time problems) and input/output contention (action problems). Others support techniques related to negotiation problems, unmitigated risks, organizational change, change management, and the category of problems sometimes lumped into "that was a dumb idea".
What simple envisioning methods do you use to work out which techniques to pull out of your grab-bag?