I started off my career in a product development environment; I sat behind a desk all day every day writing code. The only work related discussions I ever had to have was with the CTO (Chief Technical Officer). He told me what to do and how to do it. I was incredibly lucky to have fallen under his wing, because he was an incredibly talented developer and manager with years of experience. Not only did I learn a lot from him but I could always count on the fact that he always had answer to any problem I was facing.

However, in retrospect I realise I was working in a sheltered cocoon. Wanting to explore other opportunities I later moved on to a software consulting company. Soon after having started as a software consultant, I realised that I was in over my head. Interestingly enough, the technical challenges I was facing were relatively trivial compared to what I was previously doing. At the time I couldn’t for the life of me understand why I was struggling. Through experience, I later learned that the problems were not technical in nature, but they were rather social engineering problems i.e. I wasn’t in charge of managing the people on the project and even if I was, I wouldn’t have known how to manage them.

Every software project will always be made up of three major components:

• Problem: at the core of every project is an underlying necessity for a problem to be solved.
• People: there are expectations that are set out in every project by the stakeholders. These expectations are essentially agreements as to how a solution will be developed for the above problem to be solved. The stake holders involved in setting out the expectations are mostly made up of two crowds of people.
  • People requesting the software solution.
  • People providing the software solution.
• Solution: once the expectations have been set out, they need to be met by the software developers i.e. developing the software that solves the defined problem according to the expectations that have been set out.

Most inexperienced software developers and business/sales people often believe that developing software for a customer/investor is all about the technical solutions that need to be implemented to make the customer happy. These kinds of people often accept the word of the customer as the word of God i.e. they walk around saying “the customer is always right” or the “customer is King”. Personally I believe they do this because they either lack the experience, a backbone and/or foresight. Hence they are “yes people” that often say yes to whatever the customer asks for, no matter how ridiculous/incorrect these requests may be and without considering the big picture. Hence they become a puppet being played like a ping pong ball by the customer’s stakeholders, and thereby ultimately ending up with a failed project on their hands.

Part of the reason this happens is because as kids, most of us are brought up to think that our superiors (parents) are always right and that they have our best interests at heart. When we enter the working world, we tend to see our managers and/or customers as our new superiors because they’re paying paying us. Therefore our natural instinct tells us to believe the same principle applies to them i.e. that the customer is always right. However, in the real world a consultant is hired to recommend and provide solutions, not to just simply take instructions. Simply put, the customer is not your parent.

Furthermore, as the name implies, each stakeholder has their own individual interests and incentives that motivate them. Whenever there are a multitude of varying interests, you can bet that there will always be conflicts of interests. Hence it would be foolish to allow the stakeholders to control the expectations and proposed solutions, thereby controlling the project itself. Your job as a consultant is to understand the needs of the businesses, the needs of each stakeholder, what motivates them and what their incentives are, so that you can gather enough information to make your own proposal for a solution. The consultant must be the one in the driver’s seat of every project.

Simply put: the consultant should never ask what needs to be done, but instead tell the customer what needs to be done and how it will be done based on the problem at hand. This means that at least 50% of the consultant’s work involves setting the right expectations, thereby requiring social engineering to be applied before a single line of code is written.

So what is social engineering in the context of software development?” Here a few points on this:

• Understanding the customer’s business:
  • A customer will often request for technical solution to solve what is often only a simple operations problem. For example; in a warehouse they may request for software with a simpler and more intuitive process flow to be used by employees handling stock on the warehouse floor. Doing so may increase the productivity by 10-15%, but given the fact that according to statistics a warehouse worker spends 50% of their time walking to different locations, the more serious problem at hand are the long distances between the bin locations, rather than the process of data processing on a mobile device. In this example, software cannot solve the problem of the physical distances between bin locations, instead it can only optimise the existing processes which may be inherently flawed. As a consultant you need to understand these nuances and draft your proposal accordingly.
• ROI (Return On Investment) & Budget: keeping in mind that that the primary aim of most businesses is to make money, the need for most software projects comes down to a necessity to optimise current processes by cutting costs and increasing productivity. Hence, any recommendations should be applicable to the customer’s business needs i.e. do not make recommendations to develop features just because it would be fun for you to develop them.
  • ROI: any feature to be developed, needs a cost associated with it and an ROI to be proven i.e. the customer is paying X amount to have this feature developed, therefore how much money will they be saving and how long will it take before the feature is paying for itself?
  • Budget: you also need to keep in mind that although you may be offering a great solution and a great ROI, the customer you’re proposing the solution to may not always have the budget to invest in it. This applies to any sort of business. For example, someone may present you with a bargain to purchase a block of flats that you can rent out and get a fantastic ROI, but if you don’t have the budget to make the investment, it really doesn’t matter how great the solution/business opportunity is. Hence, you should never be shy to discuss the budget with a customer upfront. This will prevent you and the customer from wasting each other’s time.
• Understand your audience: IT staff for example, are more concerned with the network and IT infrastructure of your proposed solution than the usability or how it improves the business. Finance people are more concerned with the costs and ROI than with the actual features being offered by your solution. Operations people are more concerned with efficiency of the solution rather than the costs or technical architecture. Finally, end users are more concerned with the features and usability of the solution than with any of the above. You need to pay careful attention to who you are talking to at any given time as well as what you say, how you say it and what questions you ask.
• Managing expectations: customers often do not understand the implications of developing software, such as the amount of effort and time that will be required. Based on that you should not allow the customer to dictate how long something should take and how much effort will go into it. As a software developer, it is your job to inform the customers of the above and be firm about it. They must accept your estimations or go somewhere else. Needless to say that the estimations and expectations you set should be reasonable and some flexibility (within get reason) on your end will prove to go a long way.
• Getting paid: finally you need to worry about when and how much you will get paid. You will come across many customers that expect you to work for free with only a promise or a maybe of getting paid. Therefore it is imperative that you address this question with the customer right from the start in order to set the right expections. Also keep in mind that many customers that deal with software consultants are often under the impression that they are buying software, which couldn’t be further from the truth i.e. they are not buying software, they are buying your time and expertise which you need to make crystal clear to them right from the start.

To summarize: a software project is more than just someone telling you what feature to develop and then coding it. Therefore it is imperative that you understand the social engineering aspects so that you can manage the customer instead of the customer managing you. With the above said in mind, half the project is performed in boardroom discussions and over emails and phone calls, not just behind a computer simply writing pretty code.