Challenges when demoing / training / pitching complex systems

Over the last few days, I’ve been in a few vendor demos, trading partner reviews, product pitches, and project discussions, all reviewing complex systems or processes, and tools / software / services to help out. Some important, common, and somewhat random issues kept popping into my mind, all about trying to have a discussion about complex systems / interactions …

1. Always be mindful that if something was easy, we probably would have done it already. Be alert for things that are conceptually clear and straightforward, but tough to actually automate – like pivot tables / aggregate queries in SQL data bases, or the concept of “clean” data, matched up from multiple systems.
2. Be very careful when using common terms for specific meanings. A classic case – in many organizations, there can be multiple definitions of the word “customer” – make sure everyone knows specifically who we are talking about! Also, when your potential trading partner (or their implementation team) is talking about “customer”, they are probably talking about you, not the folks you sell to (who you think of as the “customer”).
3. Some design insight – build for batch processing. Trading partners typically interact via a web interface – and the tech team likes to take lots of time to show how nice and user friendly it is. Problem – if/when we want to do orders / transactions at scale, we’re gonna want to use EDI or XML. Ya gotta be ready with the batch process right away … when designing systems for your potential customers, make sure you have a batch mode.
4. Everybody wants to streamline their own business process by pushing the work to someone else. Sooner or later you’re gonna have to get the other guy to accept responsibility for getting the work done, or else you won’t be able to claim the benefits in your business case!
5. A critical element when talking about projects between partners and/or internal groups – must be clear on requirements, basic business process, and scope. It’s not a meaningless exercise to drive for a decent level of documentation for this stuff – gotta be clear, especially when time commitments and money are involved. Also, you need to understand critical assumptions, like information / data availability, rules clarity, resources to do work / provide information, and time to implement.