O Home O Newsletters O Conference O
 O Qualifications O Forum O Job Vacancies O


Prescription:EP300 Evaluation and Procurement

Aim of Module To provide the student with knowledge and skills to conduct an evaluation and procurement exercise for a new unit of hardware and/or software based on best practice of assessment and Cost Benefit Analysis.

Credits 7

Suggested Time 70 student learning hours

Prescription Expiry Date Nov 2002


Level and Assessment Schedule
TopicsHighest
Skill Level
Suggested
Assessment
Percentage
1 Risk Analysis C 5
2 Case Study P 90
3 Debriefing P 5

100


The Student Will

1  Risk Analysis
CDescribe the relevance of risk analysis to the procurement process. Establish for a given length of project the appropriate technique to be applied.
top
2  Case Study
P2.1Complete a comprehensive case study involving the acquisition of a new unit of software/hardware. This should include the preparation of a report for the user setting out alternatives, their evaluation and the preferred option with supporting documentation.
P2.2Prepare and deliver a user presentation of the report.
top
3  Debriefing
PReview the report and presentation with the user.
top
Note
> At this stage the student is unlikely to have the experience or maturity to be given responsibility for a major acquisition.
> It will usually be impracticable to set up a case study situation based on a full-scale specification, current costing, etc. for a large system.
> Since the acquisition of a ‘’small’’ system can be as significant for a small business as a large system is to a large business in terms of:
- the investment relative to the owner's equity
- the impact on the fundamental procedures of the business
It is suggested that the case study be directed to the acquisition of a ‘’complete’’ small system. The case study should revolve around an identifiable business unit e.g. a retail store, a professional office, or a semi-autonomous section of a larger organisation. If this cannot be arranged then a third-party should be arranged as the ‘’user’’ to avoid the tutor having to play conflicting roles.
> The nature of the project must be clearly understood by all parties.
> The System Specification should be ‘’given’’ i.e. the preparation of the System Specification should NOT be part of this case study. If the Specification has been previously prepared by the student then it should have been fully cleared by the tutor to ensure that it is suitable for the new exercise.
> Rather than conduct a genuine and complete calling of tenders the exercise should be managed as a ‘’dry run’’ with the co-operation of a pre-selected short list of vendors who understand the nature of the case study. While the results can be fully analysed and reported upon to the ‘’user’’ this approach keeps the project within manageable proportions, allows a choice of vendors to rotate and avoids the complications of an unsuccessful competing vendor objecting to the involvement of the tutor in open commercial activity. It also avoids the more serious complication of the ‘’user’’ who follows an evaluation report prepared by a student, buys a system which turns out to be a lemon (for whatever reason) and seeks to attach responsibility to either the student, the tutor, or the training institution.
   
Introduction
Regulations
Module Prescriptions
 


Back to list of Prescriptions



Introduction O Regulations O Module Prescriptions O


O Home O Newsletters O Conference O Qualifications O Forum O Job Vacancies O