- "Standing data"
- "the rest of the data"
- a) Depends on the size of the bakery, if it's Hovis they should probably be careful, but if it's a corner bakery (a la boutique-city-style), they should probably jump to computerized b) Pilot, don't stick all your hens in one basket c) Direct, computerize the records overnight d) Direct, don't try to fragment two halves of the hospital with different records, although staggering the rollover times may ease system load. Make sure the application can be executed in a virtual machine, and can be configured to sit behind a reverse proxy/load balancer, then it is possible to dynamically scale the system by adding more boxes e) Direct, transition in the summer holidays before new timetables are issued, and early in the summer holidays to allow the system to fail f) Depends on the production state of the factory: if its 277365, do a phased conversion to prevent having everyone from having to down tools. If the factory is shut down at nights and weekends, transition then g) This a new system, no transition is necessary
It should be noted that humans do not like change. This applies very nicely to this situation because you are changing the entire environment the human is working in. If you are changing over a system, make sure that your users know they can reach you for complaints, and that you personally care about the users. It is a stressful time to transition a system, in any shape or form, and my preferred method is to transition the entire company over in one solid lump to prevent dragging out the process. If the software is designed poorly in terms of user experience, users will require training, whilst properly executed software will not. Ensure your users have a port of call, and make sure the engineers of this software are available to fix "teething" problems with the interface (creating shortcuts for common tasks, fixing tab indexes, etc)
- a) An interview, observation and example documents b) An interview, observation and exception reports c) Bugs may exist, new security flaws in the language will emerge, users may appear irritated d) The system may need to be changed in the future. However, if maintenance documentation needs to exist, I would doubt the capability of the language in question to explain itself
- a) Phased, write the current information up into the system whilst handling new transactions b) "Please can we look at the source code?" If the managers can understand the control flow, then a programmer can. "How fast could you add a hypothetical feature?"
- An in-program assistant and based help, which interactively links into the program to show help tailored to how the user is known to behave and what tasks they want to complete
- a) The back-to-school approach by calling a "training seminar" or class b) The one-on-one approach, sit down next to the user in a pair-programming fashion and teach them everything how the program wants to do c) "Group therapy", assemble 4-6 people and one developer and let them teach each other. Reiterate that it is OK to not understand