Accounting Software Consultants – Get Agile!
Agile Software Development has been around since the mid 90’s and is gaining acceptance. If you implement mid-range packaged accounting software, like Microsoft Dynamics, you really need to look at this methodology. It is characterized by:
- Customer satisfaction by rapid, continuous delivery of useful software
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Even late changes in requirements are welcomed
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Self-organizing teams
- Regular adaptation to changing circumstances
The reality is that however detailed they may be, specifications documents never deal with all of the actual requirements. For example, it is a very rare spec that includes how to handle data entry errors, yet these are an important part of every system. What you really need is a process that puts the customer, the implementer and the developer at the same table, each constantly helping the others understand the requirements on the one hand and the system capabilities / limitations on the other.
I would argue that this approach should extend to training as well. Classroom training set up in a generic, simple company with prepackaged exercises that always work has a limited usefulness in my experience. It is more useful for clients to deal with their own system and learn to solve their own problems. For example, one of my clients does an international consolidation of numerous subsidiaries. Instead of designing a training course around the consolidation, I chose one subsidiary and converted it in a test environment. Then I sat with the two analysts and we did one together. As we finished each step, one of the analysts took a screen capture and annotated it in Word for our documentation. Finally, the analysts each did their own companies, with me available for questions. As we hit setup, data and security issues, we solved them together. The analysts came away with a better understanding of the configuration of their system than they would have had it been a pre-packaged demo that ran perfectly.
What do you think?