About 15 years ago, I had the opportunity to meet a guy who ran the largest publisher of tarot decks in the world.
Each deck consists of 78 cards, and each card is a tiny work of art that tells a story. Tarot imagery is archetypal. The pictures on the cards tell stories.
One of my favorite of these diminutive artworks is the Three of Wands, which has an image of a fleet of ships leaving the dock, setting sail on seafaring adventures, while someone stands on a cliff watching them sail away.
In many ways, that card can also symbolize how I look at projects. I often work on a number of them at the same time. I think of each one as a new ship of discovery. I'm rarely sure when it's going to come back to the dock or what will be found. Some projects won't make it at all. Others will be surprising successes.
It's in this context that I want to talk to you about how you think about and approach projects. This can apply as much to someone who is a freelancer as it does to a small company creating new products and services.
Projects involve different levels of investment, creativity, persistence, and problem solving. But for today's discussion, I want to talk about a factor that's universal to all projects: the time they take to complete.
Formal or complex projects are often characterized by PERT and GANTT charts. These documents describe the resource allocation, stages, time period, and dependencies within a project. The biggest PERT chart I ever made was for an operating system release, and it spanned the entire wall of our engineering building, about 150 feet in length. It was a big project.
As a simple example, you can't start shooting a movie until you've cast the stars.
That's a dependency. The beginning of principal photography can't begin until a pile of other stages are complete, including finding the actors. Casting the actors is dependent on knowing who the characters are in the film. And so on.
Something is considered to be on a critical path if its completion is required before some other work can continue. For example, while casting the actors is on a critical path before principal photography begins, it might be possible to work on the sets while the actors are being cast. And even then, actors that are exclusively being filmed later in the shot list might not need to be cast before the first filming is started.
To continue our film analogy, a studio often works on more than one film at a time. In fact, the essence of the studio system is the funding, shepherding, and management of multiple films in order to bring them to market. While the studio may place most of its hopes on a mega hit, even if one film is delayed, other films can still proceed apace.
In the tarot example, each film would be one of those ships. A ship might sail, representing the making of the movie. Once the movie is complete, another ship might sail, representing the release of the movie to the public, whether through a streaming service, old-school DVDs and Blu-Ray, or in actual theaters.
Sometimes, ships get stuck. Sometimes, projects reach a point where they can't go any further, at least for a while. While good project managers try to plan around that eventuality, I've found that my projects sometimes hit snags that bring them to a stop.
In my case, this makes sense because many of my projects are experimental. As a result, I often have a number of projects at work at any specific time. I'm never entirely sure which will result in an article or project or when.
I brought in two products to review and compare, both of which were new releases. Wouldn't you know it? I found bugs in both. Show-stopping bugs. In a screen-sharing conference call, the product manager for one of the products just kept repeating "that's not supposed to happen that way."
As a result, that entire, multi-month project is on hold until one of the software products fixes its critical bugs (or I find a different option).
The point of this is not to complain about a stalled project, but rather to help you understand how to queue up projects and manage the inevitable stalls that might come, particularly with experimental projects.
I should distinguish here between the sorts of experiments I do for articles and projects I do with a fixed deadline for clients. Experimental projects can stall. A key is to keep a bunch of them running, so it's possible to jump from one to another while waiting for any given one to resolve itself.
Deadline-based client projects are treated in a different way. First, I rarely take on client projects that are experimental. I have a very good idea of the scope of the project. The proposal and analysis process includes the expected time to completion, based on years of experience producing similar projects.
The way I handle managing snags or stalls in these types of projects is to track them very carefully through their stages. I also make sure I build in enough slack time to handle the typical stall scenario.
For example, I know that certain clients will always be late in providing their part of a project. For them, I make sure to build in slack time that allows for them to miss a deadline, accept a new deadline, and hopefully make their second, revised deadline.
I also know how long a typical project of a given type takes for each stage of completion. For me, there are times when I'm extremely hard at work, and then there are times in the project's lifecycle when other folks are working on their parts. So, I stagger my hard work sections. That way, each project's hard work occurs while I'm waiting for elements from other projects.
This allows me to keep multiple projects going at one time.
I use a variety of different tools for tracking, depending on whether I'm part of a team or working on something on my own. My biggest and most important tool is simply blocking out chunks of time on my calendar that are allocated to primary work time.
In Google Calendar, I use one named calendar for confirmed projects and another for tentative projects. This allows me to see how each month is taking form. I use the gap times between client projects for working on the editorial and side projects that often find their way into DIY-IT articles.
Many of the projects I work on span four or five different organizations and often a similar number of continents. I make very sure I meet my deadlines, because I'm often the critical path item.
If you're very, very interested in project management, it's actually a formal discipline you can pursue. But short of formal training in complex project management, I want you to take a few simple points away from this column.
Projects naturally have a lifecycle, from beginning to end. Sometimes they stall, and sometimes they fail. Don't beat yourself up. The more experimental a project, the more likely it is to run into a snag. That's normal.
Schedule your projects and distinguish between mission-critical projects (those with a promised deadline) and projects you're just working on. But schedule both so you know when you're working on what.
Have multiple projects running at once, but don't overwhelm yourself. You can't work on them all at once. If you're good with your scheduling, you can work on one project while waiting for stages on other projects to run their course.
When you commit to a due date and a schedule, make sure you clearly understand the elements. After all, if you promise to get something done by a specific date, it's not only your word and credibility on the line, but folks are counting on you.
Returning to the tarot example I used earlier, remember that you're not just launching ships and hoping they come back successfully. For most projects, you're either a member of the ship's crew or the captain. Pilot them all with care, meet your commitments, and use a good map.
Managing and juggling multiple projects isn't magic. You can sometimes make it look that way if you've done your planning, know your dependencies and possible snag points, schedule your work, and work your schedule.