| Why? Why? Why? |
|
|
|
| Thursday, 15 September 2011 06:35 |
|
While working at a former employer, we were required to take a series of courses to help us all with inter-personal skills. In one of those classes we were encouraged to keep asking "Why?", at least three times, whenever we were discussing an issue and felt that we had found a root cause. Why, you may ask? (OK, there's 1!) The idea is that by continually asking "Why?" we may uncover a deeper, more basic issue that needs resolving. Getting to that deeper level may solve more than just the obvious problem. Since that class I have tried to apply that concept to application development. It has some obvious applications as it relates to discussing requirements with users. The more you as "Why?", the more you understand the processes used and the core reasons for those processes. Too many people, when asked how they do their job, will tell you something like: "I take a 1 and a 4 and a 6 and a 2 and a 3". OK, what application is this? I suppose the answer is "pretty much any". Getting to the root of how things are done and "Why?" makes for a better application. At that same company there had once been an application written for the marketing department so they could extract account information from an order history database and use that to send catalogs to those customers. The order history information resided across two separate boxes. The application designed required the marketing department to sign on to each box when steps were required to process data from that box. This meant switching back and forth between systems several times before a coherent list could be achieved. This became too cumbersome and confusing for the users and, after a while, they reported to IT that they were too busy to use it, could IT do the extract for them? After several years of IT taking over that process, they re-wrote the application, but failed to note the underlying issue: the system was cumbersome. The new application was better than the old, but still required the users to jump back-and-forth between systems. Again IT was asked to handle the extracts because marketing was too busy. The next time around was my turn. Apparently I asked "Why?" enough times. Instead of having the users jump between systems, I setup a single interface to the application on one of the systems. There would no longer be any question as to which system they would need to access. From their perspective, there was only one place to go. Data needed from the other system would be retrieved using DDM and data would move "under the covers" to its desired location. Now it was simply a matter of moving from step 1 to step 2 and so on. The end result...no more IT involvement.The problem wasn't that marketing was too busy, the previous systems were too cumbersome and confusing. Digging a bit deeper uncovered the root cause and made it possible to solve. Whether the questions are "Why?" or "How?" or "When?", keep asking those questions, even after you think you have the answer. You never know what other, more basic issues you may find. |



