Table of Contents
A budget is the money that an organisation allocates to make purchases.
The main types of budgets are:
- Direct materials budget: materials used in the production process. It is usually based on a forecast of sales.
- Capital budget: major equipment and construction services.
- Operating budget: maintenance, repair and operating (MRO) supply or service.
Other types: grants and government contracts
Budget Control Tools
How organisations control their budgets:
- Real-time budget data: amount spent versus amount left.
- Defined authority: in terms of requisitioning and purchasing authority of employees.
- Defined processes: for requisitioning, purchasing, receiving and payment processes.
- Review and Audit: of purchasing practices and procedures.
- Separation of functions: the requisitioning, purchasing, receipt, and payment functions to reduce fraud.
- Use of tracking identifiers.
IT Solution RFP Outline
A Request for Proposal (RFP) for an IT Solution can be simple or complex depending on the scope and how prescriptive the specifications are.
General High-Level Outline
A typical IT Solutions RFP has four top sections:
- Product and Service Requirements
- Proposal Submission Requirements
The introduction section contains the essentials:
- Brief: one or two paragraphs summarising the RFP’s theme.
- Statement of Purpose: the motivation for looking for a new solution.
- Background: description about the company and an account on the history that led to the finding of a solution.
Product and Service Requirements
This section specifies what is expected from the supplier in terms of the product and services they would deliver if awarded the contract.
- Scope of Work: what activities are in and out of scope.
- Deliverables: concrete deliverables.
- Execution Timeline: the times at which each deliverable ought to be delivered.
- Outcomes and Performance Standards: specific outcomes (rather than actions) as well as KPI baselines that will be used to judge whether the deliverables have met expectations.
- Handover Requirements: if the products and services are transferred to a third party after the work is completed, it is useful to set out the precise expectations which are best formulated by the third party.
Proposal Submission Requirements
This section specifies what is expected from the proposal package and its delivery as opposed to the proposal’s technical content itself.
- Required Documents: for instance, whether technical architecture and financials should be included as separate documents.
- Document Structure: the proposal document(s) may need to be structured following a prescribed outline and layout.
- Evaluation and Award Process: the criteria that will be used to judge each proposal and what factors may contribute to the awarding of a contract.
- Process Timeline: steps and dates including questions and answers, proposal submission deadline, award communication, etc.
Terms and Contacts
- General Terms and Conditions: geographical scope of law under which the agreement falls.
- Specific Terms and Conditions: for example, liability requirements in connection to the use of subcontractors.
- Budget and Pricing Conditions: for example, the price may be in the customer’s local currency as opposed to that of the vendor.
- Key Contacts: a Single Point of Contact (SPOC) and contacts by role
Technical Specification Elicitation Process
This process is used to fill the “Product and Service Requirements” section.
Scope of Work and Deliverables
- Does the solution require new infrastructure or the modification (or extension) of existing infrastructure?
- What is the infrastructure scope? For example: Data Centre, Cloud, Power, Network, Hardware, Firmware, Operating System.
- Can the solution be open to multiple infrastructure options? For example: Cloud (IaaS) and Data Centre.
- What are the fault-tolerance, reliability, availability and serviceability infrastructural requirements?
- Are there preferred vendors and/or models for infrastructure?
- Will the delivery of the required infrastructure cause service disruption and if so, how will it be minimised?
- Are the personnel and skills required to operate the infrastructure particular? For example, the customer’s operations department maybe only supports the Wintel platform.
- Does the solution require new software or the modification (or extension) of existing software?
- Must the software be necessarily of the COTS variety? If so, what degree of customisation is expected?
- Must the software be bespoke? If so, what major function and non-functional requirements
- Can both COTS and bespoke options be considered? If so, what criteria must the selection satisfy?
- Are there preferred vendors for COTS suppliers and if so, why?
- Are the personnel and skills required to operate the software available?
- Does the solution require the integration with existing systems?
- Is the integration plug-and-play or does it require bespoke configuration and/or development?
- Is the surveying impact assessment of the legacy IT landscape the supplier’s responsibility?
- What degree of detail can be provided to the supplier about the legacy IT landscape?
- Are there suitable test environments to verify the integrated solution before it goes into production?
- Will the introduction of the new system result in the election of master data systems within the new system?
- Will the introduction of the new system result in the demotion of existing legacy IT systems?
- Are there prescriptions in terms of what systems are strategic for a given set of processes and data? This is important to avoid duplication of features.
- Are the interfaces required from the legacy IT landscape readily available or is there a complex on-boarding process? For example, firewalls, subnets, password creation, port redirection, SSL certificates and so on.
- Will the solution simply process existing data or will it generate new business entities?
- Does the data need to align with an existing canonical model?
- Does the data need to be replicated with key specific systems?
- Does the data need to be mastered in key specific systems?
- Does the data need to comply with specific standards in terms of structure and/or security? E.g. credit cards are never stored in plain text.
- Does the supplier need to propose a suitable business entity model?
- Does the data model need to align with a prescribed model such as SID?
- Does the solution introduce new business processes, or requires the modification (or extension) of existing ones?
- Will or could existing business processes be impacted by the solution?
- Are relevant business processes well documented? If not, does the supplier need to document them as part of their deliverables?
- If the solution establishes new business processes, what level of participation is required from the relevant stakeholders?
- Do any considered business processes need to confirm with a prescribed model? For example, eTom.
A complex IT Solution is typically broken down into stages (some may run in parallel):
- Proof of Concept: this stage may take place as part of the RFP process itself, or after the contract has been awarded. The objective is to check whether the proposed solution has the shape envisioned by its sponsors.
- Environment Setup: this includes all the activities required to perform the actual deliverables. For example, allocation of the Data Centre’s rack space.
- Platform Setup: this stage covers the setting up of the infrastructure up to Operating System (OS) level.
- Phased Delivery: this includes software installation, configuration, development and testing—if following an Agile methodology. The actual delivery model may use a variety of techniques: Waterfall, SCRUM, XP, etc.
- Final Technical Verification: this will include the customer’s verification methodology as well as that proposed by the supplier.
- User Acceptance Testing: as prescribed by the customer.
- Handover: it may require training and the collaboration of relevant third parties.
Outcomes and Performance Standards
Here, various metrics may be used subject to the specific solution’s context. For example:
- Transactions per Second (TPS)
- Latency in milliseconds
- Maximum concurrent users
- Encryption strength
- Mean Time to Repair (MTTR)
- Mean Time Between Failures (MTBF)
- Mean Down Time (MDT)
- Time Between Overhaul (TBO)
- Startup Time
- Human Interaction Efficiency: e.g. number of clicks that it takes to upgrade to a new plan.
- Disability Capability: e.g. color blindness.
- Branding Compliance
A solicitation document is used to solicit quotes or proposals from suppliers. They are normally classified as RFI, RFQ and RFP:
- RFI: Request For Information
- RFQ: Request For Quote—sometimes called Invitation For Bid (IFB)
- RFP: Request For Proposal
A Request For Information (RFI) is a business process to learn about suppliers’ capabilities. An RFI process is characterised by the following properties:
- It is used to obtain non-price information.
- It serves to validate whether the specification is feasible.
- It serves narrow down the list of potential bidders by discarding those that are in misalignment with the specification.
- The RFQ, RFP processes usually follow after it.
A Request For Proposal (RFQ) is a business process to obtain suppliers’ prices. The RFQ process is characterised by the following properties:
- It is based on fixed, well-understood specifications
- Its sole aim is to obtain pricing information rather than concepts or ideas.
- It is centred mainly on pricing information but typically includes lead time and terms.
- Price is typically the deciding factor.
- It is not “an offer to buy” and this point must be legally worded .
A Invitation For Bid (IFB) is similar to an RFQ. The term is more typical in government that in the private sector.
A Request For Proposal (RFP) is a business process to obtain suppliers’ proposals which normally includes execution, capability, delivery and pricing information. An RFP process is characterised by the following properties:
- The supplier may provide inputs to devise the specification.
- It often seeks the solution to a complex problem rather than complying with a discrete specification.
- Orders are typically awarded based on overall value rather than price alone.
- It is not “an offer to buy” and this point must be legally worded in the documentation.
At least the following sections must be considered in a solicitation document:
- An overview: why the product or service is needed.
- Evaluation and award process: an accurate description.
- Response instructions: how the supplier is supposed to respond and in which format.
- Deadline: or submission schedule if using a multiple-step bidding process.
- A specification: the product/service requirements.
- Quantity information: if applicable
- Delivery location(s) and schedule: for the requested products and services.
- Terms and conditions: For the solicitation itself and the order
Examples of terms and conditions:
- Rejection right: “The organisation reserves the right to accept, reject or make a counteroffer for any or all offers made in response to this solicitation”.
- Not an offer to buy: “The solicitation has the purpose of obtaining X (price, information, etc.) and it is not an offer to purchase goods or services.”
- Payment terms: “The organisation will pay the selected bidder within XX days of receiving the goods and/or services.”
- Cancellation right: “The organisation has the right to cancel any orders without payment at any time”
- Warranty: “A two-year warranty with x,y,z conditions will apply to the goods and services purchased”.
Statement of Work (SOW)
A Statement of Work (SOW) is a description of what is to be accomplished, when, and what constitutes an acceptable result.
Generally speaking, it includes the following information:
- Project objectives.
- Background information: e.g. history of the problem.
- Project requirements: what needs to be done, quality standards, and division of responsibilities.
- Work breakdown structure: a division of the service into distinct segments.
- Deliverables: specific, tangible, and measurable tasks that must be accomplished.
- Hold points or milestones: points in time where the purchaser and supplier can assess the quality and timeliness of the most recently completed segment and the project as a whole. They are often used to give the buyer the option to terminate services or withhold payment until the work is performed satisfactorily.
- Reporting requirements.
- Performance evaluation factors and acceptance criteria.
Poorly written SOWs result in:
- Services that fail to meet quality expectations.
- Financial and time loss.
- Unfavourable costs.
- Disagreements and litigation.
- Promote proper scheduling, forecasting, and coordination of resources.
- Lead to proposals that are both comparable and aggressive in terms of good pricing and other attributes.
- Reduce, if not eliminate confusion.
A specification is the written description of a need. A specification serves to communicate requirements for a purchase to the purchasing department and the supplier.
- Availability to compare different suppliers when they provide quotes for the same specification.
- Increased likelihood that the product or service will perfectly meet the needs of the organisation.
If the specification includes the description of a service, it may be called a Statement of Work (SOW).
Most common types of specifications:
- Performance specs: define the result to be achieved by the product or service.
- Design specs: a structural description of the product; including materials to be used.
- Functional specs: what the piece of equipment of software should do from a user’s perspective. An evaluator team is usually used who will sign off the degree of compliance.
- Blueprints/drawings: A visual guide for how the product is to be made.
- Trade name or brand specs: This is usually detrimental because it decreases competition.
- Physical/Chemical specs: Scientific attributes of the materials to be used.
An organisation will normally rely on their team of technical experts to conform a specification. When this is not possible, input from other individuals and groups will be selected:
- Suppliers: When suppliers assist in the process, the following considerations apply: (a) that proprietary information isn’t shared with another supplier (b) that the supplier doesn’t do an excessive amount of work without compensation (c) that a relationship of trusts exist if you are not seeking the input of another supplier (d) that the input of one supplier doesn’t make any future competitive bidding unfair or less than fully competitive.
- Consultants: They are useful for organisations that haven’t specified the product in the past and have not learned what the pitfalls are.
- Other organisations: those who have specified a product before may be willing to assist an organisation that is specifying a product for the first time.
- Professional purchasing organisations: Some purchasing organisations have been compiling specifications to share among their members.
A variety of pitfalls associated with specifications:
- Absence of standards: it eliminates the purchaser’s ability to consolidate volume and lower costs.
- Over-specification: specifications that are stricter than they need to be; this results in less competition and higher costs.
- Under-specification: omission of key details and/or overly loose limits on key parameters. The result is continual quality problems.
- Slanted/Slanting specs: those that exclude otherwise acceptable products or suppliers. They reduce competition and result in higher prices.
- Out-Of-Date/Obsolete Specs: specs that worked in the past may not necessarily work in the present or future. There might be changes in the availability of new materials, in government regulations, to the end product in which a component is installed.
- Standards differences between countries: standards and measurements may differ. For example, American and British gallon.
Next Level Purchasing Association (NLPA)