Overview of the procurement approach and instructions for completing the tender document pack

Table of Contents

1.  Introduction

The approach originated in 1989 when I set out to bring “the disciplines of engineering to the Information Technology and ERP industry”.  A key element of that vision is to achieve the extremely high levels of certainty and reliability with regard to outcome that characterizes engineering projects.  This can be summarized by the statement “when you approach an engineer to design a bridge you get the bridge that you asked for and it stands up.

One of the discoveries that I made early on in this process was that about 70% of IT and ERP projects failed outright and that a further 20% materially failed to meet management expectations.  By 2003 the Financial Mail reported that “19 out of 20 ERP Implementations do not deliver what was promised”.  Subsequently reports leaked out of major failures in major multi-national companies, Dow Chemicals, Nike and Disney were mentioned but facts are hard to come by.  Other reports continue to indicate that ERP implementations are either failing outright or are failing to deliver on management expectations.  Gartner reported some years ago that despite the huge investments in ERP and Business Intelligence “most organizations are not making better decisions than five years ago”.  Overall, the indications are that the situation may well be deteriorating rather than improving.  I attribute a lot of these failures to the absence of an Engineering Approach in the ERP industry generally.

Throughout this time I have been progressively testing methods based on my engineering and other training, finding things that work, and things that do not work and refining my methods.

For many years, based on my initial Civil Engineering grounding, I have been seeking a way to conduct the specification of requirements and manage the procurement in such a way that a robust and enforceable contract that safeguards the clients’ interests is achieved.  I have been involved in assisting clients with procurement for about 25 years and have progressively refined the approach and gathered information that pointed to possible techniques.  Recently I have run a number of procurement processes to a standard that I regard as “moderately successful” one of which finally delivered a high value and appropriate outcome to the client at a cost that I estimate was about 25% of the true cost to the Implementer because we had managed to pin down a robust definition of the requirement, robust tender documents and a robust and enforceable contract.

All of this experience came to a head when Client Executive contracted me to design the procurement process for the new ERP for Client – by pooling our collective knowledge and experience we have, I believe, developed an exceptionally robust process design together with an extremely solid document pack which draws heavily on the Engineering model.

This document sets out the headlines of the approach and the thinking behind the approach so that these are on record when Client are ready to go ahead with the procurement.  Notes are also provided with regard to the work that still needs to be done before these documents are ready to go out to Tender.

 

2.  Principles applied in the approach

The following broad principles characterize the approach.

2.1 Maximize risk carried by Implementer and Vendor to achieve equitable risk

Transfer the risk that belongs with the Implementer and the Software Vendor to them.  Conventional ERP and IT contracts are generally one sided and transfer most of the risk to the client.  The approach used here is directed at achieving a robust, enforceable contract that equitably shares risk according to the ability of the parties to manage that risk.

2.2 High level of Professional accountability of Implementer

Require a comparable level of Professional Accountability from the Implementer as is required from Engineers in the Main Business Area Industry.  This includes severe penalties for negligence.  They are the experts, they know their software and what is required to implement it, they must systematically gain knowledge of the business of the Client and develop a detailed design and be accountable for the effectiveness of the solution.

2.3 Rigorously define the Requirement

Rigorously define the Requirement such that change in scope is excluded unless the clients business changes tangibly at a significant level – this is the big piece of work to be done at Client before they can go out to Tender.  This includes a comprehensive catalogued and prioritized “Collection of Reference Documents” – discussed further down.

2.4 Close traditional loopholes – enforceable fixed price

Close all the traditional loopholes in ERP contracts, items such as deliberate underpricing and deliberate omission of items.  This is achieved by setting a tolerance on the first, second and third offer prices which limit the extent to which the final price may exceed each of these offers.  This is coupled to clauses that give the final bidder unlimited access to the business in order to fully discover the exact requirement before finalizing their price.

2.5 Three stage progressive price elaboration

The procurement process involves three formal stages starting with a widely distributed invitation to bid extended to Software Vendors and other parties that it is considered appropriate to invite:

2.5.1 First bids based on the full documentation pack and limited direct exposure to the business.  From these bids a short list of three to four bidders is expected to result.  The final price may not exceed this price by more than 40%.

2.5.2 Second bids by the short list following more detailed exposure to the business and more detailed exposure of the business to the bidders and their offerings.  The final price may not exceed this price by more than 20%.

2.5.3 A final negotiated price developed with the preferred bidder based on in-depth discovery and requirements sessions facilitated by the Implementer to ensure that their team is fully informed about the Client Business and that the requirements are fully understood and documented.  Concurrently with this process the final project plan will developed and all contractual negotiations will take place.

2.6 Detailed Bill of Services leads to “allowables” based payments

The approach place considerable reliance on a very detailed “Bill of Services” drawn up by the Client’s independent Consulting ERP Engineer.  Bidders are given the option to ignore items and to add in more detail.  The final Bill of Services forms the basis of an allowables based payment approach similar to that in the Main Business Area Industry – if there is no allowable there is no payment.

An agreed contingency to be jointly managed may be agreed.

A 10% performance retention will be withheld on all intermediate milestone payments and released against Certificate at key stages.

2.7 Client Compact with regard to conduct of Client Staff

Terms governing the conduct of Client Personnel and guaranteeing that the right people will be in the room for workshops and give full attention, that sessions will start on time and not be cancelled at the last minute, that documents will be thoroughly reviewed in accordance with laid down schedules, etc.  There are payments to the Implementer over and above the fixed fee in the case of non-performance by the Client in any of these areas.  This is a vital counterpoint to the robust contractual terms and penalties on the Implementer.

2.8 Robust contracting of Implementer Personnel including Continuity

Robust terms relating to the caliber of consultants supplied, guarantees with regard to availability, continuity, competence, etc to ensure that quality work is done.

2.9 Certificate based payment approach

Certificate based payment approach with formal acceptance of written stated accountability and impact coupled to multi-level authorization that ensures that each person signing the certificate thinks twice before signing.  Possession of a signed certificate entitles the Implementer to raise extra charges if they can prove that their work is in accordance with the documentation or other item covered by the Certificate and that changes are being requested outside what was agreed to.

2.10 Lawyer on the project team

A lawyer on the project team – Client Legal Advisor attends key meetings and reviews key documents in order to ensure contract compliance and send a clear message that there IS an intention to take action in the case of non-performance.  Having this in place focusses all parties on ensuring that such legal action is not required.

2.11 Independent ERP Engineer as Project Facilitator

The Client is advised and supported by a highly experienced “ERP Consulting Engineer” as Project Facilitator.  This person serves as an advisor to the client and is NOT a “Project Manager” – the Project Management rests with the Implementer.  The Project Facilitator monitors, guides, facilitates, translates and exercises quality control in support of the Client Executive Sponsor.  This person does not exercise control over the Implementer, such control is exercised by the Client Executive Sponsor based on advice from the Project Facilitator.  This is broadly the role placed by the Consulting Architect / Consulting Engineer but tailored to the ERP implementation context and adapted considerably to fit the very specific dynamics of such a project.

2.12 Owner Contract Manager

The Owner (Client) Contract Manager is an executive who manages the Implementer contractually and coordinates the input of the Business Team.  In traditional language this role is that of “Client Project Manager” but this term is avoided in order to prevent any misunderstanding with regard to where the overall coordination, administration and execution management of the project rests.

2.13 Precision Configuration based approach

The Implementation will be based on the “Precision Configuration” principles advocated by myself (James Robertson), this is a vital element of ensuring a high value, high reliability outcome – the definition of who will lead this element of the project must be clearly agreed as part of Client’s actions to finalize the Request for Proposal pack.

2.14 High level of Executive Custody

A high level of Executive Custody coupled to high levels of Business Engagement is provided for with the CEO or Deputy CEO serving as Executive Sponsor liaising directly with the Implementer Executive Sponsor (also an Executive) in order to ensure that the project is directed at the right level.

2.15 Implementer Strategic Solution Architect

The Implementer Strategic Solution Architect is a highly experienced a very senior strategically orientated ERP Implementation expert who understands the Client Business and who is responsible for making sure that the entire solution fits together.  This person’s role includes facilitating all key workshops.

2.16  Basil Rad Senior Business Advisory Team at Executive level

The Senior Business Advisory Team is a panel of Executives representing all areas of the business who are chaired by one of their members or the Project Executive Sponsor.  This team is responsible for ensuring that the project receives “top down” strategic guidance from the business, that the right people are in every sub-team and that the Implementer Team has access to the best possible insight into the business and how it runs flowing from a high level strategic view.

2.17  Highly detailed project schedule

The final Project Schedule will be a highly detailed Gantt Chart based on the Bill of Services but refined down to the level of individual tasks with a duration of one to three weeks maximum such that tasks are either not begun, in process or completed in Project Board meeting report packs and no task is in progress for more than one Project Board meeting.

2.18  Strict terms with opt-out provision

The entire approach is based on a very robust and thorough method and contractual terms in the Request for Proposal.  There are provisions for bidders to decline to comply with specific terms with the understanding that this may prejudice them.  This allows us to refine the terms during the process in the event that we find that all or most bidders are finding a particular clause too onerous and there is willingness to relax this clause.

2.19  Laboratory Approach

The configuration will be comprehensively tested, reports and training material developed and training given in a formal “Business Systems Engineering Laboratory” as defined in a separate document.  This rigorous approach to testing configuration and developing reporting and training material is a fundamental element of ensuring a high value sustainable outcome.

These principles have informed the overall approach, there are many other principles and concepts that have been applied and woven into the approach but which do not seen necessary to comment on at this point.

 

3.  Overview of the Contents of the Request for Proposal Pack and what still needs to be done by Client

The following documents, supplied electronically and on paper, make up the Request for Proposal Pack and are discussed briefly below together with comments on what still has to be done before Client can go out to tender.

00a Briefing Attendance Register

The briefing Attendance Register is for use at the various briefings.

00b Table of File Contents

This section of the document is structured in accordance with the Table of File contents.

01 Invitation to Bid

Letter to issue to prospective bidders must be transferred to letterhead and adjusted as required.

02 Confidentiality and Non-Disclosure Agreement

This is a suggestion, Client my want to have their Legal Advisors draft a much more rigorous document.  This document is intended to be issued to prospective bidders before they are admitted to the first briefing and it therefore needs to be sufficiently concise that the process is not delayed.

There is reciprocity insofar as bidders will be disclosing very detailed information about their methods and prices and they are therefore entitled to comparable protection in terms of Confidentiality and Non-Disclosure.

03 Request for Proposal

Contractually the Request for Proposal (RFP) contains most of the contractual clauses and sets the tone for the entire procurement.  This document has evolved from a number of predecessors and Client Executive and I have put in considerable time into refining it.  I am therefore confident that it is a solid document.  However, it must be subject to thorough legal review and amendment as necessary to arrive at a legally enforceable document that will form the basis of the contract.  If any changes are made elsewhere in the document pack the RFP will need to be harmonized with them.

04 Headline Requirement Specification

The Headline Requirement Specification sets out the requirement from a strategic executive perspective.  The present document is very much in a concept draft form and requires a senior analyst, such as myself, to interview one on one each of the executives and senior managers responsible for all of these areas, distil the essence of the requirement from them, document it, review it with them and further refine until they are satisfied that each section in this document is a solid high level statement of what is required in order to operate that business element.

A high quality document here will play a very big role in achieving a high quality outcome and a poor quality document here will have the reverse impact.  This element is not a large amount of time but it is a limited amount of high quality work both in terms of the involvement of executives and senior managers and also in terms of facilitation by a highly experienced analyst.  The wrong analyst in this role will set the project up for at best a sub-optimal outcome and at worst outright failure.

04b Client Mining – Summary of Points from Executive Interview with the CEO -- Antonie Fourie

This document needs to be reviewed with Antonie before it is incorporated into the Headline Requirements.

05 Laboratory Approach

This document sets out the Laboratory Approach in quite a bit of detail including the overall workflow.  These steps tie into corresponding detail in the Bill of Services.  The setting up and operation of this Laboratory will be a key aspect of final planning and then project initiation.

06 Standard Client Procurement Documents

Whatever standard documents Client want to include in accordance with their Supply-Chain-Management and other protocols.

07 Client Integrated Annual Report

The Client Integrated Annual Report as background and context so that bidders have a solid understanding of the basics of the business.

08a Requirements Discovery Plan

This is the plan that I drew up for myself when it was expected that I would carry out the work.  This will need to be adapted to the availability and approach of whoever is contracted to do this work when Client go ahead with the project.

08b Procurement Timeline

This is the schedule that was drawn up based on the tentative approval given in October 2012, it will need to be adjusted once the project is formally initiated.

09 Business Unit Schedule

A tentative listing of major business units in accordance with the Annual Report.  This will require consideration at the executive level with additional detail needed from the Corporate Administration function.

10 Schedule of Required Software

This schedule is tentative and will almost certainly change and be refined during the detailed initial requirements workshops.  It forms the basis of the relevant components in the Bill of Services, Bid Compliance Checklist and Bid Adjudication Schedule in addition to the logic in the Headline Requirements document and the Detail Requirements document.

11 Bill of Services + Summary + Rate Schedule

In a sense the Bill of Services is the heart of the commercial offer.  This provides the detail of every piece of work to be done together with the allowable fee associated with each piece of work.  This will need to be refined in accordance with the outputs of the Headline and Detailed Requirements analysis.

12 Bid Compliance Checklist

The Bid Compliance Checklist started out as a checklist to be used by the Adjudication team to ensure compliance before undertaking detailed adjudication of bids.  It was then realized that by providing this document to the bidders electronically and in hard copy they would be better able to check the completeness of their offering so this document therefore forms part of the RFP Pack for distribution and response.  This document must be harmonized with whatever changes are made elsewhere in the document pack.

13a Bid Adjudication Schedule

The Bid Adjudication Schedule also started out as an internal document but is now included in the pack for the bidders in order to ensure that they understand Client’s priorities and are able to make sure that they address them all.

This document is very much a concept draft for review.  It needs to be discussed with the Business Executives involved with the project in order to ensure that the lists and the weights accurately reflect the priorities of the business.

13b Gut Feel Schedule – possibly not for distribution

The Gut Feel Schedule originated during a procurement where it was recognized that there was a need for a headline level “gut” assessment in addition to the more tangible Bid Adjudication Schedule.

This document also requires comprehensive Executive Review and Refinement.

Client may prefer to withhold this document from bidders.

14 Table of Contents of Submission

The purpose of this document is to ensure that all offers are structured in exactly the same way thereby facilitating comparing offers quickly and easily.

All bidders are required to comply with this Table of Contents.

15 Certificates to Use on the Project

These are drafts for discussion.  There are probably others that need to be added and the wording needs to be reviewed and tightened up by a Lawyer.  These certificates are a key element of creating a psychological context of accountability that focusses all team members on doing the job right no matter what the other pressures.

16a Detailed Requirements Specification

At this stage this is just a place holder.

The detailed document must be built on top of the Headline Requirements once these have been determined and documented.

16b Client Division 2 – Preparation and Agenda for first round requirements workshops

This is a sample to be adapted to workshops in each business unit.

17 Schedule of Reference Documents

The document included here is simply the opening plus the template for the entire catalogue.

Populating this set of appendices, which will run to a significant number of Lever Arch files, should proceed hand in hand with the development of the Detailed Requirement.

The collection should be rigorously comprehensive and Business Unit heads should be required to certify that all documents are included.

Printouts of all spreadsheets in use and inputs and outputs from any custom software is required.

The complete Reference Document pack will be issued to all first round bidders.  They may be required to return the original and all copies if they are filtered out but nevertheless I recommend that all sensitive information should either be redacted with a black marker or other means or removed in the electronic copy before printing.

The final preferred bidder will need to be given a complete set of documents WITHOUT redaction so the pack must be assembled with this in mind in order to avoid a massive administrative headache when the final stage of the procurement process commences.

The assembly of this collection should proceed hand in hand with the detailed requirements workshops.  In other words documents should be brought to the workshop, discussed and rated in terms of importance and additional information recorded as necessary.  The Headline Requirements Workshops should focus on headlines and NOT documents. 

The overall approach requires a comprehensive and rigorous documentation process before Client can go out to Tender.  This should be viewed as comparable to the work done by the Architects and to some extent Consulting Engineers before a Main Business Area tender is put to the market.

I hope that the above adequately introduces the approach and what still needs to be done.  Please do not hesitate to email or phone if you require further information.  I would be delighted to assist in taking Client through the next stages of the process should the opportunity present itself.

Dr James A Robertson PrEng

24 March 2013

Download 00a Approach and Instructions for Completion in Microsoft Word docx format

Sort by: Newest First Oldest First Most Popular Most unliked