| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | Dec » | |||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
- product manager (7)
- projects (40)
- resourcing (4)
- software selection (1)
- tax billing software (32)
- vendors (49)
- water billing software (38)
- 19. April 2011: User groups
- 19. April 2011: Detecting theft
- 13. February 2011: Automated water meter reads
- 27. January 2011: What German utility billing software would that be?
- 5. November 2010: Seven myths of billing implementations
- 24. October 2010: Comparing utility billing software
- 1. October 2010: Failing in the public sector
- 29. September 2010: Project failures
- 27. September 2010: Not the product manager
- 25. September 2010: Not the product roadmap
projects
Making the most of the software
Within six months to one year after an initial software implementation project is complete, there is often a need for a second project to address opportunities with the original implementation. Typically with a new system we try to do things better than we have in the past – the project goal should be to try and improve upon the existing. In many billing implementations the sheer effort of getting the software implemented means that business process improvements are let slip and the old ways are allowed to continue. For many processes, improvement can be achieved, but with other processes, the new way of doing things is not realistic — there are nuances, dependencies, or constraints that are not considered at the beginning of a project. Addressing these opportunities as they are understood will help longer term adoption of whatever product you are attempting to implement.
Leave a Reply
You must be logged in to post a comment.