Request for Information - Google Forms

Public Sector - Request For Information

Discreet survey request for information

1. Survey - RFI
2. Explanatory Notes

Creating a survey for suppliers to respond to an RFI

The following is an iFrame insertion into this blog to allow a visual example of a solution designed in Google Drive using an integrated set of applications. 

An online survey to solicit suppliers who have developed estimating or budget tools for a public sector treasury and ICT department. 

#	Introduction	This sheet provides explanatory notes which aim to assist the respondent in understanding our expectations in completing the response sheet
1	Background	Our client, the Office of the CIO, is seeking to identify tools which might be used by South Australian Government Departments and Instrumentalities (Agencies) to establish better quality cost and benefits estimates as input into business cases for ICT enabled business transformation and business change initiatives.   This spreadsheet seeks to ascertain the extent to which the tools that you offer would be of value to these agencies.  Your response will contribute to our market research - it does not entail any commitment to purchase - simply to establish a better understanding of the tools that are on offer in this particular area.
2	Structure	We have attempted to structure the response sheet such that an initial response can be provided in 24 hours - in terms of the scope of costs and benefits that the tool assists in capturing as it relates to a taxonomy of projects undertaken by agencies.  Following completion of the initial assessment and provision as a response, we would value additional comments being provided about the capabilities and features offered by your tools in the nominated areas.  This will enable us to undertake some initial mapping of tool footprints, helping our client to understand the scope that differing tools cover.  We hope it will help to identify whether there are single tools able to cover the majority of cases, or whether there are some complementary tools, each focusing on quite distinct segments of the problem space.
3	Philosophy	The underpinning philosophy associated with our exploration of this space includes the following: * there are no ICT projects, only business projects * business change projects are about executing business strategy - about establishing the business capabilities required to support business goals and aspirations * business change projects involve strengthening business capabilities and supporting technical capabilities * costs and benefits will arise in relation to aspects of these capabilities and need to be considered as a whole within a business case * business change projects often fall within a broader business change program - business cases may be prepared for business change programs or for subsequent business change projects
4	Project Taxonomy	We have classified projects in terms of the following characteristics: * stakeholder involvement (note 5) * capability status (note 6) * products delivered / used (note 7) * services required (note 8)
5	Stakeholder involvement	The following combinations of stakeholders may be involved in using the technical capabilities for a business change project: * external (ie. customer or supplier or regulator interactions are involved in the scope) * internal (ie. only employees are involved in the scope) * multi-party (ie. internal and external, with external stakeholders having differing roles)
		An increasing number of projects do have external interactions (customers, suppliers, etc)
		An increasing number of projects involve a multi-agency approach to meeting business and community needs
6	Capability status	The business and technical capabilities for a business change project may entail: * establishing new capabilities that the agency did now own or use * upgrading or enhancing existing capabilities in use by the initiating agency or available through another agency or external entity
		Integration and transition arrangements are more complex when existing capabilities are within scope.  Hence, the interest in separating these two categories.  No doubt, many projects will have a mix, but some will be largely "greenfield" opportunities.  Activities which will need to be addressed include: * business process change * business transition planning * system transition planning * data conversion
7	Product	This relates to the technical capabilities that are within scope for a business change project.  Are these technical capabilities based around application software that is: * commodity product (used by multiple customers, often referred to as COTS - commercial-off-the-shelf) * custom or bespoke product (developed to specifications provided by the customer)
		The type of product signficantly influences internal versus contracted services/activities for the project as well as the range and mix of services involved (eg. software development versus software configuration).
8	Service	There are a number of key service categories likely to be involved in any business change project.  We are interested in the extent to which your tools support each or all of these categories: * software development * software configuration * software integration * system adoption (acceptance testing, data conversion, training) * business change (work procedures, cultural change, documentation, etc)
9	Cost taxonomy	We have identified the following considerations in estimating and assessing costs for a business change project: * capability types (note 10) * capability components (note 11,12) * financial (note 13) * planning (note 14) * analysis (note 15)
10	Capability	There will be a need to distinctly identify costs associated with: * business capabilities * technical capabilities
11	Business capability	Business capability costs may relate to improvements to: * process * information * people (skills, knowledge, culture) * other assets (office, vehicle, equipment, etc)
12	Technical capability	Technical capability costs may relate to improvements to or use of: * application software (development or customisation) * application environment (DBMS, development tools, etc) * operating system software * middleware (EAI, ESB, etc) * server infrastructure * network infrastructure * device infrastructure
13	Financial	Financial costs will include: * once-off * ongoing
		Financial considerations will also consider: * investment / capital funding * operating / recurrent funding
		This will also require the ability to accommodate different pricing models - ownership of products versus use of services
14	Planning	Program and project planning typically involves the following considerations, each of which generate cost profiles: * inputs and outputs - products/services used and products/services delivered * approach - work breakdown structure, resource demands, rates, costs * risks - mitigation strategies may generate additional project activities and costs * change - stakeholder engagement and change management strategies may generate additional project activities and costs
15	Analysis	The analysis of costs and benefits needs to consider: * economic analysis (note 16) * financial analysis (note 17) * sensitivity analysis (note 18) * options analysis (note 19)
16	Economic	Economic analysis takes account of partial use of assets, both existing and new, such that the cost burden attributed to the project is in proportion to the anticipated use by the project and therefore benefits claimed.  Cost benefit analysis will also consider the time effects of costs, generating an NPV for effective comparison of differing options
17	Financial	Financial analysis is effectively cashflow analysis with the capacity to identify differing sources of funds for covering internal costs for which budget provision already exists versus external costs which create an explicit cash burden.
18	Sensitivity	Typically, there are a number of project assumptions or parameters which can significantly impact on the overall economic analysis and project justification.  Examples include: * adoption rate for technical capabilities (eg. transition plans for progressive rollout, adoption rates for consumer services) * resourcing profile and associated project "speed" * contingency provisions (cost categories to which provisions are applied, and rate agreed) * resource costs (internal staff, backfill of internal staff by contractors, market rates for contractors)
19	Options	Business cases may need to assess multiple options.  Invariably, an assessment of the differences between a "no change scenario" and "proposed change scenario" will be necessary.  Costs and benefits will be required for each discrete option.
20	Benefit Taxonomy	We have identified the following considerations in relation to benefit estimation: * capability (note 21) * stakeholder involvement (note 5) * timing (note 22) * quantification (note 23) * realisation (note 24)
21	Capability	Benefits may be derived by a business change projects in relation to: * business capabilities * technical capabilities
22	Timing	Benefits may be derived by a business change project as: * once-off * ongoing
23	Quantification	Benefits may be assessed in the following ways: * tangible / intangible * measurable / unmeasurable * financial / non-financial * realisable / unrealisable (note 24)
24	Realisation	Benefits may be derived by a business change project through: * increased revenue/assets * decreased cost * improved productivity
		Improved productivity creates capacity to undertake additional tasks but does not enable the benefit to be realised as a labour related financial saving