response

 (Adams) To get the resource people on board, I would start by asking them how software could make their lives easier. By getting them in the mindset that you are trying to simplify their processes (as opposed to automating their jobs away) you are much more likely to have a helpful group of partners instead of an adversarial team of contrarians. Just think, would you participate in a project that was going to leave you jobless?

   Once you prevented the concerns from arising or assuaged any concerns that were remaining, you would need to work with them to figure out exactly what the order system needs to do. This is the requirement-gathering phase. You need to work with the experts on the team and preferably someone who is an expert at the software that you need to integrate with. Realistically, your application likely isn’t going to handle everything from the payment details to the shipping information to the vendor details. Bringing in people who know how those systems work can allow you to develop to their standards and ensure interoperability.

   Ensuring that you got all the necessary information can be done in both the requirement gathering and testing phase. Using a long requirement phase would give the resource people time to make sure they aren’t forgetting anything and forward additional requirements they may have thought of over to the developers. Giving them that additional time could cause them to encounter a rare use-case that they would have not remembered otherwise. Running the tests with developers and the people who would be using the system can ensure that it does what it needs. If you are trying to automate away all of those people’s jobs, they are likely going to see at this point and you will probably lose all support. If you aren’t trying to automate jobs away, giving the users a chance to bang away on it would likely find any new requirements or new information.