14 Steps to a Great Procurement Management Plan

Procurement begins with a well-documented Procurement Management PlanFor most of my career as an IT project delivery specialist, I spent my time responding to Requests for Proposals (RFPs) and, if we won the bid, delivering what we had proposed.

Then one day I got to see how the sausage was made …

When I left corporate IT consulting and started my own “single shingle” consulting practice, I was privileged to get in on the ground floor of several major IT development projects. I was contracted by organizations that needed to replace their mission-critical systems. These organizations hired me to guide them through the procurement process to find a qualified IT provider to develop and implement their replacement systems. I had the deep domain knowledge and systems background they were looking for, not to mention that I was one of a handful of contractors that was not employed by one of the IT providers.

Until I assisted in the development of their procurement documents, I had no idea of the complexity involved in putting together a comprehensive, fair, and competitive bidding process. I also had no idea how dysfunctional parts of those existing processes were.

My first surprise was to learn that none of these organizations had formalized procurement management processes in place. To be fair, they had centralized procurement offices, all of which operated with bureaucratic procurement processes; however, these tended to be generic, one-size-fits-all processes that allowed little leeway for the business areas to insert their distinctive procurement requirements.

I now understood why some of the bids that I had worked on in my corporate life had such onerous proposal response requirements. They made no sense at the time – well, they still really make little sense.

Rather than fight the established bureaucracy, our team established its own procurement management process to produce RFPs that would solicit qualified bids. While working (somewhat) within the procurement offices’ constraints, we created procurement plans that, coincidentally, line up well with the procurement management process documented in the PMBOK® Guide (Project Management Institute, 2017, pp.475-481).

We followed a 14-step process to develop and issue the RFP:

  1. Develop procurement strategy. This step was largely dictated by the organizations’ existing rules for large IT procurements, although there was some flexibility to allow us to tailor the procurement specifically to the business area. Procurement required that the resulting contracts be firm fixed price. The IT provider must follow an industry standard system development lifecycle (SDLC) with periodic gate reviews at the end of significant phases. We created a list of mandatory deliverables to be produced by the IT provider as dictated by its proposed SDLC. Payment terms stipulated payment upon deliverable approval with a percentage hold-back payable upon gate review completion.
  2. Prepare a Statement of Work (SOW). The SOW was the most labor-intensive aspect of our procurement processes. We conducted a series of workshops to solicit the high-level system requirements, including mandatory requirements from the major project sponsors. We captured the overall functional, technical, process, quality, training, and implementation specifications for the entire projects. In all of this, our intent was to provide the potential bidders with enough detail to formulate credible bids, but not dictate solutions that could limit potential bidders.
  3. Coordinate procurement with other aspects of preparation for the project. Because of the protracted nature of the effort required to create the RFPs, our procurement development plans were executed using several parallel tracks. The procurement task itself was the critical path; however, this task needed to be coordinated with all the ancillary tasks required to produce the RFPs.

    Additionally, we coordinated informally with the procurement offices to ensure that we did not stray outside of certain constraints. It was important that everyone was on board with the same desired outcome; thus, we involved many staff members from the organizations to put their mark on the final bid documents.

  4. Develop timetable of key procurement activities. As the project requirements began to flesh out, we developed a sense of the size of the overall efforts. The procurement offices provided us with the key procurement activities which we were required to adhere to.

    We laid out the timetables. The most complex aspects of the timelines were deciding on how much time would be needed by the IT providers to respond to the RFPs, how much time our proposal review team needed to score the proposals, and again how much time to provide for oral presentations, final scoring, and potential best and final offers.

    The IT provider community depends on these dates to be able to juggle staffing for our projects with their other project obligations. Similarly, the major project sponsors rely on these dates to establish project funding.

  5. Document constraints and assumptions that could affect the procurement. These procurements were very large and complex, and they came with “strings attached”. The major project sponsors, particularly the funding agencies, had well-established criteria that had to be met. The business areas had expectations on how their end-users would be served and how they in turn would serve their clientele. Certain legislative mandates needed to be met by dates certain.

    These and many more assumptions and constraints were documented in the RFPs to ensure that the IT providers understood that they were subject to them and to bid accordingly.

  6. Negotiate changes to boilerplate procurement terms. Dealing with bureaucracy is never easy. It seems that standalone procurement offices were islands unto themselves. They were never to be questioned or challenged.

    We had one simple question for them whenever we requested relief (on behalf of the eventual IT provider) from a difficult term or condition: “Do you want to attract the best possible IT provider for this project?” Of course, the answer was always, “Yes”. This then gave us the opportunity to offer suggestions for updating the onerous terms.

    For example, these organizations are fond of including a clause in the RFPs (which becomes contractual language) that places unlimited liability for nonperformance onto the IT provider. We were able to show the procurement office that qualified providers would not risk their entire company to take on such risk. Smaller providers with nothing to lose might willingly take that risk – after all, their limited assets would not be sufficient to cover unlimited liability; but neither would they be likely to complete the projects successfully.

  7. Define stakeholder roles and responsibilities related to the procurement. Upon selection of the winning IT provider, most of the responsibility for project completion is transferred to the provider. However, detailed requirements definition, deliverables review and approval, major business decisions, change request approvals, liaison with the project sponsors, user acceptance testing, and other such project activities were responsibilities that were kept in-house within the business areas. We documented the roles and responsibilities of each of the parties and included them in the RFPs to inform the bidders’ responses.
  8. Develop procurement metrics to manage the contract. Because of the mandatory constraints on the projects, the contractual implementation dates, and the number of deliverables with their corresponding review and approval cycles, we developed a set of procurement metrics that the providers were required to adhere to. These metrics included such elements as the project reporting cadence, acceptable staff turnover, acceptable defect rates, and others by which we could measure the providers’ progress.
  9. Prequalify IT providers. Again, because of the size and complexity of these projects, it was important to the organizations they received quality bids from qualified providers. Unqualified bids require major effort by the review teams to document why they should be disqualified, so eliminating these bids from even being submitted saves thousands of hours of time.

    In my corporate life, I was the proposal lead for an IT firm that was bidding a large contract. I arrived at the client’s bid opening with three bankers’ boxes filled with our proposal response. One of the competing provider’s representative was shocked at the size of our response. Their response fit into a single manila envelope. Clearly, it was not going to be a qualified bid.

    For these engagements, our strategy to qualify bidders was to first issue Requests for Information (RFI) to determine the interest from the IT provider community. We requested interested bidders to offer high-level solutions and pricing estimates based on the skeletal requirements we had included in the RFIs. Not only did this help us gauge which firms might be interested in bidding our projects, but it helped us hone our formal RFPs with regard to overall budgets and potential solutions.

  10. Develop independent estimates and potential high-level solutions. As noted in the previous step, we used the RFI process to calculate base cost estimates and to understand potential viable solutions. We augmented the RFI responses with our own team’s expertise to arrive at what we believed were plausible solutions and credible project budgets. This helped us solidify the content of the RFPs.
  11. Document risks and risk responses in selecting the IT provider. The major risks in selecting the IT providers have been alluded to earlier. Because the procurement strategy required turnkey solutions to be delivered for a firm fixed price, we wrote the RFPs such that much of the risk was transferred to the IT providers.

    The IT providers were responsible for managing the project deliverables according to the project schedule, procuring project staff and computer equipment timely, involving the organizations’ staff according to their project responsibilities in a timely fashion, and implementing the system on time and within budget. To help ensure IT provider compliance, we required bid bonds, performance bonds, and deliverables payment holdbacks.

  12. Develop evaluation criteria. Selecting the eventual IT provider is a complex and delicate task. On the one hand, if selection is based on low bid, the organization may suffer a project failure or not meet all of their project objectives. On the other hand, if the selection is based on most elaborate technical solution, the price may far exceed the available funds.

    Our strategy was to establish scoring criteria such that we received the optimum solutions for the best price – which did not necessarily mean the lowest price. We established scoring percentages based on several criteria: the proven capability and capacity of the IT provider, price, schedule, technical expertise, approach to project execution, staff qualifications, corporate financial stability, and proven project management experience.

  13. Prepare the RFP and obtain approvals. The previous steps were completed over several months, culminating in well-documented and well-structured RFPs. We walked the fine line of describing our system requirements without dictating expected solutions. We then obtained approval from the procurement offices and major sponsors.
  14. Advertise the opportunity and release the bid. Having prequalified several bidders through the RFI processes, we sent announcements to those bidders on when, where, and how to retrieve the bid documents. The RFPs were also advertised widely to provide other qualified firms the opportunity to bid.

    I introduced this topic with a quip about seeing how the sausage was made. In some ways, it truly was akin to sausage-making in that there were few formalized processes in place outside of the bureaucratic dos and don’ts. While we did augment the existing processes, we focused on the people aspects of procurement management, seeking to find the optimum solutions for the organizations’ problems, using the most qualified IT providers available.

Footnotes

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Newton Square, PA: PMI Publications, 2017, Print.


Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.