Procurement Documents

Full set of the standard procurement documents that I supply to clients who make use of my services with regard to systems procurement

The documents are redacted and in some cases fairly large components that are client specific have been deleted.  The document set is a mixture from different clients to provide practical examples

I offer a full range of services to undertake the strategic requirements analysis, tailor the procurement plan and documents to your specific requirements and facilitate the procurement process

There is still content to be added to this page and formatting of the content already added, please accept my apologies for the inconvenience and email me should you require more information

<<< PREVIOUS SUB-SUB-SECTION:  Part 3 -- Executive Engagement, Bid Compliance, Adjudication and other matters

NEXT SECTION:  Guidance and Advisory Services >>>

JARandA Standard Procurement Documents

The full document pack in WinZip format is available to download using the link below.  Individual documents are available on the links at the end of each section

Download Complete Document Pack in WinZip zip format

00a Approach and Instructions for Completion

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


Draft for Discussion


Procurement Approach

and Instructions for Completion

of the Request for Proposal Pack

Relating to Procurement of a


Integrated Business Information Systems Solution


Main Business Area Management, Supply Chain 

Management, Data Warehousing, ERP 

and other software together with

Integration, Implementation and

Project Management Services

For the Client Group

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

00b Invitation to Bid

A simple invitation letter which you can tailor and elaborate on as you see fit.

Invitation to Assemble a Team to Bid

to Supply a Financial Solution and Data Warehouse for Client

It gives us great pleasure to invite your company to assemble a team to supply, configure and commission a Financial Systems solution and associated Data Warehouse for Client in accordance with the requirements and tender procedure that we have developed.

This solution must share data with our proprietary in-house developed software suite.

Your offer should include provision, configuration, commissioning and support of the required software modules by a highly experienced and dependable team who will work with us to craft a solution that will support the business for many years to come.

We will provide you with a detailed request for proposal and supporting sample documentation and outline the tender process at a briefing to be held at our offices at 10h00 on Thursday 8 May 2014.

Kindly RSVP … and provide details of delegates.

Directions to our offices are attached.

We look forward to meeting your team at the briefing.

Yours faithfully

Chief Executive

Download 00b Invitation to Bid in Microsoft Word docx format

00c Confidentiality and Non-Disclosure Agreement

A simple confidentiality and non-disclosure agreement which you can tailor and elaborate on as you see fit and which may vary depending on your legal jurisdiction and your attorney.  I recommend that this initial document is kept simple as you want ALL persons attending the initial tender briefings to sign this

You would possibly have a much more comprehensive agreement for your short list bidders and possibly more comprehensive still for your final choice although I personally hold that very detailed documents of this sort tend to be excessive


Given by:- . . . . . . . . . . . . . . . . . . . . . . . . .  ID Number : . . . . . . . . . . . . . . . . . .

(“The recipient”)

On behalf of:- . . . . . . . . . . . . . . . . . . . . . . . Company Number : . . . . . . . . . . . .

(“The recipient COMPANY”)

In favour of Client (Pty) Ltd

(“the Discloser”)

By attending this briefing, the Recipient shall be privy to, and receive highly strategic, privileged and confidential information from the Discloser.

The Recipient agrees that:-

1.     He / she is duly authorized by Recipient Company to represent Recipient Company

2.     He / she shall acquire no right, title or interest in any information disclosed to it by the Discloser pursuant to this Undertaking.

3.     He / she shall not disclose, publish, utilise, employ, exploit or in any other manner whatsoever use the confidential information in any manner, for any reason or purpose whatsoever other than for the purpose of preparing a tender submission to Client without the prior written consent of the Discloser, which consent may be withheld in the sole and absolute discretion of the Discloser.

4.     Where this information is disclosed to personnel and contractors of the Recipient and associated companies for the purpose of responding to this tender inquiry such personnel will be required to comply with the terms of this agreement.

5.     Any unauthorised publication or other disclosure of the confidential information may cause irreparable loss, harm and damage to the Discloser. 

6.     This Undertaking shall remain in force for a period of 3 years after the date of signature thereof by the Recipient.

The Recipient undertakes that in respect of the confidential information it shall owe the Discloser a duty of the utmost good faith and shall not in any way act in a manner which is inequitable towards the Discloser.

Dated at: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  on this the  . . . . . day of   . . . . . . . . . . . . . 2014.

Signature: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Name (please print): . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Download 00c Confidentiality and Non-Disclosure Agreement in Microsoft Word docx format

00d Attendance Register

Simple attendance register
Client -- First Tender Briefing -- (Date)-- Attendance Register
First Name Surname Company Email Address Mobile Phone File Taken NDA Signed


Download 00d Attendance Register in Microsoft Excel xlsx format

00e File Table of Contents

The tender documents are issued in one or more large files, this is the table of contents for the file

Client Request for Proposal for a 

Financial Systems Solution

Table of File Contents

1.    Invitation to Bid and Confidentiality and Non-Disclosure Agreement

2.    Request for Proposal

3.    Headline Requirements Specification

4.    Procurement Timeline

5.    Schedule of Required Software

6.    Bill of Services + summary + rate schedule

7.    Bid Compliance Checklist

8.    Adjudication Schedule

9.    Table of Contents to be used for submission files

10.    Certificates to be used on the project

11.    Schedule of Reference Documents

Download 00e File Table of Contents in Microsoft Word docx format

01 Request for Proposal for Business Systems Solution

This is the heart of the tender and contains a large number of tough clauses that are directed at ensuring a realistic bid with a robust platform for realistic negotiation and a tough contract that is directed at ensuring performance

There is a more detailed version of this document at the end of this page for larger projects with a more detailed procurement process

Request for Proposal

Relating to an

Integrated Financial Solution


A Financial Suite and Data Warehouse,


Data Sharing, Implementation and

Project Management Services


Table of Contents

1.  Request for Proposal......................................................................... 2

1.1    Introduction............................................................................ 2

1.2    Overview................................................................................ 2

1.3    Project Objectives.................................................................. 2

1.4    Headlines of Approach........................................................... 2

1.5    Submission of Proposals........................................................ 4

1.6    Terms of Engagement............................................................ 4

1.7    Pricing Approach.................................................................... 8

1.8    Scope of Work........................................................................ 12

1.9    Proposed Client Undertakings to Balance Fixed Price........... 16

1.10  General Requirements............................................................ 19

1.11  Project Governance – Project Board and Project Management Team................................................................................................ 20

1.12  Key Personnel......................................................................... 21

1.13  Track Record........................................................................... 22

1.14  Extent of Work – Project Schedule.......................................... 22

1.15  Retention.................................................................................. 23

1.16  Conditions for Proposals.......................................................... 23

1.17  Multi-Party Proposals through a Single Prime Contractor........ 25

1.18  Key Contact Person................................................................. 26

1.19  Assistance to Organizations Submitting Proposals.................. 27

1.21  Timing....................................................................................... 27

1.22  General Notice.......................................................................... 27

2.  Project Governance and Roles............................................................. 28

2.1    Overview of governance........................................................... 28

2.2    Detailed specification of roles................................................... 30

2.3    Reporting and Monitoring on the Project.................................. 35

3.  Critical Implementer Selection Criteria................................................. 36

4   Business Systems Laboratory.............................................................. 40

5   Procurement process............................................................................ 41

6   Headline Requirements and Reference Documents............................. 43

7   Conclusion............................................................................................. 44


1. Request for Proposal

1.1      Introduction

This document will form the basis of the evaluation process.

Bidders are required to conduct themselves as trusted professional advisors and take all necessary steps to ensure a high value, high quality, and sustainable project outcome.

The final solution should be tailored to the exact way of doing business of Client.


1.2      Overview

Client is a moderate size ….

Client currently operates in … and the rest of the world and is expanding rapidly.

This document is targeted at Business Information System (ERP) Software Vendors with the intention that these parties will assemble the most suitable software and implementation tea to bid on this project.  The document sets out the requirements with a view to software vendors and implementers making formal submissions.  The goal is to work towards a negotiated fixed price for the project and towards this end vendors and implementers are expected to engage with us during the Tender Process in order to be able to offer a fixed price.


1.3      Project Objectives

1.3.1 To specify and procure a comprehensive Financial Suite and Data warehouse and data sharing solution which is capable of serving Client for the next twenty years.

1.3.2 To implement this software and associated services by means of a tightly run, high quality, systems engineering project with maximum business engagement and optimum solution fit at optimized low cost.


1.4      Headlines of Approach

1.4.1 Position the new Client systems to support optimum operational effectiveness in support of strategic growth objectives;

1.4.2 Create a strategic resource that supports competitive advantage;

1.4.3 Robust engineering approach in all respects;

1.4.4 Submission of an offer constitutes an explicit guarantee that the offer fully meets the requirement stated in this RFP, unless explicitly excluded, within the specified costs.  An affidavit confirming this is required;

1.4.5 This RFP is specifically targeted at Software Vendors who are required to nominate and partner with the most appropriately qualified Implementers, Integrators and Project Managers;

1.4.6  A single legal entity as Prime Contractor, which may be either the Software Vendor or an Implementer / Integrator, is required to take full responsibility for all components of the offer and the ultimate solution.  This Prime Contractor may collate an offering comprising multiple software products and / or implementation partners;

1.4.7 The offer must be made by a single Prime Contractor who accepts full contractual responsibility for the performance of the software as well as the performance of their team including performance of sub-contractors and partners;

1.4.8 Key Implementation Personnel to be committed for the duration of the project;

1.4.9 Precision configuration -- all configuration and validation data will be designed in consultation with Client to high standards of structure and precision – to be facilitated by Dr James Robertson to the standards advocated by him; 

1.4.10 Client owns the data engineering which will be developed with the assistance of the Project Facilitator.  Includes Chart of Accounts and other taxonomies, master data and differentiating business processes;

1.4.11 Acceptance of each review cycle of specifications, testing or any other iterative refinement process will include a formal declaration by both the Client team members involved AND the Implementer team members involved that the iteration has been thoroughly and rigorously executed – both sides will face sanction if it is found that this declaration is unfounded.  Refer to the form in Section 10 of this file;

1.4.12 All master data cleaning will be undertaken by a combination of Client personnel and Implementer personnel – split to be agreed;

1.4.13 This document, as accepted during the proposal process, will become an integral part of the Contract Documentation;

1.4.14 Bill of services (allowables) costing approach with fixed price per software and implementation element (including management, configuration and customization);

1.4.15 Client will NOT pay for travelling time or kilometers within Xxx.  Travel outside of Xxx is NOT expected to be required;

1.4.16 There will be NO additional disbursements, travel time or travel costs permitted over and above what is in the Bill of Services unless claimed against the capped contingency under exceptional circumstances;

1.4.17 Proposal documentation is required to exactly follow the Table of Contents contained in Section 9 of this file;

1.4.18 High level of business engagement;

1.4.19 Optimize use of internal resources;

1.4.20 Client will provide office space and furniture for on-site work.

1.5      Submission of Proposals

Submission of Proposals will take place as follows:

Five bound proposal sets together with both a physical and electronic copy of this Request for Proposal and all Annexures signed by an officer of the proposing company to be delivered to the offices of Client at, xxx by 17h00 on Friday the 20th of June 2014.


1.6      Terms of Engagement

The contract is for the supply of a specific system, or combination of systems, together with support of these systems for as long as they are in use at Client or until terminated by Client for any reason.

All submissions must address all requirements for sustainability, access to source code, sustainable support and other issues specified in this document.

This document is supported by other documents of which the Bid Compliance Checklist, Bill of Services and Software Schedule must be fully completed.  The file sections are:

1.  Invitation to Bid

2.  Request for Proposal

3.  Headline Requirements Specification

4.  Procurement Timeline

5.  Schedule of Required Software

6.  Bill of Services + summary + rate schedule

7.  Bid Compliance Checklist

8.  Adjudication Schedule

9.  Table of Contents to be used for submission files

10. Certificates to be used on the project

11. Schedule of Reference Documents

12…. Collections of Reference Documents on a Department by Department basis        

1.6.1  Invitation to Bid

Covering letter.

1.6.2  Request for Proposal

This document.

1.6.3  Headline Requirements Specification

Document setting out the high level requirements.

1.6.4  Procurement Timeline

The timeline for this procurement process.  Bidders are required to diarize these dates and to arrange their affairs in order to attend all briefings.  Failure to attend any of these events may prejudice submissions or result in disqualification.

1.6.5  Schedule of Required Software

Schedule based on items identified by Client from consideration of the Business Requirement – bidders are at liberty to add, combine or strikeout items in order to accurately describe their offer.

1.6.6  Bill of Services + summary + rate schedule

Detailed schedule for cost analysis is provided.  This schedule must be fully completed in the Spreadsheet provided without any structural change and will form the basis of the cost proposal – rows and columns may be added appropriately as required.

The final offer price must be derived directly off this schedule.  This schedule will furthermore form the basis for determining payment quanta and milestones to the successful bidder and will also form the basis of the detailed project schedule.  In the event of a discrepancy between the Bill of Services and other documentation the Bill of Services will be regarded as the final authority with regard to the scope of work and the budget.

The Project Schedule (Gantt Chart) will be derived directly from the Bill of Services.

Project scheduling should take place using a Critical Chain approach (all slack accumulated to the end of the timeline for allocation by the Project Manager in consultation with Client).

The overall approach to pricing the offer is based on the “Bill of Services” which is provided electronically.

All prices and fees must be quoted EXCLUDING VAT.

The Bill of Services lists all the headline activities that we consider necessary to achieve the desired outcome.  Bidders are free to bid in more or less detail than the Bill of Services but it must be noted that the final Bill of Services will form the basis of the contract and all payment and performance milestones will be based on the Bill of Services.

The Bill of Services will give rise to a schedule of “Allowable Fees” which will determine what is paid for every activity.  Every item is required to constitute a fixed price offer and the entire summation of the Bill of Services will give rise to the offer price.

Bidders are required to complete the Spreadsheet supplied by Client electronically and to provide both a signed printed copy and an electronic version of the data that can be used by the adjudication team to evaluate and analyze the offer.

The first round offer must include a high level Gantt Chart based on the Bill of Services.

1.6.7  Bid Compliance Checklist

All the items on this checklist must be furnished and all ite that require signature of declarations must be signed or initialed, as indicated in the table.  If any of the documents listed in this checklist are missing or if any of the required declarations have not been signed the submission may prejudice of disqualify offers.

1.6.8  Bid Adjudication Schedule

This schedule sets out the basis for evaluation.  Proposers are advised to ensure that their offer fully addresses all the criteria set out in this section.  Failure to supply information in support of compliance with all these criteria may prevent the bid adjudication panel from accurately assessing your submission and may therefore prejudice your chances of being awarded the contract.

1.6.9 Table of Contents to be used for submission files

Bid submissions must be in files or bound documents that exactly follow the structure set out in this document.

1.6.10 Certificates to be used on the project

Key documents to be used during the offer process and during the operation of the project.

1.6.11 Schedule of Reference Documents

Schedule listing all reference documents in the subsequent sections with brief comments on their importance to the project.

1.6.12 Onwards -- Collections of Reference Documents on a Department by Department basis

Sample Documentation with regard to the manner in which Client currently conducts business within the ambit of this requirement.  This documentation is NOT complete NOR is it definitive in ter of the ite required in the final solution.  It is merely intended to provide contextual information.  The successful bidder is required to budget to undertake COMPREHENSIVE discovery and investigation in order to fully scope the required deliverables.  As a minimum requirement all of these documents and reports MUST be catered for in the bid.


1.7      Pricing Approach

The approach to pricing the contract will be as follows:

1.7.1  The final requirement is for a fixed contract price; 

1.7.2  The Vendor Selection Process will comprise three stages; Stage 1 – Market Scan:

This stage will commence with a presentation of the requirement and the business and handing out of the documentation pack.

First offer is for an all-inclusive price with all options catered for.  Bidders will make a formal presentation of their offer to the adjudication panel.

Bids are required to be presented at a tolerance of 30% on the final price, that is, the final price may NOT exceed the Stage 1 price by more than 30% -- this is in order to discourage deliberate low bidding.

This bid will be evaluated and a short list developed.  It is envisaged that this stage will reduce the number of eligible bidders to around three; Stage 2 – Discovery and Due Diligence:

The short list bidders will be requested to arrange a site visit to one of their clients as a reference site, this will include a private discussion between the adjudication panel and the client concerned with the bidder being absent.

Bidders will also each be granted a four hour working session with Client to gain better understanding of the business and the requirement.

The revised bids are required to be presented with a tolerance of 15% (the final price may not exceed the stage 2 offer price by more than 15%).

Bidders will then deliver a three hour presentation at which they will present their revised offer and answer questions.  Points of clarification with regard to the offer will also be dealt with in this stage.

At the end of this stage a preferred bidder will be selected. Stage 3 (Finalization of Offer and Contracting):

Stage 3 will take place on a fixed price basis as a separately costed item in the bid submission.

The preferred bidder after Stage 2 will engage with Client to finalize the scope of work and the price.  Final price will be a negotiated fixed price after the successful bidder has engaged in:

                                                  i. Detailed discovery;

     ii. Detailed exposure of their software and methods to Client;

                                                  iii. Detailed project planning and budgeting;

                                                  iv. Detailed contractual negotiations; 

The project price and final contract will be agreed and contracted during this stage; Once this final price has been contracted no change of pricing will be considered unless Client fundamentally fails to perform in terms of granting due access to the business or the scale or nature of Client’ business changes materially to the extent that a Change of Scope is negotiated; The final price may include not more than 5% contingency as set by the bidder but draw down on that contingency will require approval by Client and verification that it is related to a real change in the requirement or omission on the part of Client; Bids must include prices for all required operating systems and databases; Bids must specify the exact hardware requirements but should NOT include prices for hardware; Client reserve the right NOT to take all modules or to negotiate a phased approach of agreed duration; Client reserve the right to identify a gap in an offer and to require the bidder to provide software or services to close that gap in order to qualify for Stage 2 or Stage 3; Client reserve the right NOT to accept any offers and to exit the Procurement Process on completion of Stage 1, Stage 2 or Stage 3; Client reserve the right to move directly to Stage 3 on completion of Stage 1 and bypass the short list process should they decide that one offer is far more appropriate than any of the others; Section 1.9 of this document contains a list of undertakings given by Client in order to make a fixed fee practical and equitable.


1.7.3    The Stage 1 offer  must include: Files containing the submission must follow exactly the Table of Contents set out in Section 9 of this file; Overview of the proposed implementation approach; Motivation as to why the proposed software and implementation team is most appropriate to meeting the needs of Client; List of assumptions made in the Cost Proposal; List of contractual  terms that the Implementer is unable to or unwilling to comply with together with proposed alternative terms which are considered acceptable; List of queries and points requiring clarification; List of high level business functionality and / or scope requirements that are not met by the proposed solution and alternative solutions that may be available; Bill of Services (Cost Proposal) fully completed; Summary of professional fee rates for standard work, travelling and standing time per staff designation; Travelling rate per kilometer and any other costs; Schedule of extraordinary or non-standard requirements in the Request for Proposal  that are considered to drive costs excessively (£1,000 minimum per item) – that is drive costs above levels that they would consider necessary in order to produce a high quality outcome – unless such items are identified in the bid there will be no basis for the proposer to later contend that the requirements were unnecessarily onerous.

Bidders are requested to propose changes which could result in material savings whilst maintaining the overall intent of the RFP; Schedule of any other costs that may not be catered for above. A proposal that does not contain detailed pricing in the specified format may be disqualified.


1.8      Scope of Work

The scope of work comprises the supply of a system or combination of systems configured, customized, integrated and fully commissioned to meet the detailed requirements of Client as set out in the Requirements Specification contained in Section 3 of this file.

Deliverables must be installed and implemented at the offices of Client in Xxx.  Remote users must be able to log in to the system if required.

The successful proposer will be required to perform the following:

1.8.1 Provide comprehensive Project Management and Project Administration services;

1.8.2  Provide Change Facilitation (Change Management) services at an agreed level;

1.8.3 Actively and formally manage project risk, taking into account the “Factors causing Business Information Systems investment failure” and the “Critical Factors for Business Information Systems Success” as defined by James Robertson as well as any other identified risk elements.  A comprehensive Risk Register should be maintained for review at Monthly Project Meetings or more frequently as required;

1.8.4 Provide functional and operational software to meet all stated requirements;

1.8.5 Undertake detailed discovery to fully understand the business and scope the requirement;

1.8.6 Develop a detailed specification of the exact business requirement, by module as appropriate, including all necessary facilitation, documentation and other elements required to fully define the optimum business application of the software supplied and ensure its effective and efficient deployment and operationalization within the business;

1.8.7 Undertake a gap analysis identifying shortfalls in the offering relative to the in-depth definition of requirement evaluated in the detailed analysis undertaken in the previous point;

1.8.8 Configure software to fit the requirement.  This will be done in the Laboratory prior to deployment in the live environment (refer discussion to the Laboratory approach document).  Configuration must be designed to work across the entire business and to accommodate future reasonably foreseeable growth.

Configuration will include but NOT be limited to: Software settings; Business Model in the General Ledger and related modules; Master Chart of Accounts and operational Charts of Accounts for individual Business Units – bidders are required to quote for facilitating the design of the Chart of Accounts; Fixed Asset classification; Product classification– note that Client own substantial inventory of xxx devices, components, accessories, etc and that these move constantly between branches and head office as well as moving internationally.  Devices are installed on vehicles and then removed from vehicles at a later date, such as in a repair situation, these devices have serial numbers.  There are other ite that are NOT serialized; Classification of Personnel; Other specific classifications; Unique attributes on Products and other classification master data; General record level attribute settings; Business Process models and workflows; Reports, models and dashboards; Other configuration settings

1.8.9 Establish and operate a comprehensive Business Systems Laboratory in accordance with the laboratory approach document in order to fully test and refine the configuration and optimize as necessary.  Set up the laboratory in conjunction with Client, test reports, standardize and document policies and procedures, create training material, train personnel and refine as necessary using a statistically representative data sample in order to ensure that the software can be deployed in the business with high reliability;

Testing of the complete configuration, including testing of any customization or custom development, will take place in the Laboratory with rigorous representative sample testing by senior business personnel.  The deployment of the software will ONLY take place once these personnel certify that the installation is robust and comprehensive AND once the implementer and the software vendor certify that they are satisfied that ALL possible situations have been thoroughly tested.

Process optimization and documentation, development of reports and business intelligence models, development of training materials and training will ALL take place in the Laboratory PRIOR to commissioning of the software in the business.  Please refer to the detail in the Bill of Services in Section 6 of this file.

Commissioning is the putting into service of the system in the business.

Once the laboratory installation is certified as being fit for deployment all staff will be trained up in the laboratory and ONLY then will production operation commence.

1.8.10 Advise and guide Client with regard to selection of statistically comprehensively representative test data for the Laboratory, take-on of that data, verification of that data;

1.8.11 Customize software if necessary to fit the requirement given that zero customization is preferred.  Any customization or custom development will be required to be undertaken using a fully qualified software development team to internationally recognized software design, construct, test and deploy standards that must be agreed to before development commences.  Design of customization must be undertaken by a senior and highly experienced Solution Architect.  Only developers situated in Xxx, Xxx may be used unless the developers are part of the team that wrote the original software;

1.8.12  Train Client’s staff in all aspects of the operation of the software.  This includes training of the internal implementation team and module specialists {super users} and training of users;

1.8.13 Assist with the cleansing of Master Data.  The level of effort expected from Client personnel to be clearly spelt out in the proposal;

1.8.14 Assist with take-on of Master Data, opening balances and other data to be transferred from the existing systems.  Only essential data will be carried forward other than into the Data Warehouse.  Recommended approach to be clearly discussed in the proposal;

1.8.15 Establish a full featured Data Warehouse and Business Intelligence Environment to accommodate all future data from all modules as well as from the custom developed software in use by Client, unless otherwise agreed and to accommodate all relevant history;

1.8.16 Take-on all history, into the ERP or Data Warehouse as agreed – allow for three stages of history take-on – first take-on, increment since first take-on, final increment;

1.8.17 Assist with verification of take-on data.  Level of involvement to be clearly spelt out in the proposal;

1.8.18 Commission the software in the business until fully operational in ALL respects in terms of the functionality supplied.;

1.8.19 Manage phased acceptance (sign-off) and handover to Client as major milestones are completed, refer to the milestones in the Bill of Services.  Handover is the final acceptance of the system in full production in a component of the business;

1.8.20 Provide hands-on support as required to ensure effective and efficient operation of the software.  This includes hands-on on-site support for: the first month after go-live; the next 3 months; the next 6 months; extra provision for the first month end; first year end; first two months following the above year end; This must include provision for Change Facilitation during these period IF bidders consider this necessary – note that Client is of the view that a well-designed solution should require minimum external Change Facilitation;

1.8.21 Provide hot-line support as required to ensure effective and efficient operation of the software on a long-term basis;

1.8.22 Provide for ongoing support and maintenance of the software;

1.8.23 Provide standard software maintenance, updates and enhancements in perpetuity.  Vendors are required to declare the annual license fees for the first five years and thereafter the maximum year on year license fee increases that will be requested;

1.8.24 Provide rates for custom additions and alterations to the software as required for the first two years after commissioning;

1.8.25  Other services as may be required from time to time.

1.9      Proposed Client Undertakings to Balance Fixed Price

The fixed fee required by Client places the Implementer at risk financially if the Client team does not perform as expected.

Accordingly, the following undertakings are proposed.  Bidders may suggest alternate or additional measures if they consider them appropriate.

In exchange for the fixed price required, Client undertake to: 

1.9.1 Best team

Mobilize appropriately experienced and equipped staff who are able to competently guide the configuration and implementation from a Business perspective and make inputs to the project;

1.9.2 Retain team

Within reason keep this team available for the duration of the project;

1.9.3 Executive engagement

Ensure that the agreed level of Executive Engagement is maintained at all times;

1.9.4 On time, full attendance and full engagement

Ensure that designated personnel arrive on time for all scheduled meetings, work sessions, etc and attend for the full scheduled duration;Ensure that team members engage actively in these sessions i.e. NOT reading emails, sending s’s, or distracted in other ways;

1.9.5 Off-line work diligently and thoroughly performed

Ensure that all off-line (out of workshop) work such as review of documentation, testing, etc is conscientiously carried out with full engagement and constructive contribution by set dates;

1.9.6 Tight management of iterations

Ensure that Client personnel do all that is required in order to complete each iteration of a piece of work thoroughly and diligently such that the work is completed in the agreed number of iterations and to agreed deadlines;

1.9.7 Timeous response to unavoidable time impacts

Timeously notify the Implementer Project Manager and workshop Facilitator in the event of unexpected illness or accident that necessitates rescheduling or substitution;

1.9.8 Reasonable compensation for standing time of Implementer Team members attributable to Client

Pay for standing time when workshops commence late or are rescheduled at the last minute because of late arrival or non-arrival of key Client personnel where it can be demonstrated that the implementer staff member concerned could not be utilized in alternative productive activities;

1.9.9 Schedule delays caused by Client

Make allowance in promised delivery dates for schedule delays in Critical Path ite caused by Client or its personnel;

1.9.10 Pay for extended work or rework resulting from Client team omissions or wrong decisions

Pay for extended work or rework resulting from failure of Client personnel to conscientiously and thoroughly review documents, conduct testing, clean data, etc.  In other words, if an iteration is agreed as complete and then during commissioning it is found that reasonably foreseeable issues were NOT identified during that iteration as a consequence of omission or carelessness on the part of Client staff the implementer will be entitled to payment for the rework or extended work;

1.9.11 Claims for standing time

Where the implementer wants to claim standing time or rework notification of intention to claim must reach the Client Contract Manager within one business day of the event taking place;

1.9.12 Maintain a harmonious team atmosphere at all times

Ensure that team members conduct themselves courteously, constructively and harmoniously and take measures to discipline and, if necessary remove, staff members who become contentious, argumentative or who generate strife;

1.9.13 Notwithstanding the above, Client will NOT pay the Implementer for: Implementer under quoting or under estimating scope

None of the above should be taken as indicating that Client will pay for under quoting or under estimating on the part of the bidder; Implementer sloppiness

Where work has been done by implementer staff that is sub-standard or contains excessive errors indicative of a lack of precision and attention to detail Client reserve the right to “stop the clock” and postpone further work sessions until the work has been redone to an acceptable standard; Implementer team member lack of knowledge or experience

Where Implementer team members are found to lack the knowledge or experience necessary to play their role.

1.10  General Requirements

The overall requirements for the software and solution are as follows:

1.10.1 The software solution shall either comprise a total solution using standard modules from standard packages (which is the preferred solution) or a combination of standard modules integrated with specialist third party modules.  Limited customization may be permitted but is NOT encouraged.

1.10.2 Where it is necessary to integrate with existing systems then appropriate provisions must be made in the Bill of Services and an appropriate contractual agreement with that party must be supplied as part of the Offer Pack;

1.10.3 Where the offering comprises entirely standard software the vendor must warrant at proposal stage that all requirements can be met with the standard software with proper configuration and must include a written guarantee to this effect in their proposal offer.

Configuration of the software must at all times reflect the practical reality of the business as determined by the Client Project Team.  Where there are differences of opinion within the Client Project Team the view of the Executive Sponsor, advised by the Client Project Facilitator will be final.

The lead Implementer Solution Architect responsible for designing the configuration must be highly experienced and be able to operate comfortably at the Executive level and evidence strategic thinking abilities at a level that ensures that the final solution is strategically appropriate and meets long term strategic goals.

1.10.4 Submission of an offer constitutes an implicit guarantee that in the event of it being found that the standard package does NOT fully meet the requirement, the standard package will be modified by the vendor as required or custom development undertaken around the standard software at no extra cost.  A formal certificate confirming acceptance of these ter is provided in Section 10 of this file and is a necessary pre-requisite for the offer to be considered.

1.11   Project Governance – Project Board and Project Management Team

Refer to Section 2 of this document for details of proposed governance and to section Section 2.3 for details of proposed regular project meetings relating to the overall management of the project.

The key roles on the project are:  (should Client CFO be included here)

1.11.1 Client Executive Sponsor – Client CEO -- Client CEO.

1.11.2 Client Internal Systems Executive – Client Executive

1.11.3 Client Project Facilitator – Dr James Robertson 

1.11.4 Client Contract Manager –  Client Manager Xxx

1.11.5 Software Vendor Executive Sponsor

1.11.6 Lead Implementer / Integrator Project Director

1.11.7 Lead Implementer Team Leader

1.11.8 Lead Implementer Strategic Solution Architect

1.11.9 Lead Implementer ERP and Finance Specialist

Implementers are invited to make suggestions for improvement.

1.12   Key Personnel

1.12.1 Bidders must provide a list of the key personnel who will work on the project together with CV's of each of the key personnel as part of their offer as well as other documentation supporting the knowledge and experience that qualifies them for their proposed role.

1.12.2 Senior key personnel must attend the short list proposal presentations (Stage 2) and must be contractually bound to the project;

1.12.3 Key personnel may be interviewed during the short list process (Stage 2) with regard to their knowledge and experience and availability for the project; 

1.12.4 Client reserves the right to decline any key person put forward at the proposal presentation or during subsequent negotiations;

1.12.5 Once the contract has been awarded substitution of key personnel will only be considered in the event of death or serious injury or major illness or other unavoidable circumstance;

1.12.6 Bidders and key personnel are expected to guarantee the availability of key personnel for the duration of the contract – a certificate to this effect is required with regard to each key person put forward and must be signed by the employer, the prime contractor if different to the employer and the team member themselves.  “Transfer to another project”, "received an offer of better employment" or “leaving the country” are NOT acceptable reasons for substitution;

1.12.7 If for any reason any of the key personnel has to be substituted, they may only be substituted by personnel with equivalent knowledge, experience and proven track record.  The need to substitute, plus the details of the person it is proposed to substitute with, must be presented in writing at a formal meeting with Client called to discuss the situation;

1.12.8 Client has the right to veto substitution; if necessary the vendor may have to sub-contract such a team member back in for the duration of the project.  Switching losses including rework and “getting up to speed” of a substitute will be for the account of the implementer;

1.12.9 Failure of the implementer to comply with this requirement may result in cancellation of the contract or suspension of the contract until the implementer complies.  Client will NOT be liable for any costs associated with such contract suspension or termination;

1.12.10 The project will NOT proceed in the absence of the full complement of personnel that formed part of the offer;

1.12.11 Should it be found at any time that a key person does not evidence the level of knowledge, experience and ability presented in the tender submission Client reserves the right to require the replacement of that person;

1.12.12 Key personnel must be available as required at reasonable levels of involvement for critical inputs throughout commissioning and for the first year after formal handover in order to ensure continuity of knowledge and experience of the solution.  In the event that they leave the employ of the Implementer the Implementer will be required to sub-contract them in when required failing which Client reserves the right to contract them directly.

1.13   Track Record

Proposers must furnish comprehensive evidence of their knowledge and experience of implementing the proposed software in Xxx AND in Xxx.  References with contact telephone numbers and email addresses must be furnished and site visits will be required in the case of short list (Stage 2) bidders.

References and reference sites must be logically relevant to Client.  Use of generic non-relevant references or reference sites may result in proposers being disqualified.

1.14   Extent of Work – Project Schedule

Proposers must furnish a high level project schedule based on the Bill of Services (same level of detail and same Work Breakdown Structure).

The final project schedule must be developed to a level of management detail of not more than two weeks elapsed time per work breakdown structure element such that the exact progress of the project relative to plan can be accurately reported at monthly project board meetings.  Any particular work package should be “not commenced”, “in progress” or “completed” at monthly project status meetings and may not be “in progress” for more than one monthly project status meeting – if this rule is broken an orange flag is to be raised and if an activity runs over three status meetings a red flag is to be raised.

James Robertson will give guidance as to how to quickly and effectively build a Gantt Chart to the required level of detail.

1.15   Retention

A performance retention of 10% will be withheld on all interim payments against the following major milestones:

1.15.1 Completion and signed acceptance of the Laboratory Configuration – that is, the entire configuration is accepted for deployment in the business – see certificate in Section 10 of this file.  On acceptance of this certificate 50% the of retention amount withheld to this point will be paid;

1.15.2 Formal declaration of project completion and final handover to Client – at this point the software must have been in FULL operation and fully bedded down and stable with all practical operational issues resolved for thirty days to the satisfaction of the Executive Sponsor – balance of retention will be paid.  See certificate in Section 10 of this file.

1.15.3 Software licenses will be paid as the software is deployed or users are added in the production environment.  Software licenses are not payable for the Laboratory phase.

1.16   Conditions for Proposals

All Proposers responding to this Request for Proposal must meet the following conditions in order to be considered.  See also the Bid Compliance Checklist in Section 7 of this file and the Bid Adjudication Schedule in Section 8 of this file:

1.16.1 Proposers MUST attend the Request for Proposal briefing; 

1.16.2 Proposers must complete all the bid for;

1.16.3 Proposal documentation must be structured according to the Table of Contents provided in Section 9 of this file;

1.16.4 Proposers must fully complete the Schedule of Software, the Bill of Services and the Compliance Checklist;

1.16.5 The submitted price proposal must be based on the Bill of Services;

1.16.6 The proposal must include a covering letter clearly stating the name of the firm and the name, address, and telephone number of the proposer’s representative;

1.16.7 Proposers must certify that they have received, read and understood the Request for Proposal and all accompanying documents and that their proposals take full account of the contents of these documents;

1.16.8 The proposer must address all of the requirements as stated in this document;

1.16.9 The proposer must identify all major (principal) requirement cost driver components in the specification and appendices which drive a cost contribution in excess of R25,000 over and above the standard software product that is being offered – this item relates to implementation costs and contract terms;

1.16.10 Proposers who fail to fully respond to the principal requirements in this Request for Proposal may not be considered;

1.16.11 Proposers must submit five (5) bound copies of their proposal, structured in accordance with the prescribed Table of Contents in Section 9 of this file, to Client together with a full electronic copy on CD;

1.16.12 All proposals submitted must include a section number index, and all pages of the proposal must be numbered on a per section basis;

1.16.13 Proposers must include the Bill of Services cost schedule both in hard copy and electronically -- fully completed – the hard copy must be initialled on every page;

1.16.14   Proposers must return one copy of this Request for Proposal with EVERY PAGE initialled to signify that the Proposer has read and accepts the entire document.  This copy must also be submitted electronically as a scanned pdf;

1.16.15 The organization submitting the proposal shall furnish such additional information as Client may reasonably require during the evaluation process;

1.16.16 Client shall NOT be liable for any costs incurred by bidding organizations in participating in the bidding process – stages 1 and 2;

1.16.17 Client reserves the right to visit the premises of the proposer if deemed necessary;

1.16.18 Any false declaration of information may result in the exclusion of the proposal from consideration.  If a false declaration comes to light once work is in progress all costs associated with consequential impacts of the false declaration will be for the account of the Prime Contractor.  In such event that such false declaration results in direct costs to Client, Client reserve the right to deduct these costs from the Retention or other payments;

1.17   Multi-Party Proposals through a Single Prime Contractor

Client requires a single provider, named the “Prime Contractor”, to offer a complete solution. This solution may comprise one or more standard software products or modules from one or more Software Vendors implemented by one or more Implementation Service suppliers.  Prime Contractors may assemble any mix of products and implementation, integration, project management and technology related service providers as they deem most appropriate.  The Prime Contractor may be a Software Vendor or an Implementation Firm;

1.17.1 There must be a clearly defined Prime Contractor and clearly defined contractual arrangements between the Prime Contractor and each of the other partners;

1.17.2 The Prime Contractor will be held accountable for providing all partner products and services as accepted on award of the contract;

1.17.3 The Prime Contractor should also furnish a document signed by each sub-contractor / partner confirming their agreement with all elements of the proposal relating to their services and software as well as their commitment to the project for its entire duration;

1.17.4 The Prime Contractor must accept full technical and contractual accountability and liability for the performance of all sub-contractors / partners;

1.17.5 The Prime Contractor is required to quote for all services associated with the complete deployment of the solution.

This includes: Detailed requirements analysis Gap analysis Customization if found to be necessary Configuration Testing – including setting up and running a laboratory to test the configuration Commissioning (Implementation) Post implementation support Hot line / help desk support Other support Updates and upgrades Enhancement Other services as may be required from time to time

The full scope of work is set out in the Bill of Services

1.18   Key Contact Person

Bidders must nominate a Key Contact Person who will receive all correspondence with regard to the bid and who will be responsible for ensuring that all other members of their team are updated with such additional information.  Client ONLY accepts responsibility for making such information available to the Key Contact Person.

1.19   Assistance to Organizations Submitting Proposals

Proposers may address requests for information or clarification by email to the following people please include both of these people in all correspondence.  Replies will be made by email to ALL organizations that have been invited to bid:

xxx – Contract Manager

Dr James Robertson – Strategic Advisor to Client at

Cut-off for questions is 16h00 two business days before the due date for submission of offers to Client – that is Wednesday the 23rd of May2014.( James, please confirm)

1.20    Final Approval

Offers will be adjudicated in accordance with the process and schedule set out in detail in the “Procurement Schedule” in Section 5 of this document.

Client reserves the right to accept any offer that is presented and reserves the right to reject all offers if it sees fit.

1.21   Timing

The timing of the procurement process will determine the commencement date of the project.  The successful bidder is expected to commence work within three weeks from acceptance of the final fixed cost proposal and plan and signing of the contract.

1.22   General Notice

The selection of the preferred contractor will be based on the criteria in the Bid Adjudication Schedule in Section 8 of this file.

As such, whilst cost is extremely important, the lowest cost offer will not necessarily be successful.

Client reserve the right to terminate the process at conclusion of stage 1, 2 or 3.

If proposals do not comply with the terms of this RFP, such proposal may not be considered and may be disqualified.

Should you need to know more about Client please visit our website at

2.     Project Governance and Roles

The approach to Project Governance has been developed in order to maximize Client engagement and ownership of the solution while at the same time creating a framework that allows the successful bidder to manage deliverables and risk against a fixed price.

Bidders are invited to submit suggestions for improvement.

The overall project governance and management structure is discussed below:

2.1  Overview of governance

The governance proposed comprises the following major components:

2.1.1  Client Executive Sponsor – Client CEO:

The ultimate customer and customer authority -- Client CEO Client CEO;

2.1.2  Client Internal Systems Executive – Client Executive

Xxx is the General Manager of Sister Company, sister company to Client and is responsible for the in-house software systems and also the xxx devices.  Close collaboration will be required with regard to sharing data between the Financial Suite and the operational software;

2.1.2   Client Business Team Leader– Client CFO:

The owner of the detailed business requirement and responsible for the business team, reports directly to the Client Executive Sponsor.  Ensures that the business requirement is accurately documented and fully satisfied, ensures that the most appropriate personnel form part of the business team and that they participate to the extent necessary – Client CFO Client CFO;

2.1.2   Client Contract Manager –  Client Manager Xxx:

Handles contract management together with Client legal affairs manager and coordinates and directs the Client team and their input –  Client Manager Xxx;

2.1.3   Client Project Facilitator – Dr James Robertson PrEng:

Reports directly to executive sponsor and translates and shapes overall requirement and direction in close consultation with Contract Manager.  Facilitates input from and coordination between all high level parties as agent of and advisor to Client --  Dr James Robertson PrEng;

2.1.4   Implementer Executive Sponsor:

Heads up the Implementer team with mandate from the Prime Contractor team and their respective organizations to direct the project at a high level.  Preferably a director of the Prime Contractor.  Interacts closely with the Client Executive Sponsor and Client Project Facilitator and other members of the Project Management Team;

2.1.5   Prime Software Vendor Executive Sponsor:

(if different from the Implementer Executive Sponsor). Represents interests of the Prime Software Vendor at monthly meetings and other foru.  Assisted by the Vendor staff member who was involved in the sale.  Preferably one and the same person;

2.1.6  Implementer Team Leader:

Runs the project for the Prime Contractor on a day to day basis reporting directly to the Implementer Executive Sponsor and manages the Implementer Team.  This is NOT a classic IT Project Manager role it is a leader, that is giving direction and exercising initiative, role;

2.1.7  Implementer Strategic Solution Architect:

This is an extremely experienced solution Architect who demonstrates a robust intuitive understanding of the Client business and business generally and who guides the Implementer Project Team in ter of technical content with regard to configuration, data and all related subjects.  This person is of comparable seniority to the Implementer Team Leader or may  be more senior but has NO line authority.  This person reports directly to the Implementer Executive Sponsor and NOT the Implementer Team Leader / Project Manager.  The Implementer Strategic Solution Architect will work closely with the Client Project Facilitator in crafting a precision solution for Client.  The Implementer Strategic Solution Architect is expected to facilitate all major design workshops in consultation with the Client Project Facilitator and to conceptualize and manage the integration of the entire solution;

2.1.8   Business Advisory Team:

Client subject matter experts encompassing all functional areas to be supported by the system.  Ensure business and technical requirements are comprehensively documented and functionally correct and accurately implemented;

2.1.10  Implementer Finance Suite Team Leader:

This is an Implementation Consultant with considerable knowledge and experience of the application of the ERP and Finance Modules of the Core Software.  May be the overall team leader in this case;


2.2 Detailed specification of roles

These roles are discussed in more detail below:

2.2.1   CEO as Executive Sponsor – Client CEO

The role of the Executive Sponsor is as follows: Ultimate business and contract executive accountability for the project Contract management through Contract Manager so that Executive Sponsor role is kept as limited as possible Advised and guided by Project Facilitator as trusted advisor Custodian of the integrated business view of the solution Does NOT require technical knowledge – owns the question “does this ACCURATELY represent the business?” High level directional decisions only Supported by Business Advisory Team with regard to detail


2.2.2   Contract Manager – Client Manager Xxx Direct accountability to Executive Sponsor; Day to day management of Implementer advised by Facilitator; Day to day line responsibility for routine matters relating to non-executive members of the Client project team; Peer to peer liaison with other Client managers; Day to day contract management and contract administration with Project Facilitator (external advisor); Works closely with Project Facilitator in putting the project together, running the procurement and running the project – this is the business manager most intimately involved with the day to day running of the project.


2.2.3   Project Facilitator – Dr James Robertson PrEng Highly experienced Business System specialist – “Business System Engineer”; Trusted advisor to the Executive Sponsor and the business; NOT an executive position (facilitator); Operates through peer influence with Client managers in Business Team; Tough quality management of contractor as agent of sponsor in partnership with the Contract Manager; Authority by proxy; Translator between the Business and the Implementation Contractor; Consolidated, integrated view of the business and required solution; Intuitive strategic insight into the business; Knows what works and what does not – mature OWN experience; Independent thought leader – retains this relationship throughout; Guides overall project communication; Close liaison with Implementer Executive Sponsor.


2.2.4  Implementer Executive Sponsor Director of the Implementation Contractor with Executive Mandate to run the project on behalf of the Integrated Implementation Team. Reports directly to Client Executive Sponsor, highest point of relationship management between client and Implementation Team. Operates on a peer level with Client Project Facilitator. Gives direction to Implementer Project Manager. Deep and mature experience of implementing the Financial Suite of choice – knows the product well. Strategic thinker who understands the essence of Client business and how to support it to thrive. Results orientated, gets things done, quick and effective decisions. Able and willing to mobilize specialists from their organization as required.


2.2.5   Software Vendor Executive

Attend monthly Project Board meetings to hold Implementer accountable from the Software Vendors perspective.


2.2.6   Project Board

The project Board comprises the Executive Sponsor, Business Team Leader, Contract Manager, Project Facilitator and Implementer Project Director, Implementer Team Leader and such other personnel as may be identified during detailed project design.

The role of the Project Board is to provide overarching integrated governance, assurance to Client Board and shareholder as well as coordinated liaison across the entire project.

The Project Board will meet monthly to discuss all executive level issues that require attention, resolution or direction.


2.2.7   Business Advisory Team Managers representing each and every significant business area impacted by the project, both support and operations; Supported by other staff for day to day activities; Collectively represent the entire business; Ensure overall direction and decisions ACCURATELY fit the business; Ensure that all key role players within the business engage fully; Advise the Executive Sponsor on overall direction and policy with regard to the project and associated business change; Ensure that both legs of every integration component work effectively; Advise the Project Facilitator and Implementer Project Manager with regard to ensuring full business complexity is accurately taken into account; Appoint, manage and take responsibility for those individual members of the Business who represent their areas of responsibility; Underpin and support Executive Sponsor’s mandate and thereby Contract Manager and Project Facilitator mandates.


2.2.8   Implementer Team Leader Day to day Project Management and running of the project. Reports directly to Implementer Project Director. Highly experienced with implementation of chosen system. Significant Transport industry experience a major recommendation. Oversees all project administration, project schedule, budget, workshop coordination and all other project management and administration tasks. Oversees all project specialists and responsible for all day to day project staffing issues. This is a leadership role NOT an administrative role, administrative tasks may be delegated.


2.3     Reporting and Monitoring on the Project

Reporting and monitoring will take place as follows:

2.3.1 Weekly Project Meeting for coordination of progress and to address issues relating to day to day project progress;

2.3.2 Monthly Project Board meeting at which formal progress will be reported in terms of work packages scheduled for completion versus actual completion and all associated issues will be addressed;

2.3.3  Quarterly Project Board meeting to assess overall status;

2.3.4 Joint Business Team meeting monthly for the purpose of overall solution design coordination;

2.3.5 Detailed Project Specialist and other meetings as required.


3.  Critical Implementer Selection Criteria

The buying decision will be a composite of the most suitable software AND a high level of certainty that the implementer team is able to deliver a high quality outcome and can be held contractually liable for damages that result to the business in the event of a failed or sub-optimal implementation.

The following Critical Success Factors will be applied in selecting the implementer:

3.1 Strategic understanding of, and insight into, the business – including what makes it thrive

Understand our business and where we are going to take the business.  Demonstrate an intuitive feel.  Communicate this in the opening sections of the submission, during the site visit and in the presentation;


3.2 Maturity and executive custody

Mature and experienced project team leadership (sponsor, team leader and other key team members).  Contractually named and committed senior team members approved by Client who remain on the Project for the full duration of the Contract and cannot be removed by the implementer.  These team members must provide thought leadership and be able to interface effectively with Client executives. 

The account executive who markets the contract should remain on the project team and remain accountable for his undertakings for the duration of the contract.


3.3 Industry Track Record

Track record with comparable client businesses.  Demonstrated commitment to working in partnership.  Size of backup and support.  Implementation experience over a variety of relevant organizations.


3.4 Implementer track record in Xxx

Experience of implementations in Xxx would be a recommendation;


3.5 Legally accountable

Software company and Implementer accept accountability for their actions and advice including go-live certification. 

Willing to sign a robust legal contract which addresses all points in the bid documentation and other points that may be identified during negotiations after the contract is awarded.

Submission of a price proposal will be taken as signifying willingness to comply with these terms


3.6 Fit for purpose

The software company and implementation partner must certify in writing that the software is fit for purpose and will work effectively for all divisions of Client.


3.7 Team members to be contracted

The following key team members are to attend the formal short list (stage 2) bid presentations.  CV’s are to be provided and Client may interview each person privately in order to satisfy themselves that the candidate is suitable.

Once accepted a team member may not be removed from the project by the Implementer except in extreme circumstances such as death, serious long term illness or serious long term injury.

Team members to be contracted are:

3.7.1 Implementer Project Executive Sponsor;

3.7.2 Implementer Strategic Solution Architect;

3.7.3 Implementer Team Leader;

3.7.4 Implementer Financial Suite team leader;

3.7.5 One person may fill more than one of these roles provided they are suitably qualified.


3.8 Software vendor liability

The software vendor is liable for business damage or disruption that results in quantifiable financial loss consequent on software defects.  Guaranteed turnaround time for rectification of mission critical defects that impair business operation.

Guaranteed turnaround for rectification of defects that impair business operation.


3.9 Implementation partner liability

The implementation partner is liable for business damage or disruption that results in quantifiable financial loss that is NOT consequent on negligence by Client personnel or on project policy decisions taken by Client personnel that go against a written dissenting opinion tabled by the implementer.

A certificate from the insurer confirming that the Prime Contractor carries Professional Indemnity Insurance at a level commensurate with the scale of the offer price and magnitude of possible damages.

Force majeure is excluded from liability.


3.10 Right to maintain and repair

The software company and implementation partner will be required to contractually recognize the right of Client to maintain and repair the software installation in perpetuity subject to commercially valid (market related) license fees being paid.

This includes but is not limited to:

3.10.1 Right to decline an upgrade and receive open ended support on the current version at reasonable rates;

3.10.2 Right to a copy of the source code and development environment if such support is declined;

3.10.3 Right to the source code if support is withdrawn for any reason other than breach by Client or force majeure;

3.10.4 Six months to reinstate support after force majeure failing which support will be deemed to have been withdrawn permanently;

3.10.5 Other measures necessary to ensure that Client are able to use the software forever if required.


3.11 Implementer Go-Live Certificate

Implementer to certify in writing that the installation is ready to run live and accept liability for damages if live operation is unstable or unreliable at a level that causes business damage as a consequence of acts or omissions on the part of the Implementer team.


3.12 Software Vendor Go-Live Certificate

Software company to certify in writing that the installation is ready to run live and accept liability for damages if software is unstable or unreliable at a level that causes business damage when in production – this clause applies even after go-live.


3.13 Deliver on deadlines and budget

Bidder must evidence a history of projects where deadlines and budgets have been consistently met – document with contactable references;


3.14 Methodology

Proven implementation methodology customized to the specifics of this client and project;


3.15 Willingness to comply with Laboratory requirements

Willing to run laboratory to our specification and timeline – refer Section 4 of this document and the Bill of Services.

Do not run live until the entire configuration has been fully tested in the Laboratory and signed off by relevant parties, refer specification below and details in the Bill of Services.

4  Business Systems Laboratory

Refer to separate document.


5  Procurement process

The procurement process to be followed is set out below:


The overall procurement approach will comprise a three stage process directed at converging on a well-considered binding fixed price for the entire configuration, customization and commissioning of the final selection of systems (Financial Suite, Data Warehouse and associated specialist modules) for Client.

This process is outlined below – dates are set out in the schedule at the end of this section and in the Procurement Schedule:

Stage 1:

Issue of a Request for Proposal and associated documents to identified core software vendors and other invited parties.

The issue of the documentation will take place at a formal briefing on the 8th of May 2014. (James please confirm, as this was adjusted this morning) The vendors will take the documents for review and comment by prospective implementation partners.

Vendors will be required to indicate the Implementation Partner/s (Prime Contractor) of choice and their commitment to bid on the final RFP by 17h00 on the 5th of May 2014

This stage will take bidders through a structured process to enable them to understand the nature and scale of Client’s business together with the headline requirements directed at enabling each bid team to make a formal submission to Client accompanied by a formal written proposal containing a fixed price offer.

Bidders may submit requests for further information or clarification, such requests must be made in writing by email and replies may be copied to all short list bidders.

Offers are to be submitted by not later than the 22nd of May 2014 at Client Offices.  First round offer is for an all-inclusive price with a tolerance of 30%.  In other words, the final fixed price may NOT exceed the initial offer by more than 30%.  This is to discourage under-quoting in the first round.

Review and adjudication of received submissions is expected to reduce the list of bidders to be taken forward to Stage 2 to a short list of around three bidders.  Adjudication is scheduled to be complete by Close of Business on the 30th of May 2014.  Client reserves the right to contact any bidder during this period for clarification of the offer;


Stage 2:

The short list bid tea will each be required to arrange a visit to a reference site during the period from the 5th to the 13th of June.

Bidders will be given a four hour private session with the Client team so that both sides can clarify any issues that require attention.  These sessions will take place from the 5th to the 13th of June.

The short list bidders will each be allocated a three hour session at which they will formally present their offers revised to take account of the abovementioned sessions.  These offers are to be to a tolerance of 15%.  While preparing their presentations they may seek clarification or amplification from Client.

These sessions will include walkthroughs and presentations of their software offerings.  This presentation will be to the Client evaluation team;

On the basis of the above representations and submissions Client will identify a single preferred bidder to proceed to Stage 3 not later than close of business on the 27th of June 2014;

Client reserves the right to revisit this selection should unforeseen obstacles be encountered with the selected bidder in Stage 3;


Stage 3:

The final stage of the procurement process will grant the successful bidder a month to undertake full discovery, analysis and documentation of the Client business requirement in order to arrive at a fixed contract price for the balance of the project.  This work will take place against a fixed fee stipulated in the original and revised offers and subject to the same tolerances as the overall price.  During this period the project schedule will be fully developed and agreed and the contract and all other related matters will be finalized by close of business on -the 31st of July 2014.

Work is scheduled to commence on 04th of August 2014 subject to Board approval.


6  Headline Requirements and Reference Documents

The headline requirements are contained in Section 3 of the tender files.

The reference documentation is contained in Sections 11 onwards of the tender files.


7  Conclusion

A robust procurement process geared towards achieving a robust and cost efficient solution that will serve Client for at least the next twenty years has been set out.

Client are seeking a long term partnership with a Vendor – Implementer combination that is a close strategic and cultural fit and capable of sustaining a highly successful long term business partnership.

We look forward to receiving your offers


Client CEO

Chief Executive -- Client

Download 01 Request for Proposal for Business Systems Solution in Microsoft Word docx format

02 Laboratory Approach to be Applied

The Business Simulation Laboratory is a fundamental component of a successful project.  This document specifies the manner in which the laboratory will be run
It is vital to test the software and the configuration thoroughly in the laboratory with the express purpose of breaking the software and the configuration by testing situations that cause the software either to fail or to fail to return the correct result
One the software and configuration have been adjusted to the point where it is NO longer possible to cause failure then the configuration can be used as a platform for configuring workflow, developing and testing reports and business intelligence models, developing policies and standards, developing training manuals and interactive training material and training staff
The project should ONLY go live once all the above had been successfully completed and ALL staff are trained up in the laboratory
At this stage the Certificate authorizing deployment should be signed by all parties.  As you will see further down the page this is a fairly onerous certificate and should ONLY be signed if ALL parties are FULLY satisfied the software and configuration is fully stable and all elements that are necessary for a successful deployment are in place


Draft for Discussion


Specification of Laboratory Approach

Relating to an Integrated Financial Solution


A Financial Suite and Data Warehouse,


Data Sharing, Implementation and

Project Management Services

Table of Contents

1.  Laboratory Definitions. 

1.1.  Laboratory. 

1.2.  Engineering.

1.3.  Prototype.

1.4.  Implementation.

1.5.  Test.

1.6.  Walkthrough.

1.7.  Software Walkthrough.

1.8.  Configuration Walkthrough.

2. Laboratory Principles.

2.1.  Prototyping environment.

2.2.  Representative data.

2.3.  Fully equipped.

2.4.  Life of project.

2.5.  Accurately model the real world.

2.6.  Break it till it breaks no more.

2.7.  Business Intelligence Development.

2.8.  Standards, Policies and Procedures.

2.9.  Computer Based Training Material 

2.10. Basis of go-live certificate.

2.11. Basis of live instance.

2.12. Goal of the Laboratory.

2.13. Bill of Services.

3. Laboratory Specification.

4. Laboratory Stages.

5.  Laboratory Completion – Certificate of Readiness to Commence Live Operation

6.  Ongoing Laboratory Operation

Specification of the Business Simulation Laboratory

This document sets out the Laboratory approach that is to be applied.

The Laboratory approach that is set out in this document has been developed by James Robertson over several decades and is geared to minimizing commissioning risk and maximizing reliability in the final commissioned Business Information Systems solution.

1.   Laboratory Definitions

The following terms are applied:

1.1.   Laboratory

A laboratory is a facility that provides controlled conditions in which scientific research, experiments, and measurement may be performed. (Wikipedia)

In the context of this document a System Configuration Laboratory is a room equipped with computers, visual aids, etc in which the configuration of a system is developed, refined and tested until it is stable and suitable for commissioning.  The Laboratory is also used to develop and test reports, training material, etc.  The goal of the Laboratory is that when the Laboratory work is completed the system is ready for deployment with a high certainty of a robust, reliable and sustainable outcome.

1.2.   Engineering

Engineering is the discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge, in order to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of people.

The American Engineers' Council for Professional Development has defined "engineering" as “The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.” (Wikipedia)

1.3.   Prototype

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from. (Wikipedia)

A prototype is a carefully and professionally constructed test sample of a system that in final form is intended to be put into economic operation by the developers (Robertson)

In the context of this document the entire configuration of all systems will be developed in Prototype form in the Laboratory until it reaches a point where it can be deployed in the business with a high level of certainty of a reliable and sustainable outcome.

1.4.   Implementation

Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy. (Wikipedia)

In the context of this document the Laboratory is a central component of the Implementation of the designated systems in the business.  The main characteristic of a Laboratory based implementation is that every aspect of the configuration is comprehensively tested in the Laboratory such that the deployment of the software in the business is a Commissioning rather than an implementation with the bulk of the Implementation undertaken in the Laboratory.

1.5.   Test

A test can be considered as a technical operation that consists of determination of one or more characteristics of a given product, process or service according to a specified procedure. (Wikipedia)

In the Laboratory approach every component of the configuration will be comprehensively tested using statistically representative data such that the configuration is proven to be reliable and dependable.  This is fundamentally different from “User Acceptance Testing” insofar as it requires a much higher level of rigour and reproducibility.  Automated testing software may be used to run repetitive testing cycles.

1.6.   Walkthrough

In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems".

A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed, its lack of a direct focus on training and process improvement, and its omission of process and product measurement. (Wikipedia)

1.7.   Software Walkthrough

In the context of the Laboratory approach a software walkthrough is a systematic step by step practical demonstration of a piece of software directed at ensuring that the people present in the session gain a solid insight into the software and how it works directed at ensuring that the design work that follows is grounded in a solid understanding of how the software “machine” works.

1.8.   Configuration Walkthrough

A configuration walkthrough is a systematic step by step practical demonstration of a piece of software configured to fit a particular element of the business using real data directed at ensuring that the configuration accurately fits the understanding of the people present in the walkthrough with a view to ensuring a tight fit to the business.

2.    Laboratory Principles

The following principles are applicable to the Configuration Engineering Laboratory:


2.1.   Prototyping environment

The laboratory is a rigorous, carefully controlled prototyping and testing environment managed by a very senior and very practical manager who has a clear high level holistic view of how the entire solution fits together and who clearly understands the critical role of the laboratory.  This manager is to be supplied by the Implementer.




2.2.   Representative data

The laboratory is populated with comprehensive, carefully selected representative data – perhaps 0.1% of the data that is in the live system but representative of all possible scenarios.

There are very specific principles to be applied in the selection of this data.  Selection of this data will be guided by the Project Facilitator.

2.3.   Fully equipped

The laboratory is situated in room with sufficient workstations, a server, backup device  (to permit rapid roll-back to previous test states), data projector, flip chart, white board, etc.

2.4.   Life of project

The laboratory is established at the very start of the project and runs until the Data Warehouse and Business Intelligence environment are fully operational and the system has been fully commissioned.

2.5.   Accurately model the real world

All configuration settings are tested in the laboratory until they accurately model the precise desired operation of the business and all required customization and custom development has been comprehensively and rigorously tested and accepted.

Executives and managers must be able to undertake structured facilitated walkthroughs of the laboratory configuration and see their business at all times – if it does not make sense to the executives and / or managers the process stops until the configuration has been modified so that it does make sense to them.

2.6.   Break it till it breaks no more

The primary initial goal of the laboratory is to break the configuration and once it cannot be broken to optimize it, document it, develop training material and computer based training material (CBT) in it, use it as a training environment, use it for the testing of reports and establish the Data Warehouse operating against it.

2.7.   Business Intelligence Development

A full set of management reports, dashboards, etc are to be developed and tested in the laboratory BEFORE production operation commences.

2.8.   Standards, Policies and Procedures

A full set of operational standards, policies and procedures must be developed during the project and embedded in the training given in the laboratory and thereafter.

2.9.   Computer Based Training Material

A full set of Computer Based Training material with regard to standard operating practices for all primary areas of business operation that uses the software must be developed in the laboratory and deployed as part of the final deliverable.

2.10.  Basis of go-live certificate

The configuration does NOT go-live until it has been comprehensively tested in the laboratory and accepted by all senior project team members.

The go-live certificate will be issued at the end of a structured walkthrough of the entire configuration by the entire top management of the project – this walkthrough may take several days and may have to be suspended several times for adjustments.

If the top team are not satisfied with the results of the walkthrough, further walkthroughs will be held until all members of the top team are willing to accept the configuration.

2.11.  Basis of live instance

The laboratory configuration forms the basis of the live instance of the software – the entire configuration is to be copied onto the production server and all transaction data files cleared and all counters reset.

The final empty configuration will be reviewed and tested during a trial run of the start-up process in the Laboratory.

2.12.  Goal of the Laboratory

The goal of the Laboratory is to ensure that the final live installation is an excellent fit to the business, that all staff are properly trained at go-live, that there are no surprises and that there is minimal well managed risk to the business on go-live.

2.13.  Bill of Services

More details of the Laboratory are set out in the Bill of Services.

3.    Laboratory Specification

The Laboratory is a well-equipped room with a full installation of all software components in which all aspects of the installation can be effectively tested.

The set-up of the Laboratory must be designed in such a way that all realistic scenarios and operational conditions can be simulated.  This may require additional workstations and child Laboratory installations at remote sites in order to fully test the performance of communication, etc at practical levels.

It is important that the workstations, server/s, network operate at peak efficiency so that testing can proceed quickly.  Testing relating to workstation, network and server performance must take place as a distinctly separate activity, maximum performance in the Laboratory is vital in order to ensure that testing proceeds as efficiently as possible and takes as little time of business and contractor personnel.

The room must be sufficiently large for an audience to be able to attend walkthroughs and there must be a data projector so that groups of people can participate in walkthroughs.

Other presentation aids such as flip charts and white boards must also be provided.

4.    Laboratory Stages

The following Laboratory Stages are to be followed – see also the Bill of Services:


Establishment of Laboratory


Detailed planning of integrated laboratory simulation programme

-- goal of the laboratory is to BREAK IT until IT cannot be broken


Specify laboratory facility


Procure equipment and establish laboratory facility


Collate and consolidate detailed statistically significant test packs for each

 module into one integrated test pack


Testing of individual modules


Commission and test individual modules in the laboratory as they become



Test Integration


Test integration of modules as they become available


Testing and acceptance of the integrated solution


Technical integration


Technical testing of integrated solution until the entire solution works technically

 -- 3 iterations


Other activities necessary to get the integrated solution to a point where it can be

 utilized by the business team -- 3 iterations


Business operational integration


Operational testing of the integrated solution until the entire solution works at a

 business operational level -- 3 iterations


Other activities necessary to get the integrated solution to a point where it can be

 presented to executives -- 3 iterations


Simulation and review of the integrated solution -- first iteration


Comprehensive simulation of live operation with a small but statistically significant

 test data pack


Systematic presentation and walkthrough of entire solution with executives


Other activities relative to first iteration


Simulation and review of integrated solution -- second iteration


Revise, refine and optimize solution


Comprehensive simulation of live operation with small but statistically significant

 test data pack until ready to present to execs


Systematic presentation and walkthrough of entire solution with executives


Other activities relative to second iteration


Simulation and review of integrated solution -- third iteration


Revise, refine and optimize solution


Comprehensive simulation of live operation with small but statistically significant

 test data pack until ready to present to execs


Systematic presentation and walkthrough of entire solution with executives


Other activities relative to third iteration


Development and testing of integrated reports and BI models, etc


Development of integrated reports -- 3 iterations with Executive review


Development of integrated BI reports, models and dashboards -- 3 iterations

 with executive review


Development of executive level strategic BI reports, models and dashboards

 -- 3 iterations with executive review


Specification, configuration, testing, refinement and documentation of integrated

 workflows / operating procedures -- 3 iterations


Specify and configure workflows -- iteration 1


Define workflows from executive level and document


Review and refine with management


Review and refine with operational personnel


Configure in the system




Specify and configure workflows -- iteration 2


Define workflows from executive level and document


Review and refine with management


Review and refine with operational personnel


Configure in the system




Specify and configure workflows -- iteration 3


Define workflows from executive level and document


Review and refine with management


Review and refine with operational personnel


Configure in the system




Finalize and accept workflows


Management review


Executive review




Development of training materials


Documentation of policies and standards -- 3 iterations


Development of user manuals -- 3 iterations


Development of Computer Based Training material with tests and performance

 measures with executive review -- 3 iterations


Other activities necessary to develop a comprehensive training environment for

 the enterprise




Training of Operational Personnel


Overall system operation, integration impacts -- who is affected by what I do

 -- how the whole system fits together


Policies, standards, protocols, escalation, authorities, etc

 -- includes speed and accuracy of data capture for all personnel with significant

 keyboard input requirements


Touch typing test for all personnel responsible for significant keyboard input

 -- touch typing classes for those who do not achieve a minimum standard of 20

 words per minute at 99% accuracy

 -- team must include an instructor


Training on CBT until reach required standard -- multiple repetitive cycles


Comprehensive operational simulation until all staff are trained to a level where they can

 migrate to new system easily -- at least 3 iterations


Other training related activities for operational personnel


Declaration of operational readiness


Training of supervisory personnel


Overall system operation, integration impacts -- who is affected by what I do

 -- how the whole system fits together


Policies, standards, protocols, escalation, authorities, etc

 -- includes speed and accuracy of data capture for all personnel with significant

 keyboard input requirements where applicable


Touch typing test for all personnel responsible for significant keyboard input

 -- touch typing classes for those who do not achieve a minimum standard of 20

 words per minute at 99% accuracy


Training on CBT until reach required standard where applicable -- multiple repetitive



Comprehensive training in conjunction with operational simulation until all supervisory

 staff are trained to a level where they can migrate to the new system easily

 -- at least 3 iterations


Other training related activities for supervisory personnel


Declaration of supervisory readiness


Training of Managers


Overall system operation, integration impacts -- who is affected by what I do

 -- how the whole system fits together


Policies, standards, protocols, escalation, authorities, etc

 -- includes speed and accuracy of data capture for all personnel with significant

 keyboard input requirements where applicable


Touch typing test for all personnel responsible for significant keyboard input

 -- touch typing classes for those who do not achieve a minimum standard of 20 words

 per minute at 99% accuracy


Comprehensive training in conjunction with operational simulation until all managers

 are trained to a level where they can migrate to the new system easily

-- at least 3 iterations


Other training related activities for managers


Declaration of management readiness


Training of Executives


Overall system operation, integration impacts -- who is affected by what others do

 -- how the whole system fits together


Policies, standards, protocols, escalation, authorities, etc


Comprehensive training in conjunction with operational simulation until all executives

 are trained to a level where they can migrate to the new system easily

-- at least 3 iterations


Other training related activities for executives


Declaration of executive readiness


Formal declaration of readiness to commence live operation -- issue certificate

 of readiness


Declaration by each Implementer Team Leader


Declaration by each Business Team Leader


Declaration by Implementer Project Leader


Declaration by Implementer Project Director


Declarations by Client Heads of Departments


Declaration by Client Project Facilitator


Declaration by Client Contract Manager


Declarations by Client Divisional Heads


Declaration by Client Executive Sponsor


Approval by EXCO


Shareholder approval

5.  Laboratory Completion – Certificate of Readiness to Commence Live Operation

As noted above the final stage of any aspect of Laboratory operation is the issue of a Certificate of Readiness to Commence Live Operation.

This certificate must be progressively signed by all team members and includes a clear statement that the persons signing the Certificate are fully satisfied that the system is ready to be deployed in the business.

The goal of this certificate is to create a context in which no-one will sign the certificate until they are fully satisfied that the configuration is ready to be commissioned.

6.  Ongoing Laboratory Operation

Once the entire system is operational throughout the entire business the laboratory as a dedicated facility may be closed down.

Download 02 Laboratory Approach to be Applied in Microsoft Word docx format

03 Business Information System Requirements Definition

The Business Requirements Specification is a strategically focused document, that is it lifts out the essence of the business and how it thrives in a structured and weighted manner so that there is NO uncertainty on the part of the bidders as to the exact nature of the business
The strategic essence must lift out the fundamentals of the busines and particularly what is unusual, the elements that deliver competitive advantage and which are therefore the most vulnerable to inappropriate action
This is NOT the place for generic industry definitions or for long lists of standard software functionality -- development of the requirements specification requires a mature and highly experienced consultant with a solid understanding of strategic essence AND a solid understanding of systems and how systems integrate with the business to deliver high value outcomes

Requirement Specification

Relating to an

Integrated Financial Solution


A Financial Suite and Data Warehouse,


Data Sharing, Implementation and

Project Management Services

Release 1





Client is a privately owned, Xxx based Xxx Company.

Client’s Head Office is in Xxx and the installation will be hosted there.

Client have a number of branches and franchises around Xxx as well as internationally.  While the solution must be capable of being deployed in these offices as required this tender is ONLY for deployment in Xxx.

The current financial suite is based on Pastel Partner coupled to an existing in-house developed operational software suite which will be retained.  The financial components of the solution are in large measure manual and based on Excel and will not support the business to achieve its strategic growth objectives.  It has therefore been decided to procure a comprehensive suite of financial business information systems including General Ledger, Debtors, Creditors, Fixed Assets, Cash Book and Inventory.  A Data Warehouse is also required.  These systems will share data to the extent necessary with the existing operational systems developed by Client.

This Request for Proposal is being issued with a view to appointing a single prime contractor on a fixed price basis to supply all required system components and integrate these with one another and with the systems that are already in use within the company.

This document constitutes the Requirements Definition for this assembly of systems.

Critical Consideration – Trusted Professional Advisors

In interpreting this document and the RFP it is vital to understand that Client are seeking to appoint a single firm as trusted professional advisor for the entire project.  This firm will be held fully accountable for delivering the required outcome on a fixed price, fixed outcome basis.

The Strategic Advisor to the CEO, Dr James Robertson, who has drafted these documents will provide quality assurance and contractual review advisory services to Client CEO but is NOT responsible for the outcome.

Bidders must fully satisfy themselves that they fully understand the requirement and are required to undertake comprehensive requirement definition workshops as part of the deliverable.

This document headlines the requirement at a strategic level in order to ensure that bidders understand the high level scope of work and therefore forms the conceptual foundation for the detailed design.

Client CEO

Chief Executive

Section 1
Strategic Business Systems Definition
The Essence of the Client Business Systems Requirement

The following points describe the headline elements that constitute the essence of the Client business requirement.  These are the points which if overlooked or compromised in the design and implementation of the solution will DAMAGE the business and the factors which if ACCURATELY accommodated will support the business in its strategic (growth) goals.

Percentages at the end of headings indicate the relative importance of these factors in achieving the project goals.  ALL components are required in order to achieve a viable business solution:

1.1  Business is growing rapidly -- Highly competitive business – xx%

Client is growing rapidly and systems are required to support that growth.  Client operates in an environment competing with 4 other major xxx companies.  The efficiency and effectiveness of its business systems is therefore of paramount importance.

1.2  Own complex system includes invoicing, installation xxx, commission payments, etc – xx%

Client sister company Client Sister Company has developed a suite of software for Client that takes account of customer billing, installation xxx, commission and royalty payments, etc.

The new financial suite must be able to share data with these systems using simple data interchange formats such as XML, CSV or similar.

1.3  Throughout Xxx, Xxx, the World – xx%

Client operates throughout Xxx with both branches and franchises.  The system must be capable of being deployed affordably in both of these types of branch in time. Truck utilization – 16%

Client operates in the following countries in Xxx and expansion is expected.  Some of these branches are wholly owned and others are franchises.  The system chosen must be capable of being deployed in these countries as required on an affordable basis.

Client currently operates in … in the rest of the world, in some cases as wholly owned subsidiaries and in other cases as franchises.  The system selected must be capable of being affordably deployed in these locations on an as required basis.

1.4  High volume low value debtors transactions and credit control is a critical requirement – xx%

The nature of Clients business is that customers are billed monthly, individual invoice amounts are relatively small, there are a large number of customers and missed payments and defaults are significant.

The solution that is adopted must be geared to managing this sort of debtor environment including xxx accounts that have been handed over for collection.

1.5  Xxx device inventory management – xx%

Xxx devices represent a substantial stock holding with items being moved from location to location and country to country on a daily basis.  An inventory solution that can handle this effectively is required.  The existing in-house systems track inventory during the installation process and will continue to do this.  The inventory management solution is required to manage inventory up to the point at which it is handed over for installation.

1.6  Debit order processing – xx%

Client obtain most payments by debit order.  The system is required to provide comprehensive facilities for managing debit orders based on a payment instruction that will be generated in the existing systems.

1.7   Single Prime Contractor – Integrator / Implementer -- fully accountable – xx%

A fundamental business requirement is to outsource as much risk as possible for the system procurement and implementation on a fixed price basis.

We are looking for a service provider who can guarantee a successful outcome in terms of the final integrated business technology solution.

It is anticipated that the final solution will comprise a portfolio of software elements which must all be integrated at the DATA level to accomplish seamless single point of entry operation.

  1.8 Precision Configuration that models the real world

In developing the solution the entire solution must be configured with a high level of precision that accurately models the real world.  This requirement informs ALL the above items.

Implementers must evidence that they have particular expertise in this area, particularly with regard to developing an enterprise Chart of Accounts that will support global consolidation in the Data Warehouse and is coupled to a robust management model.

Section 2
Headline Business Requirement

The following components define the headlines of the business requirement and will form the basis of adjudication

Percentages at the end of headings indicate the relative importance of these factors in achieving the project goals.  ALL components are required in order to achieve a viable business solution:

1.1  Data sharing -- ability to integrate effectively with current systems    

The current in-house developed systems are very comprehensive with regard to the core operations of the business and the new financial suite is required to share data with these systems on an agreed basis.

It has been agreed that this sharing of data will take place using simple and reliable methods such as the transfer of data files in, for example, XML or CSV format on a regular scheduled basis.  The exact break point between the in-house system and the new financial suite will be established on the basis of what is technically optimum.  The following items must be addressed in the offer.

1.1.1 Low technology data file transfer in -- XML, CSV or similar

1.1.2 Low technology data file transfer OUT -- XML, CSV or similar

1.1.3 Track Record -- references -- software

1.1.4 Track Record -- references -- implementer                                               


1.2   Finance functionality                          

There are a number of aspects of financial suite functionality that are critical to this project, these are listed below:

1.2.1  Robust enterprise Chart of Accounts that supports global consolidation

It is vital that the bidders evidence experience and thought leadership with regard to the development of an enterprise Chart of Accounts that will accommodate the full complexity of the Client operation globally

1.2.2 Moderately high volume of low value invoices from in-house developed systems

The existing in-house developed systems will generate the invoices as at present but these must be handed over to the Debtors module for Debtor account management and debit order processing                  

          1.2.3 Very flexible debit order processing       

This will include the processing of debit orders.  The in-house system will raise the charges but the processing of debit orders must be managed by a module to be supplied as part of the financial suite solution.  It is envisaged that this will probably take the form of a third party add-on module for the financial suite

1.2.4 Credit Control including debtors dialer and synchronization of screens with in-house  system 

Because of the debit order based billing and the nature of the business default on debit orders is a frequent occurrence.  There is a need for a debtors dialer function that will assist with the follow-up of overdue amounts, lead operators through a prioritized list of calls and associate management screens in the Debtors module and the in-house system for credit control purposes through, for example, a common ODBC link.

            1.2.5 Manage accounts handed over for collection

The number of accounts handed over for collection at any time is considerable.  There is a requirement for a component, probably an add-on module, that will synch with the collection agency so that Client have visibility of the state of collections

            1.2.6 Bank reconciliation

Because of the very large number of small payments there is a requirement for an automated bank reconciliation – ties in to the requirement for debit order processing

            1.2.7 Standard Finance Functionality

The following are routine finance suite applications; the requirement here is for comprehensive functionality that supports the way that Client does business.  It is assumed that all mainstream financial suites will meet this requirement.  Vendors are requested to highlight what they consider to be particular strengths of their offering insofar as these relate to Client

               General Ledger



               Cash Book Inventory                                 

               Fixed Assets

          1.3   Data warehouse and business intelligence capability

Given the reliance that exists on the in-house developed suite of software a fully-fledged Data Warehouse is regarded as essential.  This should comprise services and products relating to extract, transform and load as well as with regard to reporting and modelling (”business intelligence”).  The reference document pack includes examples of the basic reports that are required.  Provision must be made for more comprehensive and sophisticated models and reports.

Fully pre-mapped onto the financial suite

    Easily mapped onto the existing Client databases

            Easy to use

            Track Record -- references -- software

    Track Record -- references -- implementer

1.4   Compliance with overall tender requirements and project approach

Bids will also be adjudicated in terms of the following criteria:

            Have accepted terms of the bid as presented in the RFP, etc

            Proven track record


            Team offered


1.5  Satisfies other requirements                            

            Under our control -- do it ourselves, host ourselves

It is the culture of Client to do as much as possible themselves, the offer must recognize this and support this culture

            Standard Financial Suite should suffice                      

The following are routine financial suite applications, the requirement here is for comprehensive functionality that supports the way that Client does business.  It is assumed that all mainstream financial suites will meet this requirement.  Vendors are requested to highlight what they consider to be particular strengths of their offering insofar as these relate to Client

                        General Ledger



                        Cash Book


                        Fixed Assets

             Suitable for a business the size and complexity of Client  


1.6  Global consolidation when required in the future -- in Data Warehouse

It must be possible to consolidate financial and other performance data in the Data Warehouse solution

            Different countries

            Different currencies

            Track Record -- references -- software

            Track Record -- references -- implementer

1.7  Global operation when required in the future 

Must be able to be deployed in other countries on an “as required” basis with the understanding that in some countries, such as those with xxx based tax systems, xxx and others, that systems that are unique to those countries may be used in place of the standard financial suite.  Ability to operate in those countries is a recommendation but NOT a requirement

Global footprint and growth although only deploy Xxxn head office at present                   

          Different countries

          Different currencies

Different tax regimes

          Track Record -- references -- software

          Track Record -- references -- implementer

Business is growing dramatically locally and globally, solution must be able to grow 


1.8  Additional modules offered by vendors (not specific to finance)                              

Vendors are requested to bring our attention to any other relevant modules or add-on components that they are able to offer

1.9  Hardware and network impacts are light and manageable

The solution should NOT place heavy demands on the network and hardware

The above factors are critical in understanding the requirement and specifying the solution.  If the above factors are NOT fully catered for this will constitute a significant deficiency in the overall solution.


The above constitutes the headline requirement.

Bidders are required to assess the suitability of their software, assemble the required portfolio of software and satisfy themselves as to the scope of work in arriving at their bids.

Client CEO

Chief Executive

Download 03 Business Information System Requirements Definition in Microsoft Word docx format

Random Selection of Articles by Dr James Robertson

SNw 058 The Critical Human Foundation

Everything we do with business information systems and is dependent on people.  This articles addresses in some detail a diversity of factors that influence the success or failure of business information system projects
Cnf 091 Business Process -- Over Rated and Over Stated

Discussion of why the current focus on Business Process Mapping is seriously misplaced and is leading to major inefficiencies and negative project outcomes in the business information systems industry -- concludes that "Business Process Obsession is killing ERP"
Web 01 Simple steps to increase the strategic value from your ERP investment

Video discussing simple techniques that can be applied to drastically improve the strategic decision support information yield from your existing Business Information Systems

04 Procurement Timeline and Diary

The procurement timeline is a relatively simple Gantt Chart -- I lay it out in Excel, it is quick and serves the purpose, see the sample attached
The goal of the timeline is to set out the overall timing of the procurement process in sufficient detail that all parties are fully aware of the sequence of events that is planned so that they can schedule accordingly

Item Description  
0 Stage 0  
0.1   Briefing of software companies and issue of tender documents
0.2   Bidders assemble teams  
0.3   Notification to Client of Lead Implementer (Prime Contractor) and team composition
      by NOT later than 16h00  
1 Stage 1  
1.1   Briefing of lead implementers and teams
1.2   Implementers prepare offers - liaise as required
1.3   Clarification for bidders  
      two hour Q&A session to enable bidders to obtain clarification all bidders attend
1.4   Implementers finalize offers
1.5   Implementers submit offers (5 sets) by not later than 17h00 at Client Offices
1.6   Comparative evaluation of offers -- bidders may be contacted for clarification
1.7   Bidders advised of outcome -- short list of not more than four bidders
2 Stage 2  
2.1   Four hour site visits (including travelling time) to reference sites
      Bidders will be advised of time slots, drawn by lot, when advised they are on the short list
2.2   Two hour slots per bidder to sit with Client team
      to obtain clarification in order to bring offer to 5% tolerance
      Easter weekend  
2.3   Bidders prepare for presentations
2.4   Presentations by Short Listed bidders
      4 hours including a walkthrough of their software, team and offer and time for questions
      Second offer may be lower than first offer as greater clarity is obtained but may NOT exceed
        the tolerance of 10% on the initial offer
2.5   Selection of preferred bidder
2.6   Notification of bid outcome by Close of Business
3 Stage 3  
3.1   Finalisation of quote with preferred bidder
        Note that final price may NOT exceed the initial offer by more than 10% 
        and second offer by more than 5%
3.1.1     Further discovery in order to finalize price
3.1.2     Develop detailed project schedule (Gantt chart)
3.1.3     Contractual and commercial negotiations
        James Robertson out of town from 12th to 22nd April
3.2   EXCO review and approval  
3.3   Signing of Contract  
4 Board approval  
5 Commence with system implementation

Download 04 Procurement Timeline and Diary in Microsoft Excel xlsx format

05 Software Schedule

The software schedule is a list of all functional software elements that it is assessed are required.  This is a basis for bidders to add and subtract the modules and products that they have to offer in order to make up the mosaic that constitutes the complete response to the requirement
The software schedule correlates directly with the Bill of Services and the two should be set up to align with one another


    Serial       Item
  1 Finalization of bid -- detailed planning, contracting, etc
  No software expected to be required
  2 Establishment
  No software expected to be required
  3 Project Management and Change Facilitation
  Project Management software to be supplied by 
  4 Data Warehouse and Business Intelligence
  1 Data warehouse database, extract, transform, 
  2 Business Intelligence Software
  Basic Reporting
  Advanced Reporting
  Other Recommended Elements
  Total Data Warehouse and Business Intelligence  
  5 Client Business Management Related Software
  1 Overall Client Business Management Solution
  2 Manage ProductionAsset1 Utilization and Turnaround
  ProductionAsset1 Utilization and Turnaround
  Operations Board
  Interface with xxx
  xxx Monitoring and Reporting
  Total Client Business Specific Modules  
  6 Other Specialist Modules
  1 Software to Manage xxx Operating Costs
  2 xxx control and logging software
  3 Software to manage xxx Center operations
  4 Software to manage Sub-Contractors
  5 Software to manage quoting
  6 CRM -- Microsoft Dynamics
  7 Software for xxx Operations -- ClientSubsidiary
  8 Confirm can handle basic xxx Management
  9 Proof of Delivery Document Management 
  Total Specialist Modules
  7 Finance and Administration Modules
  1 Finance
  1 General Ledger
  2 Accounts Receivable
  3 Accounts Payable
  4 Cashbook
  5 Assets Register
  6 Other Finance
  2 Human Resources
  3 Payroll 
  Total Finance and Administration
  8 Laboratory
  Refer to Laboratory columns in this spreadsheet 
  Computer Based Training software
  Quote for hardware for the laboratory in a separate schedule
  Total Laboratory 
  9 Custom Development
  Expected that development software will be provided
  10 Overall System Integration Requirements
  Any software or other technology required
  11 Operational commissioning and ramp-up
  Any software or other technology required
  12 Operational support
  Any software or other technology required
  13 Contingency
  Any software or other technology required
            Grand Totals

Download 05 Software Schedule in Microsoft Excel xlsx format

06 System Procurement Bill of Services

The Bill of Services is directly comparable to the Bill of Materials on a Construction Project -- it is intended to list ALL the services that are required in order to execute the project and deliver the required business outcome

The Bill of Services is prepared by a person with considerable experience in the implementation of business information systems who is able to draft a comprehensive list.  This list may then be fine tuned by bidders to reflect their particular methods and approach

The Bill of Services is the basis on which the bid is priced and the basis on which the contractor is paid -- if it is NOT in the Bill of Services there is NO basis for a claim

The Bill of Services is priced on the basis of a rates schedule that provides links that MUST be a direct ratio of employee remuneration -- the consulting engineering profession generally has salary based rates formulae that can be borrowed -- it is entirely UNACCEPTABLE that contractors charge average rates over widely differing staff competence grades

It is particularly unacceptable that they under charge for senior personnel and over charge for junior personnel -- this provides a perverse incentive for sub-standard and over priced work


Implementer Schedule of Rates per hour (discounted where full utilization is expected)
All rates are EXCLUDING VAT Rate to be used for bidding in the Bill of Services Name/s of person/s nominated to play this role Rate for Travelling outside of xxx
  Implementation Director
  Project Manager
  Laboratory Manager
  Strategic Solution Architect
  Senior Implementer
  Junior Implementer
  Senior Solution Architect
  Senior Developer
  Documentation Specialist
  Computer Based Training Developer
  Typing Instructor
Other Team Members
  Other 1
  Other 2
  Other 3
  Other 4
  Other 5
  Other 6
  Other n
Vehicle Rate per km outside of xxx

Bill of Services


Columns are days per personnel category as per the rate schedule, extended in the yellow column followed by currency value of hours multiplied by rate in the blue block

    Serial       Item      
2 1 Finalization of bid -- detailed planning, contracting, etc -- phase 3 of bidding process for selected vendor
3 1 Introduction of core team that will run the project -- both sides
4 2 Discovery as required
5 3 Final Definition of Scope in terms of exact modules and products to be procured and implemented
6 4 Develop comprehensive project plan
7 5 Contractual negotiations
8 6 Acceptance and signing of contract
9 7 Other bid finalization activities
12 Total finalization of bid    
15 2 Establishment
16 1 Introduce full project teams
17 2 Move into project office, connect to network and other settling in
18 3 Agree communication, document management and other protocols
19 4 Install and commission Computer Based Training software
20  -- team must included an experienced CBT developer with experience in developing educational material
21 5 Other establishment activities
24 Total establishment    
27 3 Project Management and Change Facilitation
28 1 Project Management and liaison
29 1 Develop detailed project schedule down to +/- 2 week per work package
30  -- at monthly Project Status meetings a work package is either not started, in progress or complete
31  -- the same package is NOT permitted to be in progress for more than one meeting -- red flag to be raised if break this rule
32 2 Quarterly Project Status Review meetings
33 3 Monthly Project Board meetings
34 4 Monthly Project Status meetings
35 5 Weekly Project meetings
36 6 Implementer Project Manager in role
37 7 Other project management activities
40 Total project management and liaison  
42 2 Communication and Change Facilitation
43 1 Liaison and communication
44 2 Develop change facilitation plan
45 3 Communication activites
46 4 Engagement activies
47 5 Problem diagnosis activites
48 6 Other change facilitation activities
51 Total Communication and Change Facilitation
53 Total Project Management and Change Facilitation
56 4 Configuration and Integration of Data Warehouse and Business Intelligence
57 1 Develop overall solution definition
58 1 Executive workshops -- "if we could give you any information you can think of what would you ask for?"
59 2 Operational workshops -- "if we could give you any information you can think of what would you ask for?"
60 3 High level conceptual design and review of practicallity and cost implications
61 4 Agree portion of budget to be reserved for unexpected requirements once system is operational
62 5 Detailed planning of end user Business Intelligence deliverable
63 6 Detailed design of end user Business Intelligence deliverable
64 7 Agree final scope of Data Warehouse and Business Intelligence solution
65 8 Other Data Warehouse and Business Intelligence Solution definition activities
68 Total Develop overall Data Warehouse and Business Intelligence solution definition
70 2 Comprehensive walkthrough of as-delivered tables, ETL, models, dashboards, reports, etc in Data Whouse & BI solution
71 1 High level analysis of requirements to achieve a total solution
72 2 Detailed planning of overall data warehouse configuration and implementation -- including budget related trade-off's
73 3 Other Data Warehouse configuration planning activities
76 Total Comprehensive walkthrough of as-delivered DW and BI
78 3 Develop DW & BI for modules not covered in core datawarehouse
79 1 Familiarization with system and database design
80 2 Design schema's
81 3 Build database
82 4 Specify ETL
83 5 Develop ETL
84 6 Develop basic inquiry and analysis capability
85 1 Specify basic models, reports and dashboards
86 2 Develop basic models, reports and dashboards
87 7 Develop intermediate level inquiry and analysis capability
88 1 Specify intermediate complexity models, reports and dashboards
89 2 Develop intermediate complexity models, reports and dashboards
90 8 Develop advanced level inquiry and analysis capability
91 1 Specify complex models, reports and dashboards
92 2 Develop complex models, reports and dashboards
93 9 Executive adoption
94 10 Other activities relative to the third party module
97 Total warehouse and BI for additional modules
99 Total Data Warehouse and Business Intelligence
102 5 Business Management Related Software
103 1 Overall Business Management Solution
104 1 Liaison and consultation with module specialists
105 2 Comprehensive walkthroughs of the module
106 3 In-depth consultation with Client Business Specialists
107 4 Develop best practice standards for configuration in Client
108 5 Develop Client codes facilitated by JAR
109 6 Laboratory configuration and testing
110 1 Develop workflows, standards, policies and protocols
111 2 Develop comprehensive statistically representative data and situation test pack
112 3 Configure in the Laboratory, test and refine
113 4 Specify, document and test module specific workflows (processes)
114 5 Specify and develop module specific Computer Based Training material
115 6 Final presentation and walkthrough of entire solution
116 7 Adoption of solution
117 8 Other Business Management module configuration and integration related activities
120 Total Overall Business Management Solution
122 2 Manage Client Asset Utilization
123 1 Liaison and consultation with module specialists
124 2 Comprehensive walkthroughs of the module
125 3 In-depth consultation with Client Specialists
126 4 Develop best practice standards for configuration in Client
127 5 Develop Client codes facilitated by JAR
128 6 Laboratory configuration and testing
129 1 Develop workflows, standards, policies and protocols
130 2 Develop comprehensive statistically representative data and situation test pack
131 3 Configure in the Laboratory, test and refine
132 4 Specify, document and test module specific workflows (processes)
133 5 Specify and develop module specific Computer Based Training material
134 6 Final presentation and walkthrough of entire solution with executives 
135 7 Adoption of solution
136 8 Other Client Asset Utilization and Turnaround module configuration and integration related activities
139 Total Client Asset Utilization and Turnaround
160 4 Interface with Client Asset Tracking Systems
177 Total Interface with Client Asset Tracking Systems
179 5 Client Asset Milestone Monitoring and Reporting
196 Total Client Asset Milestone Monitoring and Reporting
220 6 Other Specialist Modules
221 1 Software to Manage Client Asset Operating Costs -- interfacing with third party systems
222 1 Liaison and consultation with module specialists
223 2 Integration must be comprehensively proven with site references if a 3rd party product is proposed
224 3 Design integration with third party systems if not already proven
225 4 Comprehensive walkthroughs of the module
226 5 In-depth consultation with Client subject matter experts
227 6 Develop best practice standards for configuration in Client
228 7 Develop Client codes guided by JAR
229 8 Laboratory configuration and testing
230 1 Develop workflows, standards, policies and protocols
231 2 Develop comprehensive statistically representative data and situation test pack
232 3 Configure in the Laboratory, test and refine
233 4 Specify, document and test workflows (processes)
234 5 Specify & develop Computer Based Training material
235 6 Final presentation and walkthrough of entire solution
236 9 Other Client Asset Operating Cost module configuration and integration related activities
239 Total Software to Manage Client Asset Operating Costs
241 2 Check Bay Control and Logging Software -- if development is proposed itemize what is required
242 1 Liaison and consultation with module specialists
243 2 Integration must be comprehensively proven with site references if a 3rd party product is proposed
244 3 Comprehensive walkthroughs of the module
245 4 In-depth consultation with Client subject matter experts
246 5 Develop best practice standards for configuration
247 6 Develop Client codes facilitated by JAR
248 7 Coordinate with other modules
249 8 Laboratory configuration and testing
250 1 Develop workflows, standards, policies and protocols
251 2 Develop comprehensive statistically representative data and situation test pack
252 3 Configure in the Laboratory, test and refine
253 4 Specify, document and test module specific workflows (processes)
254 5 Specify and develop module specific Computer Based Training material
255 6 Final presentation and walkthrough of entire solution with executives
256 9 Other Check Bay Control and Logging module configuration and integration activities
259 Total Materials Management and Tracking
261 3 Software to manage Consolidation Center Operations
262 1 Liaison and consultation with package specialists
263 2 Integration must be comprehensively proven with site references if a 3rd party product is proposed
264 3 Comprehensive walkthroughs of the module
265 4 In-depth consultation with Client subject matter experts
266 5 Develop best practice standards for configuration
267 6 Develop Client module specific codes facilitated by JAR
268 7 Coordinate with other modules
269 8 Laboratory configuration and testing
270 1 Develop workflows, standards, policies and protocols