top of page

Subscribe to future posts by email

Thanks for submitting!

Search
  • Writer's pictureJoel White

Unintended Complexity

Working with (genuinely) small companies has reminded me of the importance of checking whether processes in one part of your operation disregard the resulting complexity created in other parts.


Small companies are forced to be mindful of this because needless complexity means you may have to wrestle with hiring that 17th employee, or push a part-time employee to become full-time who doesn't want to, etc.


Recent real life example:


I was helping a company revamp an outdated pricing model, and pushed them to align the invoicing basis of their units to the the pricing basis of those units. Data points should be invoiced per data point; queries should be invoiced per query, right? Otherwise, I said, you will have problems down the road with change orders, not getting paid for all the work you performed, etc.


One of their managers said, "But we don't automatically track a lot of those things, and would have to hire an admin to start doing this across our projects."


So let me ask:

  • Do you have units in your contracts that take hours of sleuthing each month to uncover?

  • Are you sure that [per item, per visit, etc.] unit can't be changed to per month? (Even I can count months...)

  • Can that unit for 50 [CRFs, widgets, etc.] that takes 2-3 months to complete be changed to a one-time trigger?

What are you doing that makes someone else's (or a customer's, or a supplier's) work more complex than it needs to be, and what are you really gaining from that?

bottom of page