HIBACHI VOLCANO

NICE!

Posted via email from Christopher's posterous

How to document an existing system [requirements document]

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?

This dog loves football

She sleeps with one (on a Washington Nationals blanket no less).

Posted via email from Christopher's posterous

Initial thoughts on exploring CRM solutions

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

• 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 vs Close

• 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)
  

Any option available seems to have a rather steep learning curve, and customization challenge. These aren't particularly good reasons to avoid a CRM solution, if that is in fact in the best interest of the organization. In fact, one can argue that this is a prime example of "fail fast forward", get the implementation going so you can figure out what has gone wrong.

To me, that is what makes a low-cost initial tool something important to consider. You can readily pilot the option in a low-risk manner. But there is always the element of opportunity cost, time spent on the pilot, etc.

Posted via email from Christopher's posterous

Why do LinkedIn searches expire?

I was searching for some answers on LinkedIn (anyone with some good views on CRM tools for a small consulting firm). Doesn't seem to make sense unless they were timing me out of the website itself.

Posted via email from Christopher's posterous