CO32004 MDM Unit 9

1. CO32004 MDM Unit 9 Case Studies

2. Learning Outcomes • At the end of this unit, you will be able to • Evaluate multimedia case studies for examples of best practice • Identify typical problem situations in multimedia development and take steps to lessen their impact • This in turn helps you • Design and develop multimedia applications in a structured and systematic manner

3. Introduction Case studies are a useful learning opportunity in a subject as rapidly changing as multimedia. • Patterns begin to emerge that inform professional practice (experience) • Knowledge captured and codified in instructional material • But if multimedia is anything that doesn’t work yet, then we all learn on the job • England & Finney - second section (of five chapters) • Self development – responsible for own career!

4. Case Studies • Anonymous or not? • Anonymous stories are harder to read, but you don’t get lost in what you know about the company, and the author can be more frank and analytical • Non-anonymous stories have an instant appeal – easier to skim – you get the story – but can be company- or self-censored • Objective • Think about the selectivity, try to get inside the writer’s shoes • To generalise from the specific • Tie to “Reflective Practitioner” and “Action Research” concepts • As “Junior Honours” students you begin to use literature selectively and appropriately

5. Two Main Case Studies • The Success Story • Archaeoquest discussed next week • Learning from Failure • Petrochemical CBT • Contradictory Objectives • Complex Situations (Growth?) • Transparent Development • Political Situations

6. Objectives • To do a really interesting piece of multimedia • NVQ Training • Lots of 3D modelling, Video, professional voiceover • To complete the small project but • make a clear profit for the developers (£5k from £38k) • And buy new hardware/software (£12k worth of 3D) • To win the big project (£1.5m and falling) • To be confident of carrying out the big project profitably after the customer had used established project metrics to scale back fees.

7. Do you want this project? In small groups discuss whether you would like to win a £38k project that could lead to a million-pound, 18-month follow-on project but would • Last six weeks • Need six main staff • Allow you to use the latest 3D multimedia technology • Require you to use a multimedia authoring tool that none of you have ever used before • Require you to account for every minute of every working day to the customer (as well as your management)

8. Set a sprat to catch a mackerel • Your management want this badly – it will finally allow them to float onto the stock market • They usually require you to break even on £300-350 pppd. Now they are offering less than £150-200 pppd. • This is their gamble – but you are the stake!

9. Mythical Man Day* So what exactly is a day’s work and how much does it cost? • £400 per 8 hour day? • Customer gets discount, £350?, 10 for price of 7? • Employee paid £80-150 per day • Double for employers costs and overheads • How many billable days per year? • 260 working days a year less 28 holidays, 10 sickness, ?? training, ?? internal products, meetings, demos – leaves 200? • Efficiency/hard work: 0.3-1.5 days work per day *Brooks, Frederick P.  The Mythical Man-Month.  Addison-Wesley, 1975

10. Tensions • Technical Risk Management • New multimedia technology • Customer’s required technology • Multiple Projects (especially bugs from completed projects) • Variable competency and commitment • Variable definitions of the training – who is the expert? • Communications protocols - between management layers on each side

11. Risk Management • See “ScunnerProReview” (website) • Neutral in tone – otherwise you shape perceptions • Evaluation of capabilities but also limitations • Pre-empting typical development errors or ineffectual approaches

12. Risk Management • “Project Standards” (website) • Ensure that development team are “singing from the same hymn sheet” • Contractual implications – defines the structure and expected deliverables in each area • Short-hand way of communicating with the customer – meeting of two cultures

13. Risk Management • Interactive Screen Design (website) • Perils of inappropriate communication • Lack of professional experience • Undermines credibility of entire company • Places developer “on back foot” • But also finalises a number of creative approaches

14. Coping with the project • Projects have their own momentum – you can affect their direction but you are only one influence • Known Limitations and Bugs (wk 2 print) • Escalate awareness of implications • Assign indication of severity • Objective – either a working tool, or to undermine continued requirement to use it

15. Activity • With a small group, prepare a similar list of problems you have encountered with Director • Assign a severity to each • How do you think these could be resolved and by whom

16. Independent Verification • ConsultantsReportScunner.doc (website) • Call in an independent, informed third party to document issues • Use this as basis of escalation of future issues as they arise • Not solving the underlying problems, but managing the resulting situation

17. Transparent Production • Spreadsheets were supplied weekly to account for every minute’s work (website) • Need to reduce the cost of data capture and presentation • Need to monitor whether time spent was both efficient and necessary (internal tracking system nay have different objectives) • Opportunity to highlight a limited number of issues – shape the agenda

18. Getting to completion • In this situation the customer has every interest in getting you to keep working on further improvements. Stop them!! • They’re not paying! • They are measuring your quality problems – every hour you work extra for them counts against you! • But you have to own up to and fix what was wrong • You may also not always want to undermine your opposite number – by blaming them for their errors – they could be your best supporter for the next job

19. Getting to completion • Deliverables (website) • Prepare the list • Test the list • Prepare the deliverables and test against the list • Test Report (website) • Internal v External focus for information • Presenting problems in context

20. Aftermath • Development Tool Lifecycle • Small team develop generic tool from specific project • Manage to sell enough copies to improve it • Larger company buys up tool and markets it • Demand grows for comparable features to other tools • Rush-released, rich-featured, over-hyped version comes out causing users problems • Cycle of patch releases • Corporate buying and selling

21. Review of Scunner • Wk 1 – Limitations established and agreed • Wk 2 – Tool vendor gives sporadic assistance • Wk 3 – Much wasted work – crisis escalates • Wk 4 – new version solves some problems (but not all) • Wk 5 – Escalation on well-chosen issues to highest level • Wk 6 – Detailed and critical assessment of problems

22. Final report • Formal Management report (wk 2 print) • Playing “hard-ball” • Read the “note to students” • Read the Management report • In small groups discuss how you would feel if this was your project being reported on. Would you win the next phase?)

23. To summarise • Before the Project • Every word creates impressions and explicit or implicit contracts. • Every commitment made, might become a "rod for your own back". • But you have to volunteer and offer creative ideas in order to gain the contract in the first place. • This is a formidable tension to manage

24. To summarise • During the project • There will be a continual requirement to report status. • You will have to spot problems coming, get defences in place, and raise relevant issues with external agencies if the solution is not within your power. • Simply blaming vendors for the problems in their tools is not enough. • You need to demonstrate that you sought out any available solutions, or have escalated the problem effectively

25. To summarise • After the project • Every word you type for the customer's benefit is part of the pitch for the next job. • They have now invested a lot of time, effort and resources in you, you are the incumbent - unless you give them reason to write you off • Every word you write for internal consumption becomes part of your company's knowledge base. • It will shape attitudes towards you, the customer, the software you produced for the project, the internal practices of your organisation for years to come

26. In the next few weeks… • We will look at case studies of development processes, with an emphasis on the impact a tool has on a given project, in particular on using tools other than Director • Archaeoquest was successful • written in Authorware • in 30 programmer days (and around 10 graphic designer days) • featured a networked expert system that uses generic and situated information to direct users on a tour of local destinations • “Petrochemical CBT” was not • “Scunner” was a problematic tool (bad workmen…!)