Thinking outside of the box: the third way

I want to document something which happened to me last week, not in order to show how wonderful I am or to pat myself on the back, but in an attempt to learn something and internalise a way of thinking, a way to solve one type of problem.

First of all, the background. Priority has a type of data known as 'business opportunities', otherwise known as presales. The salespeople open these opportunities, recording the customer and the approximate value of the opportunity. When the opportunity reaches the status where the customer sends in his order, automatically a project is opened from the opportunity [this is a non-standard enhancement that I added] and the scope of management changes. After all, a customer order is a 100% promise of further work and so we should know how much work is going on the books and when it is going to be produced.

Priority has two kinds of customers: temporary and permanent. A permanent customer is what we normally think of as a customer: there are orders, delivery notes, invoices and receipts. Naturally a permanent customer has an account in the financial 'books'. A temporary customer, on the other hand, is the complete opposite: no orders and no financial record. About the only data types that are suitable for temporary customers are business opportunities and price quotations; we can hand out price quotations like chocolates, but only a certain percentage will turn into orders and so we don't want to open permanent customers for those that don't. A temporary customer still has all the contact details so in a sense, we're not losing anything.

This is where we have the conflict: what happens when a business opportunity for a temporary customer reaches the status which causes a project to be opened automatically? It's not possible to open a project for a temporary customer, and so when this happens, I get a phone call from a salesperson saying that no project has been opened - or worse, the salesperson opens the project manually (after the customer has been converted from temporary to permanent) and doesn't fill in key fields correctly.

My knee-jerk reaction when I heard about this was to prevent opportunities for temporary customers reaching the critical status. The sales people were up in arms, for apart from anything else, they had no way of signalling to the accounts department that the customer status needed to be changed - this was done by a message being sent when the opportunity reached the critical status. 

So we had a situation with two mutually opposite requirements, with no real way of solving the problem. A third option is required. My usual technique at times like these is to go for a walk; getting away from the computer generally allows a solution to pop up. It's also good to get some exercise, especially in these cold and rainy days.  

After walking up and down the warehouse aisles a few times, a solution did appear. Somehow it must be signalled that the automatic opening of the project must be delayed until the customer becomes permanent. My first instinct was to save the opportunity number in a table and then have a program traverse this table periodically. A few more aisles gave me a better solution: there is no need for a table; instead a flag can be set in the opportunity. Once I had this idea, it wasn't difficult to write the program that opens the project; most of the code was based on the original code that executes when the opportunity changes status.

I was disappointed in that none of the sales staff appreciated - or even understood - the solution. On two successive days, different sales staff contacted me to say that no project had been opened; I told them to wait a little and that soon they would receive an email saying that a project had been opened for a given opportunity. As I had written this in an explanatory email, I can conclude that either people don't read my emails (quite probably) or that they don't understand them. After all, sales people have to sell (they have skills that I certainly don't), and in the same way that I don't understand the ins and outs of selling and of the finer points of our products, they don't understand anything of my world and the constraints under which I have to work. 

But we're not here to talk about how the idea was executed in Priority, but rather how to find a solution when there seem to be two mutually opposite requirements. Step back from the problem and try to find a third way! Don't fixate on those requirements; almost certainly there will be a way of getting around them.