Some Management Issues

1. Some Management Issues

2. Scope • Procurement • Contracts • Legal

3. Procurement stages • Feasibility study • Prepare ITT (Invitation to tender) • Select potential suppliers and send ITT • Evaluate bids and produce short list • Short listed bidders give presentations • Final evaluation of bids • Request for ‘best and final offers’ • Final selection Note that, for procurements over €200,000, for public bodies in the EU, the procedure is laid down by a directive.

4. Feasibility Study • Start from the problem. • Identify the constraints. • Try to identify several ways of solving it (or alleviating it or avoiding it). • Then for each possible solution:

5. Feasibility Study (cont) • What exactly do we want? • Is it technically feasible? • Are there packages available? • How much will it cost? • How long will it take? • How much will it save us?

6. Build or buy? • The software industry has been repeatedly criticised for re-inventing the wheel. • Building you own is very expensive. • Buying a package leaves you at the mercy of the supplier.

7. Package software advantages • known, tried and proven (reduced risk)  • other users • many software bugs eliminated • maintained and up-to-date • costs known more precisely • probable enhancements • documentation already available.

8. Custom built advantages • Because it only has to meet your needs, it may be a lot simpler (easier to use and less likely to have bugs) than a general purpose package. • developed according to your specification • should fit in with user environment • can be modified to suit changing user requirements • users can be involved from the outset.

9. Procurement stages • Feasibility study • Prepare ITT (Invitation to tender) • Select potential suppliers and send ITT • Evaluate bids and produce short list • Short listed bidders give presentations • Final evaluation of bids • Request for ‘best and final offers’ • Final selection

10. Invitation to Tender (ITT) Otherwise known as a request for quotations (RFQ) • Results of feasibility study • Summary of functional and non-functional requirements (mandatory, highly desirable and desirable) • Terms and conditions  • Timetable and budget • Information required

11. Selecting list of tenderers • Particularly important in public procurement, where rules may say that lowest tender wins. • Important that they have relevant experience and have financial resources commensurate with the job. • Purchasing departments tend to lump all software supply together.

12. Draw up short list Examination of proposals and elimination of potential suppliers because: • They don’t meet (or don’t understand) the requirements. • They don’t meet other constraints (e.g. we said we wanted delivery in September 2007 and they’re offering delivery in April 2009). • Their proposal does not contain the information asked for (e.g. they don’t give a fixed price, although we asked for one). • We don’t believe their proposed solution will work. • We are unhappy with company (e.g. we don’t think they have the resources).

13. Presentations • Opportunity to clarify things not clear or not stated explicitly in the proposal. • Opportunity to ask awkward questions. • Opportunity to ask for changes. • Can we work with these people?

14. Evaluating bids Common procedure: • Produce a list of criteria and weights. • Get a group of people to score each proposal between 1 and 5 on the basis of how well it meets each of the criteria. • Add up the total of scores × weights for each proposal.

15. Criteria for evaluating proposals for bespoke software • Are the price and timescale realistic? • Does the company have sufficient resources of the right level actually available? • Quality of references. • Stability and financial soundness. • Project management expertise. • Quality management culture. • Fit with requirements.

16. Criteria for evaluating packages • Is the functionality adequate? • Does it meet the non-functional requirements? • How many customers are currently using the package? • Can you talk to some of them? • What do you get?

17. Evaluation of packages (cont) • Will you need assistance to implement it? • How much does it (really) cost (including training, consultancy, optional modules, maintenance)? • How well established is the producer (and the supplier if they are different)?

18. Evaluating bids (example) • How well does the proposed system meet the functional requirements? [15] • Is the supplier sufficiently well established financially? [10] • How easy will it be to expand the system to meet future requirements? [5] • Does the supplier have sufficient experience in the application area? [5]

19. Final selection • Request for “best and final offers” often results in better offer being made. • Some public procurement rules don’t allow this. • Remember to look at lifetime costs. • In public procurements in the end you probably have to take the cheapest. • In other cases you look for the best value for money.

20. UWA’s accounting package requirements • Functional requirements easily met. • Procurement dominated by non-functional requirements: • Client server architecture, with server running UNIX and Oracle and PCs running Windows as clients. • Up to 100 simultaneous users. • Network, server and PCs already in place.

21. UWA’s accounting package – procurement • (In 1996) only three suppliers able to bid. • One dropped out because it appeared they couldn’t meet our requirements. • Left with two. Both had ISO 9001 certification. One was twice the price of the other with no obvious advantages. Both had been in business for about 10 years and had plenty (around 100) customers for their earlier product. • Both suppliers warned us that their software was incomplete and had many bugs. • Existing customers of cheaper company said the it was good at mending bugs and at doing what it promised. • We chose QL, developed and supplied by Distinction, a Swansea-based company, previously known as MicroCompass.

22. UWA’s accounting package – costs (1) • Basic cost £50,000. • Required to take 10 days project management from supplier at £800 per day, plus expenses. • Needed another 10 days consultancy at £1,000 per day. • Maintenance charge 20% = £10,000 per annum.

23. UWA’s accounting package – costs (2) • Training – six people on one week courses at £3,000 per course, plus travel and subsistence expenses, £20,000. • Required to provide and pay for an ISDN line for maintenance purposes. • Had to replace 20 PCs in Finance Office by new ones that could run Windows 3.1 – cost £25,000. • 16 extra Oracle licences required for server, cost £12,800.

24. QL: First five years’ costs Year 1 £126,000 Years 2 to 5 £13,500 p.a.

25. UWA’s accounting package – costs (3) • New and much enhanced version released in 2000. • Had to take it because support for previous version would be withdrawn. • Cost £10,000 but had also to upgrade PCs to Windows 2000, upgrade Oracle, and upgrade server (necessary for other reasons).

26. UWA’s accounting package – costs (4) • Web-based version now introduced – cost c. £40,000. • Big advantages (maintenance much easier, fewer demands on client PCs, easier for non-Finance Office staff to use.

27. UWA’s accounting package – overall experience • Initially quite a lot of problems, many of them arising from bad software engineering. • Difficult to see that they were complying with ISO 9001. • Project manager not very competent; consultants very competent. • Company generally very helpful and problems now fixed. • Ten years after buying it, we are still extending our use of it and getting new benefits. • Given when we wanted to buy, we couldn’t have done better. • We were lucky. The package we selected proved successful and the supplier well managed and honest.