So tell me, Why do we pay you?
So imagine this: you are sitting at your desk at work. When a mid-level manager strolls up and asks you the following: "Why are we paying you to do what you do?" Could you answer him? Would he understand the value of keeping you if you did? Recently, I had a chance at work to answer this exact question. Thankfully, the situation was much more relaxed. You see a project that I am the technical lead of was awarded a Project Manager. To me this means that the business thinks that what I am doing is valuable. Valuable enough to pay someone to make sure that it is well staffed, organized and properly directed. I am pleased with the direction we are going. But as one might expect, the Project Manager was not a software engineer. So naturally explaining the value of the project in software terms wouldn't help. The make matters more complicated, the project is not customer facing. It is in fact a business solution, helping to tie many other services together. Since this project had been without a Project Manager for a while, we had never completely translated the value of the project into business terms. As a result our first meeting with the PM experienced a little bit of a disconnect. We spoke about the value the software provided to other software applications. But our PM had some trouble translating that into meaningful terms for herself. So following the meeting, I took it upon myself to attempt a business translation. I took what I knew about the project and its value and translated that roughly into business terms. I certainly did not do a perfect job. But I believe that some benefit may come from discussing what I have learned over the years and was able to apply to this project. As I see it, Business Value comes down to just one thing: More Money. But there are two ways to achieve this end. Either you make them money, or your save them money. If you can translate your work into one of these two parts you can usually make a business case for it. Our project was created to simplify the process of connecting many apps. The project would make it easier to maintain, and easier to extend the connections between application. It would also support new feature implementation. Moreover, since the new system is simpler, it reduces the likelihood of incorrect actions by our system. So how does one translate this into saving or earning more money? If the project make it easier to maintain a system, then it reduces the man-hours spent on maintenance, right? If you save man-hours, then you are saving money right? If you want to go the extra mile, provide an estimate of how many man-hours it saves. Then multiply those hours by the average software engineer hourly rate. This provides a number of dollars that your project can save the business! Since software projects often provide a benefit for many years; try to provide information about saving during a single year. So if I save 8 man-hours a month, I save the company 96 man-hours or 3600$ per year (assuming a salary of 75K$). To take the example a step further, I can also factor in the cost of my work on the project. Let us say that it will take me 42 man-hours ( or roughly 1 week of work) to complete this feature. Then it will cost the company 1575$ to produce. The result is a net savings of 2025$! Going back to my project, since it makes it easier to extend, the cost to implement it will be rather low. If you can quantify how much time it will take to implement your solution, you can provide a more accurate estimate to the business. The project is designed to make it easier to add new features to our system. This means that it reduces development cost. Additionally, it means that the new feature can make it to the market faster. Do not under-estimate this! Faster Time-to-Market can provide your company a competitive edge. The edge comes from either by being the first to provide a particular functionality, or by begin able to under-bid competitors. While it can be difficult to provide exact value numbers on this, you can highlight the man-hours saved in development. I find it easiest to understand by providing a comparison to the current process. To provide a good estimate, I recommend using a current project. Comment on the time it took to implement the part of the feature related to the new project. Then compare it to the time it might have taken using the new project. This provides a tangible example of the value your project creates. Finally, my project simplifies the logic of linking multiple services. This simplification reduces the risk of errors. To put a value on this, you need the time saved. Start with the current time spend debugging. Then estimate the how much your project would save, based the project's implementation. My project simplifies by pushing the logic into a more appropriate context. It also allows the using services to dictate the communications they wish to react to. As a result nearly all the current bugs could be eliminated. Not 100% of course, but a sizable chunk, perhaps 70-85%. Using this estimate, you can translate the man-hours saved into dollar value as before. Translating from software value into Business value isn't always easy. But it is doable. Further, it is quite approachable if you have the right mindset. How am I saving the company money, or how am I earning them more money? Once you have these answers, you can begin the translation into business terms. To be sure, the estimates you provide when you first start will be a bit optimistic. But with time, practice and experience, they can become more realistic. I am certain that the estimates I provided to my PM were lacking in some respects. But something is better than nothing! And I got to learn a valuable lesson in translation! If you have a project to translate, I'd be happy to discuss! If you have any pointers, I would appreciate your suggestions! Just send me a message! Good luck and Happy hunting!