Hi Shail,

Is the intent to build a new system, or to buy an existing system to handle this?  (Do you or the stakeholders know this yet, or is your analysis looking to lead toward a build-vs-buy decision?)

Might be already obvious, but a good approach might be to start collecting the most valuable points they're looking for and start using that as your due dilligence comparison criteria.

* Synch up with your main stakeholders and find out their main usage of the current system, or, what they'd potentially want (e.g. "supports workflow management," "integrates with internal system XYZ," "allows me to map the customer query to the customer service representative who fielded it"). 

* You're building a list of potential features -- abstract this out to a large functional area that encompasses the type of system they're looking for

* Depending on client's needs and time... iterate through this list a bit (get anything from 5 - 20 main features); list them in terms of priority if you can (either with stakeholder input, or use your own judgement... be sure to back it up!)

* Use these high-level features as the comparison critiera in a comparison matrix, and come up with a simple scoring method (e.g. "each vendor is scored 1 to 10, where 10 means their product can perfectly support the feature")

* Identify some likely existing systems/vendors out there, and rate them on the high-level features you defined

This could end up producing a "Vendor Comparison Matrix" spreadsheet or slide deck that you can then use for detailed analysis of options.

-- Adam

Hi Shail,

The question seems a bit loaded: which prototype to present, "the most complicated feature or the easiest feature" (I read that as complicated from a development/implementation point of view).

My thought is to really nail down the client's desires... identify their top needs, and make sure you really get to the heart of the client's useage of the potential new system.

After identification/prioritization of features, it might come down to how your firm deals with such client systems.  Some folks may say to pitch the "most complicated" featureset first, to help with iteratively developing the system to manage risks.  If your organization or the client do work differently (e.g. if your firm has a fixed-price arrangement of some sort), then you may modify your approach/suggestion.

Either way, I think you're on the right track if you start identifying client's needs first and foremost, and only after that put on the filter of complexity of underlying systems/architecture.

-- Adam