Saturday, December 19, 2009
One of the bigger challenges as an IT Consultant is when you are asked to help define and document an existing system. Here are some of the challenges, thoughts, and considerations on should have:
- The greatest challenge is balance between real requirements and system constraints.
- How can one balance what users of a real system expect, versus what they would have at the outset of the system. There is a balance to be maintained between the “real” requirements, which existed before the system was in place and those that now pop into the heads of the developers and users. The odds are they might not have said the system needs x, y, and z integrated functions until they have been using it for several weeks.
- The document must be instantly useable to guide future development and testing, which is hard. An existing system has existing users, which means there will be requests very soon to change the system (either corrections to bugs, or enhancements). These enhancements might have been deficiencies to the original system design, which did not have the guidance of the user base’s requirements.
- It HAS to be valuable in analyzing and engineering future system changes; if it doesn’t make sure that future changes don’t conflict with existing functionality, it is not worthwhile.
- Requirements documents are always a challenge to write, and to be useful in general. Let alone when the system is in place and being used.
- Is the client committed to using a requirements baseline? Will they maintain it? How will they do so? Who will maintain it and use it?
Friday, December 11, 2009
The company I work for is starting to head down the path of CRM, we're exploring our options to see what is available and what can be a useful solution for us.There is of course the SaaS/Software decisions, as well as Open/Close system element. Here are some quick thoughts on the situation.
SaaS vs Software
SaaS vs Software
- Either gives you a good bit of flexibility, SaaS is much more flexible than it used to be
- SaaS makes the accessibility of the system that much easier
- Software used to make it easier to administer on a granular level, but that's not a compelling case anymore
- Open source options make it easy to find a low-cost initial system to explore and test
- Either is going to require customization, and this can often mean a special consultant
- All Closed system sellers are going to claim that enhancements and customizations of Open systems make them brittle, and problematic to upgrade, which is true
- But that also begs the question of how easy is it to upgrade from the Closed system
- And which specific opens (Open or Closed) are going to allow for the export of data from the system (the "data roach motel" conundrum)