Procurement Management

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.

Rate Article

Related Videos
Play Video Learn Business English Vocabulary for Project Management	Play Video Learn Business English Vocabulary for Project Management	Play Video How to Build Small Business IT Consensus for Major Projects	Play Video Project Collaboration	Play Video How to Manage a Home Improvement Project

Listed below are more articles related to the above article from the "Project Management" article category.

People interested in the above article "Procurement Management" are also interested in the related articles listed below:

 

Why Projects Fail? Part 3

This article deals with the third of the OGC's eight causes of project failure: insufficient or ineffective engagement with project stakeholders. Individuals and groups who are not part of the project management team, but who need to interact with the project or may be affected by the project's outcome, are known as stakeholders. Stakeholders can potentially gain or lost as a result of project delivery, and as a consequence may support or oppose the project.

Why Projects Fail? Part 2

This post deals with the second of the OGC's eight causes of project failure: the lack of effective or clear senior management, ownership or leadership at higher levels within the organisation.

Why Projects Fail? Part 1

In April 2009 the National Audit Office published a report that declared the failure of the original C-NOMIS and described how the project had demonstrated seven out of the eight primary causes of project failure. C-NOMIS has now been re-scoped and is earmarked for delivery in 2011. However, important questions remain regarding the way in which the project was managed, the length of time for which mis-management of the project was tolerated, and the value-for-money that can be expected from vast government programmes of this kind.

PMP® Certification Preparation - The first step towards PMP Certification

India’s two important cities Mumbai and Bangalore have arrived on the world map as the hub of some of the key businesses. Mumbai being the commercial and financial capital of India is home to the all the major financial institutions, banks and stock exchanges whereas Bangalore is better known as the Silicon Valley of India, as the answer to the silicon valley of USA. These two cities have witnessed large scale development and are today thriving Indian cities, with numerous software and financial establishments coming up.

What is a Project Manager?

A Project Manager is the person responsible for the overall success of the project. Having received the Project Mandate (detailing the reason for the project and the expected outcome) from Corporate/Programme Management, it is the Project Manager’s job to...

PMP Certification - An Important Career Move

As a project manager with many years experience under your belt, still you will find many circumstances which challenge your abilities and skills to mange projects successfully. As the projects come in all sizes and shapes, it makes your job all the more challenging and tough. With some of them having no past history the job as a project leader becomes more daunting as the learning and gathering information phase extends. This brings a lot more pressure to perform within the timelines and budget.

How to Deal with Project Failure

It is a fact of life that not every project succeeds. Sometimes the market changes and the product is no longer viable. Sometimes the budget or time constraints are untenable. Sometimes it is simply a case that somebody has made a mistake.