| 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 (4)
- projects (36)
- resourcing (3)
- software selection (1)
- tax billing software (30)
- vendors (42)
- water billing software (32)
- 8. June 2010: More on project success
- 6. June 2010: Project success
- 3. April 2010: Screwing up
- 2. April 2010: When things go wrong
- 31. March 2010: Do projects ever end?
- 29. March 2010: Project costs
- 7. March 2010: Implementing the software wisely
- 21. February 2010: Dealing with regulation
- 18. February 2010: Effective project management: the client perspective
- 14. February 2010: When projects go bad
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.