Though we all have the same amount of time, it just seems to slip by me faster than it does other people. It's not that I'm lounging around smoking cigars, playing poker all night, and ignoring my work (okay, not usually). It's that I take on much more than I should and everyone suffers. And the projects that I take on magically grow from cute, innocent endeavors into eight-armed monsters that crush my schedule over and over.

     Project managers know—or should know—the iron triangle of project management (see Figure 1), sometimes called the triple constraints of project management because all projects are constrained by these three elements: time, cost, and scope. My nemesis is the angle on the left: time.

     Any project, from developing a new piece of software to building a new house, takes some amount of time. The relationships between the scope of the project, time, and cost should balance. If there's not enough time or budget, the project is doomed. (No kidding.)

     The real problem? Planning. Delegation. And learning to say no. First, we must define the product scope: the verifiable, tangible deliverables that make the customer happy (or happier, depending on the customer). Once all agree on the product scope, then it's on to the project scope—all of the work and only the work to create the project deliverable. The product scope and the project scope are dependent on one another; if you change a detail in the product scope—gosh, the project scope will change, too. And these changes take time.

     Now, sometimes I'm late and it just ain't my fault. (Come on, I did say "sometimes.") For example, I was working on a project for a company that couldn't decide exactly what they wanted. It was like one of my usual dates: "I don't know what I want, but this isn't it." We'd go round and round through feasibility studies, new versions of the training manual, class development, and more frustration—then they wanted to know whether I could still hit the target deadline for project completion. My mental response? "Yes, just as soon as I get back from my bike ride to Hawaii."

     On any given day the phone rings, email chimes, or the fax spits out some new request, and without thinking we say yes. That failure to think is killing us. A little change here, an addition there, and four or five new projects coming in; time disappears faster than a plate of donuts at a Weight Watcher's meeting.

     But this isn't an article on how to whine. We're all crushed for time; some of us just manage it better than others. When it comes to project management, I know that the time management discipline is my Achilles' heel. In the past, I would gladly take on the work without thinking, planning, and delegating. But I'm getting better about it—I told someone no last week. It was sad and disappointing, but I can't let things pile up anymore and current commitments slip by.

The Official Approach (How It Looks on Paper)

     In the perfect project-management world, which doesn't exist, there is a logical, practical approach to calculating how long a project should take to complete. Let's pretend that we're living in this perfect project management world and see how things should go.

     First we work with the customer to define the product scope—describing the thing that they want us to create. Then we create the project scope—all of the required work and only the required work to create the product scope. And then, boy oh boy, we create the work breakdown structure (WBS).

     The WBS is not a list of the activities to complete the project. That's right. The WBS is a deliverables-oriented decomposition of the project deliverables—not the project work. Once we've created the WBS, we can generate a list of the activities that the project team will need to perform to create the identified deliverables.

     The activity list should conform to a fun heuristic called the 8/80 rule, which states that the smallest element of the WBS, called the work package, should take no more than 80 hours to create and no less than 8 hours to create. We don't want the WBS to be so granular that we're dictating each step to create the deliverable; nor do we want the work package to be so large, as in more than 80 hours large, to leave much of the work open to interpretation. (As with most rules, of course, there are exceptions.)

     The activity list should then be arranged in the order in which the activities must or should take place. Many of the activities will rely on hard logic; they must occur in a particular order for the project to be successful. We have to install the operating system before installing the application. Soft logic relies on management discretion. For example, we could create a fancy script to install the operating system and then call a remote server to pull the application and install it on the target machine once the OS has been installed. But we may choose not to do that. It's preferential logic based on experience, the nature of the work, or your mood on that particular day.

     Now the real fun starts. As the expert time-starved project manager, you examine the work sequence and realize that you can actually take several paths to project completion in tandem. So you map out the work visually in a project network diagram (PND), as shown in Figure 2. A PND visualizes the work and allows you to find the critical path. The critical path is not the path with the most important activities; it's the longest path to reach the project's conclusion. The critical path reveals the activities that, if late, will cause your project to miss its target completion date. You can find the critical path by simply counting the duration of activities from Day 1 to project completion.
Figure 2 A project network diagram illustrates the project's path to completion.

     But what of the activities that are not on the critical path? These activities have float—the amount of time by which an activity can be delayed or late without affecting the project end date. There are some fancy formulas called the forward and backward pass to calculate the float for each activity.

     You don't have to be a genius to do the math, but it's easier to just let your project manager information system (such as Microsoft Project) do the calculations for you.

     Your critical path can change. Some of your non-critical path activities may be late, additional activities may be added to your project, or the duration of non-critical activities may be revised. Your project may take longer if any of this happens, and you'll have a new critical path.

     Between each set of activities in your PND are relationships that describe how and when successor and paired activities may begin. There are four different relationship types, though chances are that you'll use only one or two of them:

• Finish-to-start. This most common of relationship types means that the upstream activity must finish before the downstream activity can begin. For example, you must create the disk image before you can push it out to 1,200 machines.
• Start-to-start. This relationship allows two activities to start at the same time, but not necessarily end at the same time. For example, imagine that your organization has a new piece of software that all users will have installed on their desktops. In your project plan, all users must complete a four-hour training session before the application is installed. You create a system that installs software on users' desktops while they're in class for the new application. Both activities start at once, but they sure won't finish at the same time.
• Finish-to-finish. This relationship requires both activities to end at the same time. For example, you're managing a project to redesign your new web site. To promote the new chic look, your organization will mail a million postcards to current and potential customers. Your project plan requires that the final modifications to your web site and the postcards arriving at your prospects' offices finish at the same time. Fascinating.
• Start-to-finish. This is the most unusual and least-used relationship of all. It's special. You'll find this relationship when you're using just-in-time scheduling. Basically, the upstream activity must start so the downstream activity can finish. Imagine that you're a manufacturer of plastic bottles. You don't have room on your shop floor for an infinite amount of plastics, so you only order plastics when your supply is running low. The depletion of plastics by current activities triggers an order for more plastics so you can create more bottles in the future.

     Coupled with each of these relationships you can use lags and leads. A lag is simply waiting time, while a lead is hurry-up time. For example, you're installing a brand new network in a building. You'd like the cable installation and the installation of the punch panel to happen in tandem. Realistically, however, the punch panel needs a head start on your cable runs, so you add lag time to the cable installers. This plan allows both activities to happen at once, but requires the cable installers to wait a bit until they begin their activity. (Cable installers usually have no problem waiting.)

     Sometimes project managers have to hurry things along in a project. This is where lead time comes into play. It allows you to move activities closer to the project start date by subtracting time from each activity's scheduled start time, as shown in Figure 3. Lag is positive time; lead is negative time.

Estimating Project Duration

     The estimated project duration is based on the sum of the activities. With some math magic, we can predict the best, worst, and most likely scenario for how long each activity will take, and ultimately how long before we put this beast to bed and move on to the next.

     To create an estimate that's accurate or close to accurate, it's really more than just adding up the activity durations. We also have to consider several factors that could wreck the schedule, drive managers nuts, and cause our hair to fall out (see my photo):

• Constraints. A constraint is anything that restricts project options. You've hired a consultant who is only available on December 29. You've enrolled your project team in a training class on January 20. Sam the systems engineer is taking a four-week vacation in February. All of these are constraints—and there are tons more.
• Assumptions. We all know what happens when we make an assumption (think ass and umption). For example, we assumed that the vendor was honest when saying that the new servers would be delivered by October 1. We assumed that the client was using Windows 95 or better, not OS/2. We assumed that we could have access to the job site 24/7, not just during business hours. If we don't document and share these assumptions, it's trouble.
• Available resources. Have you ever calculated that you'd need four network engineers to pull and install the cable, only to discover that you only have two network engineers for your project? If your required resources aren't available, your project will be hurting.
• Law of Diminishing Returns. The Law of Diminishing Returns controls yield against the amount of labor available. Suppose we have an activity that will take 40 hours with two network engineers assigned. If we add two more network engineers to the activity, can we finish the work in 20 hours? Maybe. If we add 40 network engineers to the activity, can we get done in a few minutes? Not likely. In addition, not all activities are effort-driven; many are of fixed duration. This is a nice way of saying that it doesn't matter how many experts you throw at the activity—it will still take the same amount of time to complete.
• Parkinson's Law. Parkinson's Law states that work will expand to fill the amount of time allotted. Imagine that Joe says an activity will take 40 hours to complete, although he knows he could finish the work in just twelve hours. He's added padding to account for potential mistakes, issues, and games of solitaire he may encounter. Magically the task will grow to take the allotted 40 hours. Think of your workload the day before you leave for vacation. You can crank and get it done. But the day after vacation? Takes all day to send one email. (Maybe not you, but probably that guy in the cube next to you.)
• Risks. Business risk can have an upside or a downside—although we usually think of risks with the downside. Most risks that come into fruition have potential to delay the project work, add activities, and in some instances require us to wave the white flag of surrender. (I'll cover risks in more detail in another article. I know, another time management issue for me. Thanks.)

Time Management and the Crystal Ball

     How do we ever know how long any given activity will take? For some activities, you can rely on experience. Other activities have to rely on expert judgment, historical information, and approximation. Approximation?! Yep. Consider any IT project you've ever managed, worked on, or heard about. Each IT project is subject to the first-time, first-use penalty. Just about every IT project is unique. Even if it's an integrator installing the same old piece of software over and over in different environments, there are unique aspects to each environment. No two IT environments are identical. Even if it comes down to the humidity in the air, the ghosts in the machines, or the users who will crunch and crank on the software, there are always differences.

     These subtle and sometimes not-so-subtle differences can drive us crazy, or inspire us to take up professional roller hockey. These unique configurations also confound best efforts to predict how long an activity will take to complete. Sometimes you think you know and other times you know that you don't know.

     And now a word from reality: That's why estimates are called estimates. Management and customers don't seem to get this part, do they? Have you ever given an ad hoc estimate where you pulled a duration estimate out of the sky? This is a rough order of magnitude (ROM) estimate; a simple, ballpark guess that management and customers are certain to hold you to. No fun for you—just them. I encourage you to not give any ballpark estimates. If you must, add an asterisk to your verbal quote, indicating that this is an ROM estimate and that it can be way, way off—from 75% up to 125%. Otherwise, you're stuck with the number you throw out there. Should your actuals be different from the ROM, you've heck to pay. Right?

Time To Wrap This Up

     If time management were easy, everyone would do it. The biggest input to effective time management is effective planning. As project managers, we must have control over our project schedules, which requires a constant eye on activity duration estimates; actual time committed to activities; and expert judgment, guts, and experience to make refinements to our schedule when appropriate. Of course, it's never fun when a project manager replaces a bad date with another bad date.

     We all have the same amount of time. The only thing we really control is what we do with it.

Projects typically need stuff: servers, software, subject matter experts, pizza, etc. And to buy all this stuff, you need to go through procurement processes. That's just a fancy way of saying you need to follow some rules and procedures within your organization to get the things you need to complete your project.
Well, duh.

     In some organizations where I've consulted, the project managers can spend carte blanche up to $10,000 on any purchases they need. In other, less fun organizations, the project managers can't buy a soda pop without an accountant's permission.

     So where are you? Do you get to buy, buy, buy, or is every purchase considered, weighed, and meditated on before someone reaches for the wallet? In either shop, there are some guidelines you should consider.
Really, there are.

Planning What To Buy

     All purchases require some level of planning. The intensity of the planning is relevant to the purchase being made. You do this already, right? If you're about to install a new piece of hardware, you'll consider all the functions that the hardware should have, shop around a bit for prices, and then see how much your project or organization can spend (or is willing to spend).

     Planning for procurement includes more than window shopping. Think way, way back to the start of any project that required procurement. Early in the project planning, it was easy to identify those things or services that you needed to buy for the project to succeed. As the project moved forward, "emergencies" popped up, requiring you to buy more stuff: cables, software, additional hardware, tools, training, spaghetti sauce, whatever. So how did you go about getting all this stuff? Did you go to management, hat in hand, and plead your case for your much-needed spaghetti sauce, or did you dip into a project contingency fund?

     How you go about purchasing depends on the structure within your organization. It's difficult, if not impossible, to define a universal approach to procurement. Everybody, every organization, has a specific approach to procurement. The moral of the story? Follow the rules. Once you know the rules of how to procure, then you can play the game.

Gettin' to the Gettin'

     I know lots of people who like to go shopping. One person (who shall remain nameless, but her initials are LISA) plans her vacations based on the shopping malls in the vicinity of her hotel. She buys an extra seat for the flight home, just to carry all of her new shoes and fancy outfits.

     As a project manager, you can't go project shopping just because shoes are on sale. While sales are good, they don't always help the project to acquire the things it needs to reach project closure.

     There's nothing better than finding a sale on the hardware or software that your project needs, but you and I know that's just not the way technology and procurement usually works. We have to shop, compare, evaluate, and eventually cough up the cash to get what our projects need.
But here's some Econ 101 for you: Prices are affected by supply and demand, pending changes, and other factors, from government regulations to the economy as a whole.

     I can hear you again: Duh.

     But hold that "duh" for one moment. Three specific conditions affect how much you pay for the things your project needs:

• Sole source. In this condition, you'll likely pay big bucks. Sole source means there is only one qualified seller in the market. This is supply and demand at its finest. If your project needs a Cisco CCIE-certified consultant who must also know how to program in COBOL, speak Spanish, and cook spaghetti for up to forty people, and must live local to your firm, those are some high requirements—you'll likely have to pay a higher dollar for this expert than for your average spaghetti-cooking hack.
• Single source. You're in love. When there's a single source provider, your organization prefers to work with this provider even though other providers may be less costly or more qualified. The danger is that your single source provider may know your attachment and take advantage of the situation. Or get lax in their commitment to quality. Or go out of business. (Or not.)
• Oligopoly. This one is just fun to say. Try it: Oh-lig-AH-polly (sounds like monopoly). This market condition means that there are so few providers of the particular good or service that the events, actions, or circumstances of one seller affect the events, actions, or circumstances of the other sellers. Examples: Airline fares; oil prices; hardware costs; or possibly availability of spaghetti-cooking, COBOL-programming CCIEs who live in your neighborhood.

Cash and the Law of Diminishing Returns

     One of my favorite economic laws is the Law of Diminishing Returns. It's basic stuff at first glance, but can really haunt a project manager if he's not careful. I know you're familiar with the Law of Diminishing Returns, but that guy from Sheboygan is also reading, so let me help him out.

     Imagine that you have a wheat field. Wait, he's from Sheboygan. Imagine that you have a corn field and you know that you can get 100 trucks of corn out of the field. That's the most corn you'll ever get from the field. You also know that if you hire 10 guys to harvest the corn for you, they'll be done in 2 days. So you reason that if you hire 20 guys you'll be done in 1 day. So this must mean that if you hire 40 workers, all the corn will be harvested in half a day, right? Maybe, but if you continue to add workers to the field, a few things will happen:

• Your yield—100 trucks of corn—remains the same no matter how quickly you harvest the corn.
• Your profit will decline because you have to pay all those workers to harvest the corn for you. At some point, you may even be upside down on profitability because of the expense of labor.
• The workers will become counterproductive because they'll start getting into each other's way.

     So how does all this corn relate to an IT project?

     The obvious answer is that you can't exponentially add labor to get a project done faster. And just because you add labor doesn't mean that the project will get done faster. (Have you ever had two programmers, two systems engineers, or even two Spanish-speaking, spaghetti-cooking, COBOL-programming CCIEs argue over how a task should be completed? The argument could go on for years before the work actually gets started.)

     But the Law of Diminishing Returns also applies to the technology that you purchase. Have you ever bought an application that was so rich with features that the cost and time of learning the application was more than the returns from using the application? Or have you ever installed a massive powerhouse print server where many of the features of the OS go ignored? Or maxed out the RAM on a laptop that's only used for PowerPoint presentations and solitaire?
When it comes to IT hardware, as with labor, project managers should procure only what's needed—not the max that the budget will allow.

Build or Buy?

     Ah, one of the great arguments of all time. Should we buy it or should we build it? Well, it's probably not that great of an argument, but I'll bet you've been in some heated discussions on the value of either side of the debate. If not, let's start one now.

     Sometimes, like it or not, it's more cost-effective to spend the cash and pay someone else to build the thing for you. Why? Your crew is busy doing other jobs, they don't have the competence to build the thing you need, or your organization doesn't want to take the risk of creating the thing in-house. Lots of reasons.

     Other times, like when your project team is lounging by the company pool sipping pinot noir and snacking on spaghetti, it's ideal to put them back to work building something. Again, there are lots of reasons why it may be better to build versus buy, or the other way around.

     But sometimes it's purely a price decision. Here's the deal: Let's say that if your organization builds a piece of software, it'll cost $45,000 to create and then $4,500 each month to support. Now, a vendor says they'll only charge you $23,000 to build the initial product, but they'll need $6,500 each month to support it as part of the deal.

     Hmmm... so what's a project manager to do?

     Math.

     Here's how it works: Take your build option of $45,000 and subtract the vendor's quote of $23,000. The difference is $22,000. Now take the monthly support fees of the vendor, $6,500, and subtract your lesser in-house fees of $4,500. The difference is $2,000.

     Now, drum roll please, divide the initial out-of-pocket expense difference of $22,000 by the monthly support fees difference of $2,000 and you'll get 11.
Eleven what?

     Well, 11 in Blackjack means double down. Here it means that you can pay for the out-of-pocket expenses of creating the software in-house in 11 months. So, Copernicus, if your software creation will exist for less than 11 months, hire the vendor to do the work for you. If your solution will be around longer than 11 months, and price is the only factor, build the software yourself.

Taking Out a Contract

     Contracts override everything: promises, email, secret handshakes. As long as they don't include illegal activities, contracts are backed by the U.S. legal system. A contract is what makes the deal a deal.

     To get to the contracting activities, you need to create the procurement documents. The initial document is usually the statement of work (SOW), which describes the thing or service you want to buy. The SOW is provided to the vendor with an invitation to bid (IFB), which you probably also know as a request for quote (RFQ). The IFB and the RFQ are basically the same thing and are focused just on price, not ideas.

     A request for proposal wants a price, but also suggestions and ideas on how the project work should be done. Proposals are more than just costs—they're a bit of consulting from the vendor.

     In big-dollar contracts, you'll likely host a bidders' conference in which all vendors that want to create a proposal or bid will meet with you at once and ask questions concerning the SOW. This setup ensures that all the vendors have the same info on which to base prices and proposals.

     Once you make a decision on which vendor to use, you go through negotiations—which lead to a contract. The contract-type selection might also be negotiated, but usually the type of work or goods being procured dictate the appropriate contract type.

Bring Your Wallet

     Procurement is, uh, big business. There are lots of details in procurement planning, the creation of procurement documents, bidder conferences, and in the contracting of the work. All organizations have their approach to procurement and contracting. You, the project manager, need to understand your organization's approach and then follow the rules to get the stuff you need.
Now, if you'll excuse me, my Spanish-speaking, CCIE-certified, COBOL programmer has spaghetti ready. And I need to pay his invoice.