As I’ve said more than once lately, these are difficult times for most IT managers. Odds are you don’t have enough staff or enough budget, but you have no shortage of responsibilities. You spend a lot of time trying to keep your people motivated, while attempting to extend the lifetime of your existing hardware and applications, because you can’t afford the upgrades.
At times, the projects can seem almost insurmountable. You don’t see how you can possibly get everything done on time and within budget. Fortunately, I have a solution. Here is a technique that can give you confidence to approach even the most daunting task.
A lesson from the movies
I started thinking about this while watching a movie. The other night, I was suffering one of my periodic bouts of insomnia. While I was scrolling through the late-night cable offerings, I came upon a documentary about the making of the classic modern Western Butch Cassidy and the Sundance Kid.
If you’ve seen the movie (and if you haven’t, you need to add it to your Netflix list today), you’ll remember the scene when Butch (Paul Newman) and Sundance (Robert Redford) have been tracked for hundreds of miles by a posse, only to be trapped on a cliff high above a raging river in the Rockies. As sharpshooters from the posse move into position to pick them off, Butch and Sundance bicker about whether to give up or fight what appears to be a hopeless battle. At the last minute, they decide to jump.
The brief scene has a number of different shots. First, you see Butch and Sundance on the cliff, arguing. Then, they build up their courage and run off the end of the ledge. Next, you see them falling into the water. Finally, you see them floating downstream at a fast rate, while the members of the posse look on helplessly.
In the documentary, you see how the director put the scene together. Here is what had to happen to get the shot seen on the screen:
- Location scouts toured the Rockies looking for a river surrounded by cliffs that would serve as the backdrop.
- During location shooting in the mountains, Newman and Redford are filmed climbing near the summit of the cliffs, as are the members of the posse as they move into position.
- Back near Los Angeles, a small outdoor set is constructed, which re-creates the top of the cliff from the location shooting. This is where Newman and Redford are filmed arguing about whether or not to jump. This is also where they are filmed jumping off the “cliff,” which in reality is just a drop of a couple of feet to a wooden platform.
- Using a decades-old technique, studio art experts use detailed photographs of the river and cliffs as a model when painting a copy of those same cliffs over a large piece of glass.
- Two stunt men, dressed like Newman and Redman, are filmed jumping off a large crane into a lake. However, holding the painted glass in front of the camera while filming, it looks as if Butch and Sundance are falling between the mountains on either side of the river that was filmed on location.
- After all the filming is complete, editors put the various shots together.
On the screen, it looks seamless, and the scene is one of the high points of the picture. But, of course, the creation of the scene demanded that many smaller projects be handled separately—not even in the same locations, in fact.
Partition your projects—and your problems
Now, of course, we all have to do some partitioning in basic project management. What I’m talking about here is something different. Rather than viewing a project as a series of tasks to be done in sequence, sometimes it helps to view them as a series of separate mini-projects.
This could provide two advantages, one tactical and the other philosophical.
Let’s talk tactics first. In traditional project management, managers tend to view large projects as a series of steps to be completed one after the other. I know that our Gantt charts and project management software allow us to track work being done independently, without pushing back the overall schedule. (In other words, not every task on Gantt chart has a dependency on other tasks.) However, I’d argue that even though our software allows us divide up projects in that fashion, we tend not to think that way. All too often, our project plans look like nothing so much as the instructions for assembling a bike or a swing set: step one, then step two, and so on.
Take the movie example. The producers used a variety of people working independently to capture the different shots I mentioned. It wasn’t done sequentially. In fact, I can think of only one major film that was shot sequentially—Alfred Hitchcock’s Rope. All other films are shot to maximize efficiency. For example, if you need a large crowd for three scenes, you try to shoot all of those on the same day, rather than going to the bother of hiring a bunch of extras three different times. If you need to close a city street to shoot some scenes, you try to film all those scenes together.
As I said, this isn’t the way that many teams approach project management. For example, consider how many project plans envision blocks of time set aside at the end of a project for QA, training, or documentation. These plans often schedule a massive QA effort at the very end of the project, rather than building smaller QA sessions for separate pieces of the project as they are finished. These smaller QA sessions could find potential problems sooner, as well as speed up project deadlines. (Of course, you need some QA at the end of the project, to make sure everything works well together, but you don’t have to do it all at once.) The same thing is true of training: Why wait until the end and do it all at once? Some of your users would probably appreciate as much early training as possible, even at the cost of having separate training sessions as different applications come online.
By viewing a large project as a collection of discrete smaller projects, you can sometimes become more creative in how you tackle problems that arise. For one thing, such a view could encourage you to outsource portions of the project or to buy an existing application and tailor it to fit the needs of one of the mini-projects. By looking at a mini-project with an independent mind, you may find a better solution. (Of course, the risk is that you can lose efficiency by not scaling your development efforts across the entire project. However, sometimes you should be willing to pay that price.)
Celebrate finishing a mini-project
In general, this approach allows you to view each mini-project as a kind of component. This leads to the second advantage of this approach. This benefit is psychological.
As I said at the outset, it’s tough to be a technical manager these days. You’re being asked to do more with less—in some cases, a lot more with a lot less. In that kind of environment, a big project can seem more than a challenge. In fact, it can overwhelm you.
By breaking a huge task down in to mini-projects, it can seem less threatening. When you finish each of these components of the project, you’ll feel a sense of accomplishment, no matter how small. Further, it can keep your team from becoming demoralized. Too often in standard project management, the team puts endless hours into a massive undertaking, without being able to see signs of progress. Instead, when a mini-project is completed, you can take your team out to lunch and congratulate them on their smaller accomplishments.
This may not seem like much of a benefit. But these days, it pays to take advantage of all that you can.
From the IT Leadership Web log
Project management is just one of the topics I discuss on TechRepublic’s blog for technical managers and their bosses. It’s called IT Leadership—check it out today. It’s free, and I post to it almost every business day.