Project Procurement

Agile Project Procurement (Comparing Apples to Oranges)

In PowerPoint presentations, every project procurement solution works and every business case rocks but that’s not the case in real life. Bad project procurement planning and choosing the wrong solution are key risks in a project. This has been one of the most time and energy-consuming activities for me, especially in situations with more than 3 companies on services not easily comparable. Project Methodology Main Page

IT Project Procurement

In my field, which is IT, the most complex procurement processes are related to software solutions (hardware related processes are more standardized). Comparing software from different providers, although for the same requirements, is often like comparing apples to oranges. Price is not always an indication of quality. I have seen both scenarios; paying premium dollars and getting bad quality from big names like HP, Oracle and IBM. I have also seen companies bidding with low prices to get the deal, then not being able to fulfill their promise. Big companies can afford good marketing and selling teams, the key skill is driving the perception of quality by building excellence with their polished presentations.

How do you protect the project from price speculation and the marketing window dressing? This is a technique that delivered good results for me on several occasions, making the project procurement process of choosing between apples and oranges less painful. There are 2 prerequisites to this approach. First, you should not be in a hurry. It is good practice to start as early as possible with the planning of the procurement phase. Second, you must have some negotiation leverage with the vendor companies.

Project Procurement Steps

I call this approach the agile project procurement, and it goes like this:

1) The team agrees on the quality criteria and price/quality ratios for selecting the winner. The selection criteria is approved by the steering committee in order to have it written in stone.

2) It is key to start the process fast by sharing a short version of the requirements/procurement-SOW in an RFI with the problem you want to solve and the objectives. Having the list of prospective vendor companies predefined saves time. The companies are asked to propose their solutions based on their past experiences for similar requirements. It is very important to keep this first cycle short in order to use the time later. In this phase, you also request a high level cost estimation.

3) Based on the feedback of the companies, you use the selection criteria and choose 3 companies.

4) All the companies are notified to enter the second round and are asked to build a PoC (proof of concept) or prototype of the proposed solution in 2-4 weeks. Usually companies agree to build the PoC when the process is important to them. If one of the companies does not agree to build the PoC, this might be an indication of trouble and needs to be investigated. Either the company is not very interested in the process, resulting in a low level of commitment, or worse they’re not capable of delivering the required software.

5) After the PoC is delivered, project stakeholders and business users are invited to have a dry run of the software. After their testing, they must provide formal feedback.

6) Based on the gained experience and user feedback, the original RFI is enriched to a RFP and the companies are asked to provide the final pricing.

7) The final selection is done using the original approved selection criteria, which includes the feedback of the users.

Project Procurement Pros and Cons

This project procurement approach is no silver bullet, it has benefits and drawbacks. On the benefits side, it deviates from the classical waterfall planning of procurement by bringing stakeholders’ and users’ feedback into the equation. It reduces risk by braking the power-point tradition and asking the companies to prove their capability to deliver. And it increases the competition, resulting in better price/value positions. This also helps the companies get a better picture of what they are committing too. The benefits are lower risk and better quality.

Some of the drawbacks are that requires more resources compared to the classic procurement phase. The procurement process may cost more and you may lose some of the companies who do not want to invest significant effort during the selection phase.

How To Manage Multiple Projects Video

Dick Billows, PMP
Dick Billows, PMP

After successfully managing projects in IT, healthcare, construction, or general business, project managers can move up to managing multiple projects, programs and/or portfolios of projects. Enterprise Project Management Main Page

Here they must allocate resources across all the projects in the program or portfolio they’re responsible for managing. They must also deal with executive sponsors and stakeholders more often. They must try to enforce effective organization-wide processes for managing multiple projects and programs. And that is a significant challenge.

Managing multiple projects

The technical skills of portfolio management, setting priorities and allocating resources are straight-forward and rather simple. What’s not simple is handling the politics of managing multiple stakeholders with conflicting interests and priorities. Many newly promoted program and portfolio managers think all they need to succeed is the power of the CEO behind them. However, they soon find out that the senior executive, while backing the idea of doing projects the right way, will not overrule the executives that the program or portfolio manager deals with every day.

Far from using their power to force compliance with the program manager’s proposals and processes, the CEO will want them to “work it out” with the executive stakeholders. Thus, managing multiple project takes program and portfolio managers into the world of political maneuvering, horse-trading and deal-making. They must join in the political deal-making and coalition-building or the executives will quickly ignore them. They will consider the program and portfolio managers irrelevant to the issues and challenges these executives face.


Make Clear Assignments & Estimates With A Work Package

Dick Billows, PMP
Dick Billows, PMP

A key success factor for project managers is making crystal-clear assignments to their project team members. This ensures  the team members understand what’s expected before they start work. A related success factor is having team members make realistic estimates for their tasks. This ensures the overall project estimates are accurate. It’s important for team members to be committed to those estimates and have some “skin in the game” in terms of hitting their work and duration numbers. Main Project Estimating Page

Project managers also need a vehicle to capture and store historic data on each project. So when you, or other project managers, have similar tasks on future projects, you can look at the actual assignments on completed projects. You can use some of that data from the work packages for the current project’s tasks. You should be able to retrieve the estimated hours versus the hours actually used and apply that information to your analogous estimates. The use of the project work package addresses each of these success factors.

The project work package is a simple tool that improves the clarity of project assignments. At the same time, it increases the level of team member commitment to their estimates. In a very real sense, the work package is the contract between you, the project manager, and the project team member. In it, you make clear exactly what is expected of the team member on each task. The work package details the metric you will use to measure the assignment as well as the approach the team member should take to complete it. It also details the input deliverable(s) the team member needs to start work. Additionally, it specifies the output deliverable(s) which are the things other team members need from this assignment before they can start their work. The work package also allows you and the team member to discuss risks and how to handle them. It is a very important part of the estimating process.

Learn to Use the Project Work Package

You need to work with your team members to introduce the project work package. Be careful that it’s not viewed as “just another form to fill out.” You want to talk with them about it as a contract or agreement that the two of you will use on the project. You should point out that it offers them protection against changes to their assignments that don’t include adjustments to the work and duration estimates. You may also frankly explain that the work package is a device to reduce the padding of estimates because it offers the team member protection against unfair changes to the scope of their work assignment.

It will take one or two projects for the team members to become accustomed to using work packages to define an assignment, their availability to work on it and their estimate of work and duration. But the benefits are substantial. They are particularly helpful down the road when you can review completed work packages to use as the basis for estimates on future projects.


Get Our Free Project Manager Newsletter
A Free Project Article & Video Each week

By submitting this form, you are consenting to receive marketing emails from:, 125 cold springs dr, georgetown, TX, 78633, You can revoke your consent to receive emails at any time by using the SafeUnsubscribe® link, found at the bottom of every email. Emails are serviced by Constant Contact

Create WBS

Dick Billows, PMP
Dick Billows, PMP

The WBS or work breakdown structure is a listing of every deliverable that the team must produce. Creating the WBS with team members  is a great opportunity to improve people’s commitment to the project and give them a sense of ownership. Usually, the project team sees their tasks after the project manager lists everything they have to complete. That yields very little ownership and even the lack of understanding of how each team member’s deliverable connects to the overall scope. Main WBS Work Breakdown Structure Page

The starting point for working with your team is after the project sponsor has approved the scope and 4 to 7 major deliverables in the project. Note that all of the entries on the work breakdown structure are deliverables with acceptance criteria like, “Error rate less than 3%.” That acceptance criterion could cover an entire project or it could be one high-level deliverable in a project aimed at improving customer service. Finally, it could be the deliverable assigned to an individual.  However, every entry has a metric that tells people what a good job is. Having your team participate gives them an understanding of how the entire network of deliverables fits together.

Create WBS with Team MembersCreate WBS: Brainstorming With the Team

With those definitions in mind, we start the process by taking one of the high-level deliverables and decomposing it. Decomposition is the process of breaking a deliverable into its component parts. As an example, if we were decomposing a deliverable we talked about earlier, “employees can retrieve items from the supply inventory in less than 180 seconds 90% of the time.” we might talk with the team about how we go about achieving and identify these supporting deliverables;

  • install new supply room map that lets 90% of the people locate the shelf with their item in less than 60 seconds
  • reorganize shelves so people can find their specific item in less than 45 seconds
  • automate the supply signed out process so people can record the item(s) they took in less than one minute 15 seconds.

There might be many ways to go about achieving the high-level deliverable of reducing the time to retrieve supplies. During the conversation with your team, you would allow people to suggest different ways of achieving that end result. It is good practice to achieve consensus on the approach to each of the deliverables.

Another way to develop the work breakdown structure besides brainstorming with the team is to use work breakdown structures from previous projects.  You may not be able to use the entire work breakdown structure. However very often you can find a section of the WBS that is close enough to what you’re doing in the present project that you can simply copy the deliverables. On larger projects that are more complex you may bring in experts on certain kinds of deliverables like computer programs, remodeling of workspace and so on. You would use their expertise to develop the deliverables for your project.

Predecessors that control the sequence of the tasks will link them. Then we assign resources to each task in the WBS. The resources could be people, materials, or contractors. Then, the project manager calculates the duration of every task in the WBS and that completes our project schedule. When the project sponsor approves the schedule, the project manager saves that approved version of the schedule as the baseline. When work begins, the project manager keeps track of the progress the team makes on each task. That is the basis for status reporting.

Create WBS: The Decomposed Project Scope

We always develop the work breakdown structure by working top-down from the scope, not by assembling a list of the things people want in the project. That to do list approach to developing the work breakdown structure yields projects that cost much more and take much longer than they should. When we work top-down, we start with the scope of the project as defined by the project sponsor and we decompose it or break it into 4 to 7 high-level deliverables, each of which is a metric. Then we continue working top-down and we take each of those major deliverables and break it into its components, the elements that are required to produce that deliverable. On a very large project, we may work down another level or even two, subdividing large deliverables into smaller deliverables until we get down to the level of individual assignments. That’s developing the work breakdown structure top-down.

Create WBS: Best Practices

As you can see, the WBS is very central to the entire process of planning, scheduling and tracking a project. The best practices for developing a WBS involve these steps:

  1. After the sponsor of the project defines the scope or overall objective, the project manager begins the creation of the WBS by decomposing the scope into 4 to 7 major deliverables.
  2. We define each of the major deliverables by what the team will produce at the end. As an example, “Clean up the file room” is not a clear deliverable because we can’t measure the end result. On the other hand, a deliverable like, “98% of the books on the shelf in alphabetical order,” does define the end result in measured terms.
  3. To complete the WBS, the project manager takes each of the major deliverables and further decomposes them into smaller deliverables until they reach the right size task for an individual project team member.


Project Failure

project failure project failureWhy Projects Fail So Often

Some organizations have project failure rates that threaten their existence. In some cases they can’t deliver to a customer or client profitably. In other cases they can’t deliver new products and services that allow them to successfully compete. The failure rates are as high as 70%. Enterprise Project Management Hub

Most Organizations Have a 70% Project Failure Rat

Project success = produce planned deliverables, within budget and on time (including approved changes). Using this definition of success, we find that most organizations have 70% project failure rates.  That project failure rate wastes so much money and human resources that even a small increase in the success rate is worth a lot. But the solution is not easy. Poor performance causes high project failure.  The poor performance is at three levels in the organization: executives, project managers and team members.  To cut the rate of failure, project managers must coach both the executives (subtly) and their team members (directly) about their roles.  And implementation of a project process in the organization is vital to reducing the project failure rate to under 20%.

How To Avoid Project Failure: Executive’s Role

Executives set clear strategic objectives for projects. They ensure all projects yield business benefits, and they allocate resources based on priorities. Most executives fail at their project role and this contributes to project failure.  Here’s how they usually operate. An executive calls two subordinate managers into a meeting and says, “We have a mess in customer service and we have to fix it. This has to be priority #1.  Drop everything else and clean up the mess. Install new systems and procedures and whatever else we need for World Class Customer Service!  In fact, we’ll call it that – the WCCS Project.”

One of the managers says, “Didn’t we do that last year?  I mean the acronym we used was different but boy, this project sounds familiar.”

The other manager says, “You’re right.  In fact we’ve done this 3 times since I’ve been here.”

The executive snaps back, “Yes, and each earlier attempt failed.  Let’s do it right this time.”

The two managers exchange pained looks as the executive goes on, “Now, I have two other ideas for projects to cut costs and improve service. So here is what I…”

The first manager interrupts with a groan, “You always have great ideas, boss, but our plates are full.  Our first-line supervisors are already spending half their time on projects and their real jobs are suffering.  The engineering and technical staffs are all working 70 hour weeks.  Something has to give.”

The executive frowns and says, “I know what’s going on down there and there’s plenty of time to squeeze in a few more projects.  Your people just have to work smarter not harder!”

Instead of giving the project managers clear unambiguous objectives , the executive gave them mission statement mush. There was no assessment of the project’s business value. Additionally, he refused to tackle the politically difficult task of setting project priorities for allocating the limited resources. Project Rescue

How To Avoid Project Failure: Project Manager’s Role

Project managers conceive, manage and control projects. They use best practice techniques to ensure the projects deliver their planned outcomes efficiently. Many project managers also fail in their role and contribute to project failure. This is how they operate. A newly promoted project manager enters the cubicle of an experienced project manager and says, “I’m really nervous about my new project.  The way my director was talking this morning, the world may end if this project fails.  I’m gonna tell my family not to expect me to leave work on time for the next six months.  My boss said this is priority number one!  I’m worried that I’ll be in real trouble if I don’t bring it in on time and on budget.”

The experienced project manager laughs and says, “You’ll laugh too after you’ve heard that speech about 50 times.  On the first day they all talk loud and long about how important the project is.  But when you ask them to spend an hour or two planning this critically important project, they’re too busy.  When you ask them to make sure the project team members from other departments actually show up to work on your projects, they’re too busy for that too.”

The rookie relaxes and says, “Okay you’ve been there and I haven’t.  I’ll take your advice. Can you tell me how the company wants project plans and schedules put together?”

The experienced project manager chuckles again and says, “We have no standard methodology.  Every project manager in the company just wings it.  You can’t possibly put together a plan when executives make you start work before they decide what they want.  When you try to define the scope or even ask what the project is supposed to produce, what you usually get is a long speech about how we need to react quickly and stay flexible.  The best thing to do is write down what they want you to do first and do it.  Then go back and ask them what they want you and the team to do next.  They want to micromanage everybody anyway. There’s no sense creating a lot of plans and schedules – they’re always a joke.”

The rookie gasps and says, “You’ve got to be kidding.  This is a successful organization.  How can we be successful without project plans and schedules?”

The experienced project manager smiles and replies, “I’ll help you with that. I’ve got a bunch of old project plans and some really big work breakdown structures you can use to copy and paste.  If anyone asks, you’ll have a really big plan and a highly detailed work breakdown structure that no one will ever look at anyway. But you won’t be responsible for project failure.”

Instead of the project managers pushing for the use of best practices, they act like order-takers at a drive-in restaurant. They give little thought or energy to planning or how to avoid problems before they occur.

How To Avoid Project Failure: Project Team Members’ Role

Team members make accurate estimates of the work and time. They report status accurately so problems are identified early. Many team members fail in this role and contribute to project failure.  This is how they operate. Two technical professionals with heavy project workloads meet at a table in the company cafeteria.  The first technical professional, who is new to the company, grumbles, “They gave me three new project assignments this morning. I was afraid to say anything but there is no way I can get them all done by the due dates. It is more work than three people could do.”

The second technical professional laughs, “They’re always starting new projects and if you try to do all of them on time, you’ll kill yourself for nothing. Just pad the estimates by 50 or 60% so the project manager can’t blame you for the project failure. There are so many half-done projects floating around that no one remembers them all.  My rule is that if no one has talked about a project in the past month, I don’t do any work on it.”

The first professional replies, “But when we start these projects, the boss says I am committed to the estimates and completion dates. That’s exactly what he did on some projects two weeks ago.”

The second professional laughs again, “Oh yes, you’re committed.  Has the boss asked you about any of those older projects recently?”

“Well no.”

“Then they’re dead ducks.  Work on the projects people are screaming about.”

“But I’ve put dozens of hours into some of those old projects,” complains the first technical professional.  “Does the organization want me to just throw that time away?”

Shaking his head, the second technical professional replies, “I think we waste about a third of our time on projects we never finish. And we have high project failure rates on the ones we do complete. That’s why you shouldn’t get excited about flushing another one down the drain.”

Instead of making accurate estimates of the amount of work and time required, project team members focus on avoiding blame.

How To Avoid Project Failure Summary

Organizations that consistently succeed with projects perform well at every level in the project management process:

  • They control the initiation of projects; planning, approving and monitoring projects based on the business value those projects produce.
  • They manage the pool of project resources just as they manage their capital budgets; allocating people’s time and money to projects based on the payback.
  • They follow a consistent methodology for all projects; holding people accountable for measurable achievements.

To learn a complete methodology for project success, consider our private online training.

Get Our Free Project Manager Newsletter
A Free Project Article & Video Each week

By submitting this form, you are consenting to receive marketing emails from:, 125 cold springs dr, georgetown, TX, 78633, You can revoke your consent to receive emails at any time by using the SafeUnsubscribe® link, found at the bottom of every email. Emails are serviced by Constant Contact