Treat Your Customer As A Business

This is an attempt at making requirements elicitation more efficient and to help get the bigger picture. Software, whether it is explicitly said or not, makes an impact on the business it is being used in. Value of the software is driven by that magic number provided by the Return On Investment (ROI). So, even if the customer is an individual treat him/her as a business. This can bring out the standing and significance of the software in the business.

What business are we talking about?

A software is typically looked at as a solution to a problem. This problem lies in its own problem domain which lies in the business. The business involves much more than your customer. It involves your customer’s customers, your customer’s vendors, shareholders, other stakeholders and of course your customer’s competitors. A business also plays are role in the entire supply chain. A business interacts with its customers, interacts with other businesses, probably with customers of its competitors. A business is a system with other subsystems in it, in which people are involved. Any software, whatever its scope, used in any part of any subsystem has the potential of making an impact on the entire system and eventually making an impact on the supply chain. If the software does not make a difference to the entire system, then why invest in it? Accounting department of a company can want an accounting software. But if using it does not affect the business of the company, is it really useful? Meaning of usefullness can change when you consider this business.

The business gets its ROI only when it can leverage the software to improve its standing in the entire supply chain. This can be direct or indirect. This business is a different animal than your customer. It is affected by more factors, it runs under more restrictions and it also affects more factors. To be able to get a handle on these factors, it is imperative to understand and treat your customer as a business.

What factors are we talking about?

Business, being a generic term, lets look at its generic factors.

Localized Optimization

The software affects the peripheral businesses or subsystems, along with the problem it is supposed to solve. A manufacturing unit can improve efficiency of the production department, however, this efficiency affect the business only if it propagates through the delivery systems. Sometimes, an improved production department can stock up the inventory system which can turn into a cost centre. The production efficiency is also only as good as the efficiency of the business providing the raw materials. If this is realised earlier in the stage appropriate solutions can be identified for the possible problems caused by localized optimization.

The real benefit lies in overal optimization, which looks at the bigger picture and finds solution in the bigger picture. This factor can help us in tying features of the software to benefits to the business, without the middlemen of departments or localized cells. Somehwere there also lies the answer for ROI.

Current Investment

A business inherently involves people. With people come their skillsets, their ability to learn and their questions. Software is not only about development, it is also about training, it is about making the users use the software in a right way. This can happen only if their skillsets are considered. The business perspective highlights this factor which is missed a lot of times.

People are a form of current investments. There can be many others like using existing real estate, expertise and even softwares. A software initiative can consider to use them instead of requiring new investments.

Growth and Dynamics

A business wants to grow, wants to scale up, wants to do more things. The software should not be an impediment. There is no way of predicting future requirements, but the software design can include provisions for growth and scalability. Website for a newspaper, that has a thousand readers today, but expects five thousand in future, should be able to handle this scalability. An overhaul of the website for this purpose can turn about to be too expensive. This can be achieved by querying the roadmap or vision or goals of the business.


Last but not the least, a business operates under a variety of restrictions. Timelines, financial budgets and even the market trends factor into the various tasks that a business carries out. These restrictions percolate to the software initiative. Eventually, each of the restrictions on the software project are born out of some real-life business restriction. This realization can help us understand the impact of breaking any one of them. It can make us look for a better solution that can comply with all the restrictions. If complying with all is not possible, it can at least give us time to prepare for the eventuality.

Still Be Personal

Treating the customer as a business sounds impersonal. Being personal does not mean involving personal problems, but giving personal attention to the customer. Labelling the customer in a category of other customers and giving a generic treatment is impersonal. Every customer, every business and every project is different. Realizing this, treating them different and giving them personalized solutions is being personal, and this can happen only when you can deliver something that brings in positive results for the entire business. And this can happen only when you treat your customer, not as an individual, not as a group, but as a business.

Technorati tags:

Copyright Abhijit Nadgouda.


Software Development Is Like Running A Restaurant

Software development is alien to a lot of people and explaining it in technical terms really makes it worse. So, we use metaphors. Lidor Wyssocky says it is like a broken telephone. And there have been many more attempts, to compare it with the construction industry with similar roles – architect, designer, developer (?) or manufacturing. Here is my attempt.

Software Development Is Like Running A Restaurant

This is the closest metaphor I can find today. To serve the customer that satisfies his/her needs, to provide tasty servings that are unique enough to make you standout but still within the realms of expected quality and standards is what we both do. It requires a delicate balance of creativity, engineering, understanding of the customer’s needs and other constraints like time and budget.

The waiter has to not only provide the menu but also gather what is it that the customer is looking for. Most of the times the customer does not what to order because he is not familiar with the culinary skills. It is upto the waiter to get the information, and help the customer choose a course. The course is split into parts and include the condiments like wine or starters are part of the order, they are the ones that complete the experience.

Once the order is taken, it has to be given to the kitchen so that the chefs and use their knowledge and skills to work on the order and create something that will satisfy the customer. There should be good information flow and collaboration between the dining area and the kitchen so much so that the customer feels that they are one and the same. The chefs have to be careful to select the right ingredients and the right combinations and the right proportions. Any change in this will cause a change in experience to the customer. However, the chefs cannot have all the time in the world, they have to serve before the customer gets frustrated waiting for the food. If the customer is hungry it might call for a different order or an expedited preparation. The decision involves not only the chefs’ skills but also the needs and constraints of the customer.

In the kitchen it is a different ball game for the chef. He has to design the dish, along with managing and motivating his team to complete the dish in time with a certain quality. This calls for samplers, tasting (or testing), good people management and good communication. Typically the kitchen ends up serving more than one customers which requires good estimation and scheduling skills.

Sometimes it makes sense for the chef himself to come up and talk to the customer. A lot of times problems raise their ugly head, like lack of seating or local problems like loss of electricity or disasters in the kitchen. The restaurant needs to have a good manager who can handle these situations and keep the customer abreast. A good restaurant will like to take the customer’s feedback and suggestions, and factor them in their improvement. Unless this experience is good, the customer is not going to revisit the restaurant or suggest it to his colleagues or friends.

Last but not the least, it is important for the restaurant to realise that every customer is unique. The same course need not satisfy all the customers, the restaurant has to consider and treat every customer individually and serve individually.

All this has to happen while making sure that the customer does not feel that he has been handed an expensive deal. The restaurant should still keep making money, and hopefully good profit so that some of it goes back in improvements of the restaurant and stay updated to the trends. The restaurant has to, in the background, make sure to manage the raw materials and manage the vendors.

And you see all kinds of restaurants – from the five star ones where there is a hierarchy of waiters to the ones who are affiliated to hotels and lodges to the three star ones, the Thai, Italian, Mexican and such specialized ones to the mass caterers to the diners to the ones that are part of a food court in the malls to the ones who give take-aways to the ones on stalls on the road.

It Is Still A Metaphor

Having said all this, running a restaurant is still a metaphor. The biggest difference is that the software development is about automation that is expected to serve for a longer time. This is what makes it complex, it is expected to serve for a time in which the customer’s needs and requirements keep changing.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Activity Centred Design

Don Norman proposes activity centred design as a better approach for designing. The logical methods of organizing into taxonomies and classifications does not support activities, which is what users carry out while using software.

Taxonomic structures are appropriate when there is no context, when suddenly needing some new piece of information or tool. That’s why this structure works well for libraries, stores, websites, and the program menu of an operating system. But once an activity has begun, then taskonomy is the way to go, where things used together are placed near one another, where any one item might be located logically within the taxonomic structure but also wherever behaviorally appropriate for the activities being supported.

Provide The Context

However it is unfair to say that logical reasoning is the culprit. It is an oversight on the part of designers. It is important to realise that users carry out actions on a piece of content after it is discovered. Taxonomy is very effective in providing navigation and discoverability of content. However, once found, the software should provide the context to the user. Supporting the activities is part of providing the context. The context is a direct result of the purpose of the user to use the software, visit the website, use the car dashboard or visit the city library.

Once the purpose is established, the context(s) can be identified. Although it is entirely user centric, more factors contribute to the context. If it is the software, then the layout design, the usability design, the usage patterns and more importantly tracking the usage history are part of providing the context. Some of this can be gathered when the requirements are being identified, and some has to be built when the software is being used. Usage patterns can be developed for certain users and corresponding contexts can be provided.

The Desktop

Will it help if the desktop is activity centric rather than application centric? How many end users want to know and want to be worried about installations and uninstallations of applications? The common man uses computer to carry out activities. Each type of the user has to carry out different activities, the home user, the employee, the student, the teacher, the developer, the marketing personnel – all have different use of the computer. Why is the desktop same for all of them? Why is the desktop not engineered according to their activities?

A solution is to change the interface – the desktop manager. It should carry activities like browse the internet, check email or write a letter rather than shortcuts to applications. This tells the user to carry out his/her tasks rather than start and close applications. The activities and underlying tasks can vary per user.

The challenge here is to take something as generic as a desktop manager and specialise it for a user, and still stay generic at the core. This requires deep understanding of the users types and their possible activities. It is also important to not limit the user to certain functionalities, but to be flexible so that it can be customized per user.

Technorati tags: , ,

Copyright Abhijit Nadgouda.

Requirements Are Important

“Requirements are for you, not for me!”, blasts the CEO at the software provider. “Don’t waste my time on it, and don’t charge me for it. Just give me what I want.”, he continues while walking out of the meeting. Well, not exactly, but I have come across this more than just a couple of times.

Most of the times businesses decide that they want to start using a software because they think that it will solve their problems. However, the problems are only the symptoms. It is important to gather more information so that the diagnosis can be successful and the right cure can be proposed. Especially in today’s age, softwares are not just adopted by businesses, softwares become integral to execution of the business processes. However, the software can provide the perceived Return On Investment (ROI) only if the automation targets not the problems, but the root causes of these problems. To be able to do that it is imperative to gather more information – which is the requirements gathering.

Feature-driven Selection

Usually the decision to use a software is reactive and not proactive. This ends up being a deadline-was-yesterday project and software tools selected are mostly feature driven and not requirements driven. As an example, there are many Content Management Systems (CMSs) available today provide comparable features. Just because a CMS provides an article management system, it does not mean that it can be applied to every newspaper publications. There are various factors within the domain of article management system like workflow, flexibility of the workflow, its maintainability and more that determine the right choice.

Feature driven selection usually ends up in either the tool not being flexible enough to satisfy the requirements. Or the customization costs are so high that the budget overflows. In either case, it is termed as a failure of software engineering. The success of software engineering starts by idenfying the requirements.

As Content Management author and consultant Gerry McGovern says, “I’ve seen so many organisations that have gotten burned because they didn’t spend the time to really figure out what they wanted.”

Requirements Represent Your Business

No business is similar to another, nor should be the solution. Two businesses can work in the same domain, be of same size and be located in the same geographical area. They are still different, because there are simply too many factors that profile the business. It includes the business vision, the staff and its skillset, the budget and probably many more. For the same reason, a software solution applicable to one business cannot be copied and pasted onto another. If it is, then it will not provide the maximum returns, sometimes making it a complete failure.

Requirements represent your business and domain and make it unique. Only the requirements identification can provide what the business needs and in effect the right solutions.

Requirements identify two distinct pieces of information that provide an answer to the question – What to do?

  • the existing processes and system of the business (as-is)
  • the future processes and system (to-be) that encompasses the solution

The software engineering is an exercise of transition from the as-is model to the to-be model and provide the solution. If the as-is and to-be models are not identified then the software project can end up in a wild goose chase.

Requirements are usually born out of two sources:

The Business Vision, Business Rules and Constraints

These are usually long-term requirements which are defined when a business is established. Businesses have vision and rules that work as guiding principles and in the process impose a way of working. The business constraints are more distributed in nature, and can change with time. Some examples of such requirements are:

  • The business has to target markets in multiple countries to be able to achieve its vision.
  • The business is geographically distributed and requires communication tools within the branches.

Current Problems

These requirements represent the current situation, and hence the requirements can be short-termed. However, they usually indicate towards some long term root causes. In such cases it is important to look beyond and identify why the current problems exist. Usually the impact is on the underlying processes.

  • The changes in the company are so dynamic today that we are not able to communicate all of them to our customers, other branches or other stakeholders.
  • The maintenance work going on certain machines makes it difficult to complete the work in the scheduled time. Do we need to change the schedule?

These point towards certain underlying issues. This may be because the environmental factors have changed, and the business has to react effectively. It is also possible that these problems are being caused by certain constraints and breaking these constraints might provide the solution.

Future Requirements

The irony of requirements is that we try to specify them, but they change with time. So does the business, and the rules and possibly the constraints. It is important to realise that businesses are dynamic and solutions should be flexible enough to accomodate them. It is not possible to envision everything, but reflecting on possibilities in the near future can help decide flexibility of the software tool that should be used.

A Piece Of Software Is Not A Solution In Itself

A software package itself is not a solution. The solution is in its application to the business and its appropriate usage. If there are problems in the underlying processes, then only the software will not help. The real solution might involve Business Process Re-engineering so that the root cause is eliminated. However it is difficult to determine if the requirements and the root causes are not identified.

There are various ways of requirements gathering but that will be another post in itself. Requirements are not for the software, but for the business itself. Only after defining the requirements can the solution be defined. Otherwise it might head for just another failed software project.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Theory Of Constraints And Software Concerns

Unlike a lot of others, I was introduced to Theory Of Constraints (TOC) by the business novel

Necessary But Not Sufficient

and was instantly addicted to the revolutionary approach, an output of exceptional work by Eliyahu Goldratt.

The Theory

Theory Of Constraints (TOC) is, at its basics, a problem solving approach that focuses on the constraints or limitations involved. Anything that we are part of today – work or family or organizations – involves multiple factors. There is a continuous effort to get better at it. The apparent approach is to maximally use the resources, change all the variables so that the betterment is optimum. However, the working is usually limited by not all, but some factors – the constraints. TOC makes this more explicit by approaching the solution by looking at an entity through its constraints. A business has to work under constraints – monetary, time, workforce, competition and probably hundreds more. To bring about an improvement, the effort should be directed towards the constraints.

At its center is a set of tools called Thinking Processes, containing causality and necessity as two basic elements. The revelation of cause and effect can identify root cases of undesirable effects (UDEs) and help us answer the three important questions:

  • What to change?
  • To what to change?
  • How to change?

Consider the following excerpt from the video transcript of introduction to TOC“:

Just to give us a couple of very simple, trivial examples. If we talk about causality, it might be as simple as “if I touch a hot stove, then I get burned.” That’s our understanding of reality. And if we want to change it, then we may look at some of the assumptions and alter the situation that says, for example, now “if I touch a hot stove and I’m wearing a pot mitt, then I don’t get burned.”

Instead of one reality, we have what we’ve put into place that alters that reality. This is utilizing this cause and effect.

Had we expressed it more in the realm of necessity, it might appear that “in order to avoid getting burned, I must not touch the stove.” Why? “Because touching a hot stove might burn me.”

Thinking Process provides following tools for a systematic approach:

  • Current Reality Tree (CRT): to identify UDEs and their root causes
  • Clouds: to resolve conflicts that causes UDEs
  • Future Reality Tree: future state of the system after some actions are identified
  • Negative Branch Reservations: possible negative ramifications of actions chosen
  • Prerequisite Tree: a pre-plan which identifies the intermediary objects required and possible obstacles
  • Transition Tree: details of the action to be taken

This is very analogous to what my friend says about using Business Models for as-is system, to-be system and the transition.

TOC And Software Industry

TOC has been applied to multiple industries like Production, Logistics, Accounting, Marketing and many more. It has resulted into amazing processes like Drum-Buffer-Rope (DBR) that lead to synchronized manufacturing or throughput accounting or Critical Chain.

I want to tackle application of TOC to software industry in two different ways. One is impact of TOC on software concerns to provide maxium ROI. The other is use of TOC in managing software processes.

ROI From Softwares

Scott swirls his brandy and takes a taste. “When does a new technology bring value?” He starts with a rhetorical question. “We expect that a new technology will bring benefits, when and only when, the new technology diminishes an existing limitation. It is simply common sense.”

“Maybe to you. What do you mean?”

“If the new technology does not diminish any limitation whatsoever, there is no possible way in which it can bring benefit.

This is an excerpt from Chapter 12 from the book that I mentioned before.

TOC tells that an organization can benefit if its constraints are targeted and resolved. If a software has to be beneficial, it has to follow the same way. The key benefit of software is automation – automation of processes. TOC, through its focus on constraints, which are part of processes in an organization, typically leading to BPR. Use of TOC in Business or System Modeling can lead to right automation of these optimized processes which will provide maximum benefit to the organization.

TOC In Software Engineering

Software businesses can use TOC to improve by overcoming its constraints. Just like every other business, even a software business has limitations. TOC can be used to identify them and act on them to provide improved processes.

Software solutions require more and more out-of-box thinking, solutions that are not run-of-the-mill but innovative and original. TOC can provide answers to the basic questions leading to an unique and effective solution. Use of TOC can also provide pragmatic solutions in project management.

Each of these deserve individual discussions on them, which I hope to follow up with.

There might be many more applications of TOC in software industry. There are already some softwares out there which provide TOC solutions. Let us look for more usage of TOC in software industry for the benefit of both, the software users and creators.

Technorati tags: , , , ,

Copyright Abhijit Nadgouda.

The Business Interface

The inventory manager sat down to look at the day’s reports. To scrutinise further, he went to the computer screen so that he could get some detailed information about aluminium pipes, their raw material. Once he logged in, he tried to get information about the quantity and quality of the aluminium pipes received. To his surprise, the screen prompted him to enter the inventory ID number; in a baffled state he tried to look around but failed. On speaking with the IT engineer, he came to know that there was a user manual in the shelf which would provide the ID number for aluminium pipes, that had to be used.

As a software engineer I realise that the software application had to maintain an internal ID for every raw material; and I also realise that it is only the software application that needs it, not the inventory manager. This is a classic case of wrong design – where the user was forced to identify an item the way the software identified it. Shouldn’t it be exactly the opposite way? If the software used aluminium pipes for identification, it would be much more convenient for the inventory manager and would have saved him effort and time. I am sure there would be cases where only the raw material name might not be enough to identify it. However it can still be combined with other pieces of information that the inventory manager knows, the way he identified in the real world. This is what we call Business Interface.

The rule of thumb is to hide entities created by the software for itself, that don’t exist in the real world, from the user. Though the software internally has its own system, it should be appreciated that it is being used in the real world, by real world people.

It is quite possible that the same thing is called differently by different users. To be able to understand these details, it is imperative to identify all the different types of users that will interact with the software, including the administrators. The information required by the software and the output given should always be in a language and terminology that the users understand. This not only makes it more usable, but also requires the user to learn minimal things to use the software.

Technorati tags: , , , , ,

Copyright Abhijit Nadgouda.