Month: December 2018

How do I manage Computer Rage?

Posted on by Paul Kolozsvari in Management, psychology, Software

Before we get into this topic let’s first establish what Computer Rage is exactly. It’s essentially anger that turns into uncontrollable rage over a malfunctioning computer or any other electronic devices . This results in people verbally or even physically abusing a computer. According to Wikipedia article (and many other sources which can be verified with a quick search on the Internet): “In 2009, a survey was conducted with British computer users about their experiences with computers. This survey found that 54% of respondents reported verbally abusing their computers, and 40% reported that they had become physically violent toward their computers. The survey also found that most users experienced computer rage three to four times a month“.

This may be bit of a sensitive topic for some, but if you’re planning on a long and prosperous career in the software industry or any other industry that requires you to use a computer on a daily basis, you or someone you know will at some point experience Computer Rage. Hence it’s probably a good idea to give it some thought and if you’ve ever experienced it, it’s an even better idea to try and manage it for your own mental health and those around you.

If you were to to go according to pop psychology, you would think that any one experiencing Computer Rage is a psychopath that treats other people in the same way that they would treat a computer when experiencing Computer Rage. Pop psychology even tells us that before dating someone you should first see how they react to working with a non-functioning computer or a slow internet connection. Personally I don’t believe that you have to be a psychopath to experience Computer Rage. Based on the above statistics, I cannot believe that 54% of British computer users are all psychopaths. There must be something else to it.

I’ve searched far and wide for information on Computer Rage and how to manage it. However, I have to say that aside from statistics and basic pop psychology I haven’t really found much value in the materials I’ve read thus far. A this point I have to be honest and say that over the years I have experienced Computer Rage on a few occasions, but fortunately with age and experience I’ve started to manage it much more effectively. So in other words, this advice is coming from someone that has first-hand experience with Computer Rage.

As a disclaimer, I’d like to add that I’m not a psychologist nor a doctor, but instead this is just simple advise from a software developer that has spent a minimum of 8 hours a day in front of a computer for over a decade and has occasionally experienced Computer Rage just like the other 54% of British computers users cited in the study.

Let’s look at some of the reasons that cause Computer Rage:

  • Impatience & unmet expectations: Impatience is an obvious one, but it’s important to think about what causes impatience. Suppose you’re on Holiday and you have all the the time in the world to relax and enjoy your life. There is nowhere that you need to be and there are no deadlines. You’ll probably notice that you and everybody else around you that is on holiday is driving slowly. Suppose you get to a traffic light and there’s one guy in front of you who doesn’t notice that the light has gone green: chances are that you won’t lose your cool but will remain calm and relaxed. Now imagine that you’re back at work and you have to catch a flight for a very important meeting with a customer on the other side of the country. If you miss the flight you miss the meeting and you’ll probably lose the customer. Now imagine you’re running late to the airport and imagine the exact same scenario where the guy in front of you at the traffic lights doesn’t see that it’s gone green. Chances are you’ll lose your cool, start sweating, maybe start cursing and hoot at him. The difference between the two scenarios has nothing to do with the guy not seeing the traffic light going green and everything to do with your expectations. In the latter scenario, your expectation is to get to the airport on time and get to the meeting. When people are driving slowly you realise that the expectation will not be met, which makes you impatient with other people and can lead to anger and even road rage.
  • Feeling helpless: Another major cause for anger and frustration with computers is when you feel helpless to change a situation. This can often happen when something goes wrong with your computer or software and you don’t know how to solve it. This can quickly lead to despair and generally feeling like your whole world is falling apart. Feeling helpless and despair will instinctively draw a fight-or-flight response from most people. Some people will start crying (flight response) while others will get angry (fight response) as a natural knee-jerk reaction to overcome the perceived threat they’re facing.
  • Lack of confidence & anxiety: A lack of confidence can lead to anxiety and anxiety can lead to a lack of confidence. This goes hand-in-hand with feeling helpless. A lack of confidence in your own abilities to troubleshoot an issue can amplify the feeling of helplessness and despair.
  • Existing stress: Working with computers on a daily basis can be stressful in itself. That coupled with additional external stress, either from your personal life or work politics can be prove to be overwhelming and turn into a recipe for disaster. There is only so much weight that one can carry on their shoulders and given long periods of time under heavy stress can make any one reach their breaking point. This can lead to irrational responses and Computer Rage.
  • Fatigue: Working when you’re tired can reduce your level of concentration and patience, which once again can reduce your ability to troubleshoot issues and therefore make you short tempered when things don’t go according to plan.

So here’s my advise for managing Computer Rage:

  • Psychological tips:
    • Manage your expectations: the first step to becoming more patient is to start managing your expectations and you do that by planning ahead. You know that the traffic to the airport will be bad, hence you should probably leave earlier. If you do end up running late, you should realise that it’s your own fault and just surrender to the impatience and anger you’re feeling. This translates in a similar fashion to slow and unresponsive computers: you should start planning better for your deadlines and keep in mind that in the tech industry anything that can go wrong will go wrong. If you’re going to leave your work for the last moment, you will quickly lose your patience with the computer when it doesn’t behave the way you expect it to behave. Furthermore you should lower your expectations of your computer i.e. you should expect the computer to be slow at times.
    • Avoid working when you’re tired: I know that there are many companies that push for ridiculous deadlines and actively encourage workers to pull all-nighters. But the truth is that working while you’re tired is not in any way productive. Aside from many other negative side effects which I won’t get into in this post, you have to also keep in mind that you will be short tempered when you’re tired. I have never in all my years seen anyone maintain the same level of patience when they’re tired than as when they’re fully rested. Therefore working when you’re tired will without a doubt cause some Computer Rage.
    • Avoid working on an empty stomach: First of all, your brain needs to nutrients in order for you to think properly. If you’re hungry and come up against an issue when working, you will not be able to think clearly and troubleshoot the issue efficiently when you’re hungry. This once again can lead to feeling helpless and and ultimately even anger. This is known as being “hangry“. The reason for it is that not eating will lower your blood sugar levels and according to psychologists “Hunger and hypoglycemia (low blood sugar) are primitive signals known to set off the stress response in a person“. For some people this stress response can escalate into anxiety, depression, anger or all three. This is an evolutionary mechanism designed to put us (and animals) into survival mode in order for us to prioritise finding food. Therefore it is important to not work on an empty stomach if you want to avoid being short tempered when things do don’t go according to plan.
    • Don’t drink too much coffee: There’s a joke in the software industry that developers are machines that convert coffee into code. This may be true because coffee is a stimulant that gets your brain going, but at the same it can escalate anxiety which can turn into anger and being short tempered. So try avoiding getting over caffeinated.
    • Close your eyes, take a deep breath and count to ten: Even if you’ve put all the above measures into place to avoid Computer Rage, there will still be times when your computer will cause you to get angry. For example, the computer could become unresponsive because it is busy processing or perhaps trying to connect to a resource over the network. If you’ve ever run on a treadmill or done the plank exercise, you’ll notice that looking at the odometer or timer can be an excruciating experience where 30 seconds can feel like a life time. You will have probably come to realise that looking away from the odometer or timer and thinking about something else will make the time go faster. The same principle can be applied to dealing with unresponsive computers. If you start feeling irritated, try closing your eyes while waiting for the computer to become responsive. You could also try taking a deep breath and counting to ten while keeping your eyes closed. Nine times out of ten the computer will once again become responsive by the time you’ve opened your eyes.
    • Take a walk: As a last resort, if all else fails and you can feel the onset of anger, you should get up from your desk immediately and take a walk. While being away from your computer try thinking about all the possible causes of the computer malfunctioning. You will probably come up with a few ideas within seconds at which point you’ll be tempted to go back to the computer to try them out. Avoid going back to your computer before you’ve calmed down. Instead, carry on walking and come up with several more ideas. You can go back to your computer once you have a list of ideas and you’ve completely calmed down. You’ll also notice that as you become calmer, the ideas will start streaming in  i.e. your level of calmness and the rate at which you get new ideas are directly proportional.
    • Sort out other problems from your personal life: It is naive to think that problems in your personal life cannot affect your work life. The truth is that we are all human and if you have a personal issue, it can cloud your judgement and your ability to think properly while on the job. For this reason it is important to sort out your personal problems as quickly as possible so as to not affect your ability to work.
    • Practice silent leadership: It’s not always easy to be immune to drama and/or office politics happening at work, but it is important to at least try. The best way to avoid office politics is to practice “silent leadership“. There is a great deal of material out there on silent leadership so I won’t get into this topic except to say that silent leadership is essentially putting your head down and getting to work without complaining, arguing with other people or worrying office politics and drama.
  • Technical tips:
    • Don’t be cheap: This is by far the best and most important advise I can give anyone for preventing Computer Rage. If you’re a knowledge worker and especially a developer that spends at least eight hours a day behind a computer, then you simply cannot be cheap with your hardware. Development tools can be especially resource hungry causing a weak computer to be quickly brought down to its knees. Aside from the drop in productivity of using a slow computer, I can without a doubt say that it would be literally destroying your own mental health and maybe even your life in general. There is absolutely nothing worse than having to constantly wait for your computer to be doing something after every click. Given enough time working under such conditions it can literally drive you into a mental asylum. There are certain things in life that you could and should be cheap on, but a computer is not one of those things. I know that most of the times the companies normally provide you with their own computers to work on and many of these companies that are run by bean counters can indeed be very cheap on the hardware they provide you with. If that’s the case, do yourself a favour and go out and buy the best computer that you can afford. If it comes down to it, sell or downgrade your car if you have to, but purchase a fast computer i.e. your car costs you money while your computer is a tool that helps you make money.
    • Saving you work: One of the main causes for people losing their cool with their computers is when they’ve been working on something for an hour (or more) and all of a sudden something goes wrong with the computer where it freezes, blue screens or applications crash. This can easily lead to feelings of despair with people throwing their toys out the cot. This is in fact the easiest issues to solve by simply getting into the habit of continuously saving your work. Learn your keyboard shortcuts for quickly saving your work. If you’re coding for example, get into the habit of hitting the save keyboard shortcut after every function or line of code that you’ve written. If you get into this habit, you’ll end up instinctively saving your work without even thinking about it e.g. it will become like changing gears in your car, where you don’t even think about it you just do it.
    • Backups: I have personally seen people having meltdowns after documents that have somehow been deleted or their computers crashed without being able to reboot them. It goes without saying that the easiest way to prevent this from happening is to always have backups of everything using one or more of these options:
      • Source Control: You would think that every developer on the planet uses source control, but I have personally seen programmers with years worth of code just sitting on their laptop never having been checked into any repository. Seeing this blows my mind. Even if you’re a single developer working alone without having to collaborate with any other developers, it is crucial that you get into habit of checking in and pushing your code changes to the repository as often as possible. If something goes wrong with your computer or you lose it, you can simply check out your code from the repository and be back in business in no time.
      • External Drives: For very large files that may not be appropriate for source control repositories, I’d advise you to get into a habit of backing up these files to an external drive.
      • Restore Points: Start using  TimeMachine on Mac OS X and System Restore on Windows in order to create restore points. If anything goes wrong you can always restore your machine to a previous state. Personally I love using Apples’ Airport Time Capsule because not only does it serve as a wireless hard drive that I can manually copy files to, but it also performs automatic backups of my entire laptop every day while creating restore points for Time Machine.
      • Cloud Backups: Most operating systems nowadays have some sort of cloud backup feature whether it’s through Google Drive, iCloud, Microsoft OneDrive or even Dropbox. Get familiarised with these tools and save your most important files to the cloud.
    • Knowledge is power: The easiest way to overcome feelings of helplessness and despair when dealing with technical issues is to learn. This obviously doesn’t happen over night, but the more knowledge you have the more empowered you will be to overcome technical issues when they come up. So instead of getting angry and throwing your toys out the cot, you’ll be able troubleshoot the issue with confidence. Keeping this simple rule in mind can help when you feel the onset of anger.. Even if you don’t immediately know the cause of the issue or how to resolve it, you can at least start researching for possible causes and solutions before you lose your cool.
    • Task Manager / Activity Monitor is your friend: The easiest way to start troubleshooting an unresponsive computer is by using Task Manager on Windows or Activity Monitor on a Mac. Nine times out of ten, there will be an unresponsive application that is the culprit. Using Task Manager/Activity Monitor you can view which applications and services are being resource hogs i.e. taking up the CPU, RAM, handling heavy network traffic, or furiously reading and writing to the hard disk. If the application does not respond after a few minutes, you can quickly kill the process and restart the application.
    • Close apps you’re not using: This is all about setting up good habits. I have seen people running 50 or more applications and browser tabs concurrently on their computers. When the computer starts slowing down and becomes unresponsive they seem to be flabbergasted by it. It’s always good practice to try and limit the amount of applications and services that you’re running concurrently. This will free up your resources on your computer and provide more processing power and memory to the applications that are currently in use.
      • Browser tabs: you really don’t need more than a few tabs open in your browser e.g. email, search engine and two or three other web pages. For example, if you have 50 web pages that you’d like to go through, then you really don’t have to keep all of them open in your browser. Instead, rather copy and paste their links into a text file as a reference. When you’re done going through one web page close it and open the next URL.
      • Applications: Get into the habit of saving your work and  closing an application you’re not currently using. Not only does this free up computer resources, but it also makes it easier for you to navigate between the applications without constantly searching through all the clutter. This is essentially similar to having a clean desk because as they say “A cluttered desk is a cluttered mind.”
      • Background Services: On Windows for example, using Task Manager you should get into the habit of regularly looking at all the services that are running and the resources they’re consuming. On Windows for example; if there’s a Windows Service that is running and not being used, then stop the service and change its Startup Type from Automatic to Manual i.e. the service should only start when you manually start it instead of starting up automatically when the computer boots up.

These are all just some basic tips for avoiding Computer Rage and stress in general when working with computers. Keep in mind however, that simply knowing these tips will not help unless you practice them everyday.

Do project managers actually add value to software projects?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

Throughout my career I’ve worked with various types of PMs (Project Managers) and I too have managed many projects over the years. I’ve often pondered about whether PMs do indeed add value to projects or not. The simple answer is that I think PMs can indeed indeed add value to a project, but in my experience 90% of the time they just simply don’t. If anything they probably make the project go slower and bring about unnecessary complexity. Having said that, I don’t believe it’s any fault of their own. Personally I think this is caused by upper management assigning the project managers for the wrong reasons or there are other corporate politics in play that prevent PMs from adding value to projects.

So let’s start with a list of very wrong but very common reasons why a PM gets assigned to a project and how they end up adding little to no value:

  • Promoting the weakest link: Suppose there’s a guy on a software team called John and suppose that John has limited technical skills. This could be because he doesn’t have any talent for coding, or he’s lazy, or he isn’t analytical enough, or he writes horrible code, or maybe he simply doesn’t care enough about the company or project. When it comes to employees like John, upper management will have tried to place him in various roles in the hope that there’s something that he’s good. Unfortunately, John cannot code to save his life, and when given the opportunity to code, he creates more problems than solutions. They’ve tried putting John into an analyst role to gather and document requirements, but because of his limited technical skills he cannot translate functional requirements into technical requirements. Worse yet he doesn’t have any eye for detail, and misses a lot of important information when relaying information between the customer and the development team, which in turn can cause havoc on a project. They’ve tried putting him in a support role, but he ends up escalating almost all the issues to the developers without ever learning anything in the process. As ugly as it may sound the bottom line is that John is pretty much useless. So, what do you do with a guy like that when you’ve tried everything to increase his technical skills and the only thing that he seems to be half decent at is talking to people. Well, what often happens is that upper management will assign him as a PM on the next project. Their reasoning is that in their minds, project management is only about managing the customer, so John will definitely not be able to screw it up. Even if John does screw it up, project management can cause the least amount of collateral damage i.e. the developers will continue with their development and the project can still be a success.
  • Maximising billable hours: In software consulting companies it’s all about resources (people) and time. The more hours the company bills the more money it makes. Suppose you have two developers on a project and they communicate with the customers directly: any time spent attending meetings, phone calls and emails is often ignored i.e. it’s a loss to the company. Even if that time is actually billed for, you’ll only have those two people billing time. Therefore what many software companies do is to add as many people on the project as possible i.e. instead of having only having two resources on a project let’s add a PM into the mix so that he too can bill hours for attending meetings and drawing Gantt charts. This is the oldest trick in the book by any company that makes money through selling services. Lawyers often apply the same tactics: instead of getting one lawyer that can do everything, they will tell you that one lawyer specialises in one side of the law while another will specialises in something else, and you’ll need another to take notes, another to do research, and another to supervise the whole circus. In the software industry, it often happens that a PM gets assigned purely to increase the amount of billable hours instead of to actually manage the project.
  • Specialised project managers: many software companies hire PMs that have some sort of formal project management course under their belt and they assign these people purely into PM roles without any technical responsibility i.e. they’ll never do any analysis, design, development, or support work etc. The problem with this approach is that these PMs have no technical skills or engineering experience whatsoever. So if they ask developers for time estimates, they will take whatever the developer tells them because they don’t have any hands on experience to tell right from wrong. Worse yet, they might not even ask for estimates from the developers, and instead simply thumb suck the schedules and timelines. When deadlines are not met being met, the PM passes the buck by blaming the developers. Furthermore, when the developers try to explain a technical issue they’re struggling with, the PM cannot articulate those issues to the customer.
  • Glorified secretaries as project managers: many software companies are run by non-technical business people. For this reason, these business people often do not understand the work that the developers do, nor can they measure their developers’ progress. They’re often also not interested in the technical details regarding issues the developers are facing. What the business people do understand though are numbers. So what they often do is assign a PM for the simple purpose of capturing, keeping track and reporting back on costs and timelines throughout the project. At the same time, the PM is given limited authority. So when it comes to the technical staff not performing, missing deadlines and dealing with unhappy customers, this PM has virtually no power to do anything about it i.e. they might have the word “manager” in their job title but none of the technical staff report to them. In cases like this the PM is in fact nothing more than a glorified secretary that schedules weekly meetings to ask for progress updates, accepting anything the developers say without questioning anything. Thereafter the PM will update the Gantt chart and spreadsheets and forward them to the real manager who is not even involved in the project. This is a recipe for disaster because these kind of PMs end up being nothing more than shock absorbers for the developers thereby fostering  laziness i.e. the developers never have to face a screaming customer because their glorified secretary of a PM will take the hit, while at the same time the PM is not able reprimand them for non-performance.

For all the above reasons I believe that PMs add little to no value in most cases. However, I do believe that PMs can indeed add an incredible amount value under different circumstances.

Here are a few very good reasons for assigning a PM on a project and some strategies for maximising the value that they can add:

  • Reduce communication channels: the most important reason for assigning a PM to a project is reduce the number of communication channels between stakeholders. This really comes down to Fred Brooks’ famous quote, “What one programmer can do in one month, two programmers can do in two months.” The simple logic behind this statement is that the more people you add on a project the more these people spend talking instead of working. If you only have a single person on a project, then this person has no one else to talk to and therefore spends all their time working. If you have two people, they will spend a considerable amount of time talking to each other and consequently establish a single communication channel amongst themselves. Having three people means you have three communication channels between them. Having four people results in six communication channels. Hence, increasing the amount of people on a project increases the communication channels exponentially, which in turn reduces productivity. This is rule is known as Combinatorial Explosion and the formula for determining the number of communication channels is as follows: l = n(n -1) / 2 where n is the number of people on the project and l is the number of communication channels. Using the formula we can calculate the number of communication channels on a team of 10 people to be 45 i.e. 10(10 -1) / 2 = (10 x 9) / 2. As you might expect, in such a team, the 10 people will spend all their time talking instead of working. This being the reason why so many corporate environments have endless meetings without ever getting anything done. Smaller companies on the other hand tend to be a lot quicker and more productive. It’s in cases like these that PMs can be added to reduce the communication channels. By adding a PM in the centre of a 10 people team it will reduce the communication channels from 45 to 10 i.e. instead of each team member talking to every other team member, the communication becomes centralised by them talking only to a single PM.
  • Assign a PM with strong technical skills: adding a PM to reduce the communication channels is all good and great, but it will prove to be futile if the PM has insufficient technical skills to hold a discussion with the developers. For this reason it’s important to ensure that a PM has a strong technical background as well as people skills to communicate not only with the developers but also to manage the customers and/or business people. The result of having a weak project manager is that the developers will simply resort to sidestepping the PM by talking directly to the customer as well as manage the project amongst themselves. Evidently this defeats the object of assigning a PM in the first place.
  • Increase the PM’s authority: If a PM is going be assigned to a project, the PM then needs to be given absolute authority over the project. Even if some team members do not directly report to the PM within the company, within the context of the project, they should be reporting to the PM. Higher level management should explicitly make it clear to the team that they report to the PM and failure to do so comes with consequences.
  • Do one project at a time: Even if absolute authority is given to the PM on a given project, the developers for example may be working on multiple projects at a time reporting to multiple PMs simultaneously. The problem with this scenario is that the developers can use one project as an excuse for non-performance on another project. For example, a developer could say to PM 1 that they haven’t made any progress on project A because they’ve been busy on project B. They could then turn around and tell PM 2 that they haven’t made any progress on project B because they’ve been busy on project A. Meanwhile back at ranch, the developer hasn’t made any progress on either of the two projects, but the two PMs will be none the wiser. Amongst many other pitfalls of running concurrent projects is that it undermines the PMs’ authority thereby enabling the developers to run amok.
  • Global authority: In many companies it’s simply not possible to run a single project at a time. This could be for financial reasons where customers cannot be held off for several months in waiting for resource availability. In such cases, it’s best to assign a single PM to manage all concurrent projects, thereby granting the PM complete authority across all projects. The goal being that a single developer should report to more than one project manager at any given time. By doing so the developers will never be able to deceive the PM by using one project as an excuse for non-performance on another project.

Managing Costs of a Software Project

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

Developing software is an extremely time consuming process, requiring long hours of uninterrupted focus on the technical task at hand. That coupled with constantly learning new technologies, analysing requirements, designing, documenting,  coding, debugging, testing, installing etc. makes software development a stressful and difficult job. But no matter how difficult the job, for certain types of people the process of imagining something and bringing it to life from nothing proves to be work that is incredibly rewarding and self satisfying. Most successful software developers that I’ve met over the years love coding and most cannot imagine doing anything else with their lives.

Before I started working as a software developer professionally, I  remember spending hours sitting at my computer for hours on end writing code just for fun, without any interruptions or any other worries. When I was done my code had no bugs whatsoever and by that measure the code was perfect. If I wanted to implement another feature, I would just start coding it right away. The only limits were my own imagination. However, after I started working as a software consultant for a few years I noticed a few things that would kill the joy of coding. It’s for these reasons that many developers end up changing careers or at the very best keep switching between jobs in the hope of finding a light at the end of tunnel i.e. bringing joy back into coding.

The truth is that if you want to enjoy your career in the real world, you cannot continue sticking your head in the sand and pretend that you’re just a coding geek, and ignore the business aspects. You may not enjoy getting involved in the business aspects of software, but as the saying goes, “if you can’t beat them, join them” and believe me when I tell you that you definitely cannot beat the business people for the simply reason that they are pragmatic realists while most coding geeks are idealists with their heads in the cloud … or sand or whatever else geeky developers put their heads in. As George Carlin once said “Inside every cynical person is a disappointed idealist.” Continuing on a path of avoiding business meetings will turn you into a disappointed and grumpy pessimist, ending up complaining to your grandkids over Christmas dinner about how unfair the world is. So you may as well join the business people and turn yourself into a pragmatic realist that somehow always seems to find a solution where others see only problems.

Here’s some advise for getting involved in the business side of things. It all starts with managing ongoing costs of projects. Firstly, every software project has three components that need to be managed and there isn’t a single business meeting in which these components are not brought up:

  • Money: in the real world, people need to put food on the table, bills need to be paid and companies need to make a profit otherwise they go out of business. For this reason every little thing needs to have a monetary value assigned to it. So if you have an idea for a feature you’d like to develop, you cannot just start coding it because someone needs to pay for your time and effort. Your customer/boss will only pay for you to do it if it provides an ROI (Return On Investment) to the company i.e. a financial benefit the company gets from having this feature/application developed. Therefore before you start coding, you first have to create a proposal, estimate costs, prepare an ROI analysis, present it to the customer and wait for approval. Depending on the costs, complexity of the project and other factors this process could take a week, a month, a year, or it might never get approved (probably because your proposal sucked).
  • Time: regardless of whether you’re billing by the hour or you’re getting paid a flat salary, your time is being paid for. Therefore any feature or app you are developing must have a time constraint assigned to it because time equals money. To make matters worse, there are deadlines imposed by the customer because they need it by a certain date. If that’s not bad enough, you’re competing with other software companies, and so in order to win a contract, you’ll then have your salesman promising the customer (on your behalf) that you will in fact delivery the finished software in half the time for a fraction of the money that other companies are offering it for. While you’re still standing there dealing with the shock and horror of the situation, the salesman will then turn around and spew out motivational quotes to you which he heard at some sales seminar that he went to last week … or maybe he’ll just quote Barack Obama by saying “Yes, we can!”.
  • People: the more people are involved in a project the more politics you can expect. That’s just a fact of life. The reason being that different types of people have different agendas with different incentives in their job. So once again, before you get to write any code, people need to agree on what this code needs to do and how it needs to do it, how long it’s going to take, what budget is going to be allocated to the project and who is going to handle which work. Going forward you can expect millions of emails, phone calls, conference calls and endless recurring meetings that will make want to pull your hair out … assuming you have any hair left to pull out. Throughout this process both functional and technical specifications need to be written up which essentially serve as contracts for what will be delivered as the finished software to the customer.

You would think that people would be aware of all the above, but most people, especially inexperienced or non-technical stakeholders, somehow still believe that software projects are purely about just writing code. They either fail to foresee all the above mentioned factors or they simply choose to stick their heads in the sand and not learn from past mistakes. So they typically end up quoting purely for the time required to write the code, thereby setting up unrealistic expectations with the customers. On the customers’ end, it goes without saying that most customers are not software people and therefore never expect to pay for anything other than the time required to write code.

When these naive people inevitably run into these problems they throw their toys out the cot, arguments ensue which lead to meltdowns and they just generally become stressed out and unhappy with life. Many of the software companies then end up going out of business because of failed projects or loss of money due to time that was never billed for.

In order to to survive in this industry and avoid projects going pear shaped, you have to start managing expectations. Expectations translate into managing money, time and people and it all starts with the first quote to the customer. A million questions will arise when doing the first quote on a project. Here are some examples:

  • “Should we quote for emails, phone calls, meetings and other project management related work?”
  • “What if the customer refuses to pay for anything other than purely coding time?”
  • “Should we then just act like a charity and give that work away for free?”
  • “What percentage of the project do we spend doing project management versus time spent developing software?”
  • “What if unexpected things go wrong and the costs go up?”
  • “What if the customer keeps changing their requirements resulting in scope creep?”
  • “Should we then quote for requirements analysis and documentation work?”
  • “Will our competitors be cheaper than us because they’re not quoting for all the above?”
  • “What if our competitors undercut us by deliberately underestimating the time and effort required and oversimplifying the customers’ requirements?” This happens on a regular basis by the way. Many sales people do this because they know that once they get started on a project the customer will not be able to simply turn back if the project ends up costing more than what was originally quoted for. This approach is like the drug dealer sales approach i.e. the first one’s free, after that we’ll nail you.
  • “If that happens, will the customer be experienced enough to realise that they’re being played by our competitors and that in the long term it will eventually cost them more than they bargained for?”
  • “Should we then preempt the competitors’ tactics and deliberately under quote just so we can get the deal i.e. should we stoop to our competitors’ level?”

These are all difficult and valid questions to ask yourself before quoting on a project. What I can tell you though, beyond a shadow of a doubt, is that if you’re only charging for purely coding time, your company will inevitable go out of business. The reason being that in my experience at least 50% of the work required on most projects excludes coding time.

So what is the best way to quote and bill then?

  • Wrong sales approach: Under quote and over bill i.e. the drug dealer sales approach. As mentioned above, most inexperienced sales people will under quote and over bill in this manner and most inexperienced customers will accept these quotes, which unfortunately perpetuates these bad practices i.e. people learning from bad examples. This approach is equivalent to over promising and under delivering in terms of costing. There are all sorts of other problems which this approach can create:
    • By quoting for purely coding work and/or cutting the budget, you are cutting the time on the project, thereby putting unnecessary pressure on the developers who will end up taking shortcuts in their code, resulting in massive amounts of technical dept being accrued. In the long run, the project will end up costing way more anyway. Hence I say that you would be putting yourself and/or other developers under unnecessary pressure.
    • It goes without saying that taking shortcuts leads to lower quality code being produced and the software being filled with bugs.
    • Due to the low quality code and over-budget costs, your reputation will end up being tarnished in process. So even if you end up finishing the project successfully, that very same customer will most likely never call you again for the next project.
    • In the end it really comes down to the customer getting what they pay for. That being the reason for many internal and enterprise products only being as good as they need to be i.e. sales people undercutting competitors, underestimating requirements and customers being cheap and shortsighted.
  • Right sales approach: Over quote and under bill: it’s always difficult to estimate the costs and timelines of a project. For this reason and all the reasons mentioned above, I have found the best strategy to be as follows:
    • Sales meetings: During your first sales meeting/s with the customer, get a sense of the their requirements. You don’t need to get into too many details about every custom single business rule and how exactly each feature will be developed. The reason being that the customer is not paying for these sales meetings. Hence you don’t want to spend too much time doing the analysis and design work before any payments have been made or approvals have been granted i.e. you do not want to work for free. Furthermore, it can often happen that you’ll go through a long and rigorous analysis phase, designing and fully documenting a proposed solution only later to find out that the customer took your design to a competitor and ended up paying them for only their coding time. You may or may not be surprised to know that this in fact happens quite often. If you do this enough times your company will end up going out of business. The purpose of the sales meetings should only be to:
      • Sales Pitch: Pitch yours and the company’s services to the customer. The main aim of your first sales meeting should simply be to prove your competence and skills to the customer.
      • Requirements Overview: get an overview of their requirements for the software they’re looking to develop. Don’t get bogged down into specifics. The specifics should be left up to the analysis phase when the customer is actually paying for your time.
      • Proposal: put together a proposal for the solution you plan on implementing. This proposal should not be a functional and especially not a technical specification. There should be no mention of specific features or technical details of how the software will be developed.
        • Technical Information: from a technical perspective it should only provide an overview of the technologies (hardware, frameworks, SDKs and programming languages) you plan on utilising to provide the solution. You can  provide them with generic architecture diagrams, but don’t spend too much time creating custom diagrams that are specific to their business.
        • Solution Benefits: you should mention the benefits of implementing such a solution. This could be an increase in productivity, accuracy, automation etc.
        • Costing: this is the tough part that most people get wrong. Only through experience will it become easier to prepare costing estimates.
          • Development Costs: firstly, you need to think of the time required to develop the software by breaking down the tasks. If you’re using XP and Agile, these could be your stories or whatever you like to call them. If you’ve done similar projects in the past it will be easy to make an estimate. However for features that you’ve never implemented before, I would advise you to always be conservative i.e. think about the time required for research, testing debugging etc. If you’re not the one developing the software, this process will be become even more difficult in which case you will need to speak to the developers and get estimates from them.
            • Developer Confidence: Keep in mind that you cannot just take the developers’ estimates at face value. The reason being that some developers provide optimistic estimates, while others provide pessimistic estimates and this is based on their confidence, which may or may not necessarily have anything to do with their actual skill level. Confident developers typically tend to under estimate the time and effort required for coding, while under confident developers will overestimate time and effort.
            • Code Sloppiness: Some developers can be incredible quick to write code but they code can be sloppy. For such developers, you need to add buffer time for them to go back to refactor and debug etc. Others are perfectionists and take really long to code, but when their work is done it’s actually done. Therefore, you need to take all of this into account on the overall costing.
            • Buffer Time: Once you’ve come up with a fair estimate, it is best to always add a further buffer by multiplying the estimated hours with a factor. This factor is something of gut feeling you get through experience. For example, suppose a developer gives you an estimate of 10 days of development, you could then multiply that by 1.5, thereby your estimate to the customer being 15 days. The reason for this buffer is to take into account unexpected issues that can and do always pop up. Some may say that allocating extra time encourages procrastination, but I think that’s non-sense because it is the project manager’s job to check on up progress and ensure that people are meeting their timelines.
            • Do not quote on details: when quoting for development work, do not make the mistake of separating and displaying costs for every little coding task e.g. do not quote for each and every single button that they want on a form. Instead group the costs together and have only one or two development line items on the quote. The reasoning behind this is because you do not want the customer interrogating you about every single line item e.g. “Why would it take 8 hours to develop a single button.” The purpose of not quoting on details is not to be dishonest about the costs, but rather to avoid having technical debates with a customer that isn’t technical i.e. the customer has no idea how much work goes behind implementing the logic of that specific button and therefore to the customer it just looks like a simple button, while there could be 2000 lines of code behind that button for it to do what it’s supposed to do.
          • Project Management Costs: think about all the time that will be spent on the phone, writing emails, in meetings and driving around to those meetings. You must also take into account the kind of people the customers are when making this estimate. If your customers are professionals that know exactly what they want and they themselves plan ahead, then the project management costs can be reduced. However, you will have customers that know very little about software projects, are unprofessional, will constantly change their minds about what they want and the goal posts and timelines will constantly change. For unprofessional customers, I’d advise you to increase the project management costs substantially because you’re going to be doing a lot of baby sitting.
          • Analysis Costs: this is the time required for you to sit in workshops and meetings to discuss and finalise requirements and write up documentation. This time needs to be paid for because at least a third of your project will involve analysis work. It is for this reason that you should never make the mistake of starting the analysis phase before presenting the proposal and getting the customer’s go-ahead on the project.
        • ROI Analysis: finally once you’ve come up with a final number for the costing of a project, you then need to sell it against a value you’re providing to the customer’s business i.e. you need to give your customer a financial reason to spend the money on doing the project. Simply listing reasons is not going to cut it. Your motivation for doing the project needs to be have financials attached to it and that is typically the ROI (Return On Investment) calculation. In most cases, customers will already know why they want the software implemented, that being the reason why they called you in to take on the project. However, that may not always be the case, especially in cases when you are the one approaching them. In such cases you need to show the customer that doing the project will be an investment in their business and like any investment it must have a return/payback in a certain amount of time. So for example, if the project costs will be $100 000, you need to show the customer that the software will reduce costs in other areas of their business thereby enabling them to save X amount of money every month.  Those savings will amount to the total investment in a certain amount of time and that will be your final ROI payback period. Going forward the customer will continue to save for as long as they continue using your solution. In other words, the purpose of an ROI calculation is to establish a win-win deal with the customer whereby you earn money from the project implementation and the customer wins even more in savings over time. Selling based on ROI is the most difficult kind of sale you can make because you will need to have a thorough understanding of the customer’s business in order to put together an ROI calculation. However this kind of sale is also the most rewarding because instead of selling based on billable hours, you’re selling based on the value your software solution provides. It always helps if you are already familiar with the specific industry that the customer is in. If not, then you will be required to do a lot of research into the industry. Either way you will need to ask the customer a multitude of questions regarding their business before you can understand how to solve their problems and cut their costs.
      • Project inception: once you’ve presented the proposal to the customer you can expect to have a few backwards and forwards rounds of meetings and discussions about the proposal. Do not make the mistake of starting a project without the go-ahead from the customer. If it is a new customer that you’ve never dealt with in the past, I would advise you get a formal approval in written form from the customer. This can take the form of a PO (Purchase Order) or otherwise some sort of a signed contract.
      • Analysis and Specification Documents: it is only at this stage once you’ve gotten the go-ahead from the customer that you can start working. However, it is still not time to start coding just yet.
        • Project Plan: First and foremost you need to put a project plan together. The project plan will consist of the timelines of when each project deliverable (feature/work) will be completed and which resources (people) will be working on those deliverables. Both you and the customer need to agree on the project plan and the timelines need to be in line/comparable to the project costing in your proposal.
        • Functional and/or Technical Specifications: included in the project plan should be time allocated for analysis work and writing up the functional and/or technical specification. This phase of the project will involve having workshops and meetings to discuss the requirements of the software. Throughout this process, you will document the requirements in a formal specification document.  Many developers will say that documentation is a waste of time, but in the business world these documents will essentially server two purposes:
          • Contract for work required: The specifications will serve as a contract for what the customer can expect of the software. No more and no less than what is specified in the document will be delivered to the customer for the agreed upon price. It is for this reason that many software companies only quote the customer after the analysis phase, because they will say that they cannot quote for the project without fully understanding all the project requirements in detail. However, remember that I mentioned that in the costing process you should always add a buffer i.e. allocate extra budget and time for unexpected costs. This buffer that you added in your costing should cover any unexpected work that is being requested during the analysis phase and it will also protect you from doing the analysis phase at the risk of not getting paid for this work.
          • Mitigating scope creep: without a specification in place, the customer can continue asking for changes and you will end up spending way more time on the project than you initially anticipated all the while the customer is getting all this additional work for free.
      • Billing:  Many software companies bill only at the end of the project with an agreement in place that the customer only pays once the project has been completed and the solution has been implemented and tested. This is a huge mistake. The reason being that the customer will be under the impression that the project costs you presented in the proposal are a flat fee and in such a scenario the customer will not take into account the accruing costs of changing requirements, calling you in for additional meetings etc. All of that can land you in a mountain of scope creep costing your company ridiculous amounts of money. Hence it is important to:
        • Bill actual hours not estimated hours:  It is crucial to make the customer understand that the costing you did in the proposal are only estimated costs and that they will be billed the actual hours worked instead of these estimated hours. This clearly tells the customer that it will not be a flat fee for the project, but instead can change based on changes in the requirements. If you added a buffer to the budget (over estimated costs) in your proposal, the customer will end up being pleasantly surprised when the costs of the project are less than the estimated costs. However, if the customer continuously asks for changes throughout the project even after the specification document has been agreed on, these changes will be handled as CCRs (Change Control Requests) which fall outside the scope of the initial specification. The CCRs must be paid for and given enough of these CCRs the total cost of the project will end up going over the initial costing in the proposal. Having these mechanisms in place will encourage the customer to think twice before asking for changes to the initial agreement and will protect you against scope creep.
        • Bill in cycles: Bill the customer for the hours worked in continuous cycles e.g. monthly or even every two weeks. The developers and other resources on the project will then have to keep track of their hours worked and ensure that the costs are not going over budget. If the costs do end up running over budget, either because your initial estimation in the proposal was wrong or because of CCRs, the customer must be alerted of it and approval must be gotten from the customer before continuing with the project.

Keeping all of the above in mind, here’s a summary of golden rules to follow in order to manage the costs of a project.

  1. Always over quote and under bill instead of under quote and over bill.
  2. Do not get into too many details in the sales cycle i.e. when drawing up the proposal and estimating the costs of the project.
  3. Bill actual hours worked instead of estimated hours: Explain to customers that the quote is purely an estimation and that they will be billed actual hours worked rather than estimated hours. Explain to them that if there are no change requests, they can most likely expect the total cost to be less than the estimated cost in the initial proposal.
  4. Never work for free: aside from the sales meetings, proposal and costing, no other work should be done for free without formal approval from the customer. Even after the project has started, any change requests must be paid for.