You are currently browsing the Public Sector Billing Blog weblog archives for the day 11. October 2009.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Sep | Nov » | |||||
| 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 | 31 | |
- 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
Archive for 11. October 2009
Too many cooks
11. October 2009 by admin.
How big should the team be that selects and implements software? A Canadian consultancy believes that the optimum size is five or six, according to a story in IT World Canada.
When buying a commercial app or working with a vendor to create one from scratch, organizations are specifying too many requirements, including ones that are non-essential or cosmetic. According to one Info-Tech Research Group Ltd. consultant, the key to successfully selecting a vendor for packaged or custom applications is to identify core requirements quickly and keep the initial selection team small.
“If you have a team of more than five people who are commissioned with finding the right solution and requirements, you’re probably wasting a lot of effort,” said Andy Woyzbun, lead analyst at London, Ont.-based research and consultant firm. Especially for customized projects, design by large committee almost never works, he added.
Posted in projects, tax billing software, vendors, water billing software | Print | 1 Comment »