What could be a better way to start “Developing and Writing Use Cases” training session than to identify the participants as “Actors” and asking them to set their “Objectives/Goals” from the training session! Prof. V. K. Garg must have walked this path so many times. It was an excellent way to emphasize the fact how the IT consulting should be “User” centric than “System” centric. He established the context through the set of objectives/goals defined by the actors. Examples of how only 10% of the functionality provided by American cars was used 90% of the time and how this analysis helped Japanese car builders to reduce the cost and still satisfy the users was very helpful to highlight the user centricity. The same is true with the most widely used word processing software!
Most of the times, IT people “gather” requirements and build solutions. Generally such a development happens around system/technology centric which can be termed as inside out architecture/design. The user centric system development shall be a value proposition which is termed as outside-in architecture/design. It is very important to identify the end user of the system. A system built considering the viewpoint of the wrong end user focus shall be of no use.
Prof. Garg’s case study of a pharmaceutical company was very adequate to explain the point. After going through the historical data, a pharmaceutical company discovered that accounts department was not able to produce travel related expenses of the medical representatives (MR). After series of interviews with accounts department, the company arrived at the conclusion about lack of data related to their medical representative’s (MR) visits. The authenticity of the data was also in question. It was then discovered that in most cases MRs fill logs at the month end to somehow meet the requirements. Series of interviews with MRs highlighted the nature of the field job, more time spent on the field than the office and lack of connectivity on the field. After lot of analysis it was decided to have a connected system to capture the MR logs. These logs would contain date, time, location, doctor’s name, travel expenses etc. To avoid the delay in recording the data, it was also decided to give hand held devices to the MRs. It took some time for the company to implement the system. Out of curiosity and some force, MRs got hooked to the system. They could show off their hand held devices to the doctors and others. (One of the hidden agenda of the company to advertise their tech-savyness got satisfied!). Soon this system was seen as a burden by MRs and the response started fading. It almost went back to the original problem when the company decided to reinvestigate. This time they interviewed MRs and discovered that there is no sense of “ownership” or “belonging” amongst MRs towards this system. This system was seen as “spy” on MR. Further investigation revealed that it does not provide any helpful information to the MR. Few MRs reported that along with the logging the system should have details about a new products. Based on the notes of the last visit to a doctor, the system could prompt about relevant product information. There could be added flavors as doctor’s date of birth. After implementing the relevant requests, MR started using the system effectively which satisfied them as well as accounts people.
The story shows that incorrect objective taking a prime importance severs no purpose. It highlights the fact that main goals should be separated from the sub goals. In the above scenario the main goal should have been to empower the MRs, instead the initial implementation had system centric goal of capture the logs.
Prf. Garg then walked us through the intricacies of use case development starting with glossary, steps to build scenarios till the documentation. The actual case study carried out in the second half and the preparation of the documentation for the same was very helpful.
Towards the end of the training Prof. Garg touched very sensitive topic about estimation. He cleared the myth around using UCP, FP and other techniques by highlighting the fact that all these techniques give only the size of the project and not the time estimation. Every company should derive their Project Development Rate (PDR) for various technologies based on the historical data of the actual project execution time. Many companies’ CMM level 5 status was revoked because they had not derived PDR. He highlighted that almost 95% of the companies are using FP because of the availability of ISBSG data. It should be noted that many end users have started to size their projects on their own (like the tenders in the engineering world) which forces the bidders to sharpen their PDR to win the case.
