Decision Making¶
Decision making is difficult.
Without perfect information, decision making will always be imperfect, however we have to make decisions all the time.
Some decisions are trivial and some are very important with wide reaching consequences. So how do we approach decision making?
This document is not a general purpose decision making framework, it is specifically about how to make decisions with regards to Edmonds Commerce projects.
Types of Decision¶
There are many types of decision. Here are a few:
Potential Action¶
A potential action is anything that we might consider doing. This could be implementing a new module, making some server configuration changes, performing a major upgrade. The list is endless and this is your most likely decision.
Choice of Technology¶
Deciding which technology to use when implementing a potential action. These decisions need to carefully balance the cost/benefit.
Communication¶
When communicating with other team members, project stakeholders and various people who represent the client, then careful decisions need to be made about what and how to communicate.
All Decisions are Imperfect¶
Whenever a decision is made, a reasonable decision maker will gather the facts to the best of their ability and from these facts, make a decision that takes care of the priorities whilst balancing the costs/benefits and the potential risks.
Making the Right Decision¶
The chances of making a provably correct decision are really quite small. When dealing with complex, contentious and risky decision then there are likely multiple choices that could possibly be valid.
Despite this, we can be sure that there is always going to be one choice that was the best one , we simply can't know which one it is.
For example, when purchasing a lottery ticket, the correct choice of numbers are the winning ones. However it is impossible to know this. The fact that it is impossible to know this does not mean that it is not true.
Avoiding the Wrong Decision¶
Within a scenario involving multiple choices, there are probably some choices that are objectively and comparatively much worse than the others. For example, out of 5 choices there might be 1 that will yield the highest benefit, 2 that will yield a good benefit and one that stands out as resulting in no benefit and a huge risk. In this instance, we really want to be sure that we do not choose this option.
No matter which decision we make, we must really try to avoid making a wrong decision.
Improving Decision Making¶
The best thing we can do to improve our chances of making the right decision whilst ensuring we do not make a wrong decision is to gather as much relevant and accurate information as possible and then to fully explore the costs, benefits and risks of each option.
Terms¶
Here are some terms that you need to be aware of and understand. I am not going to go into detail, each term is fully explained on Wikipedia etc
Turnover¶
Turnover is the amount of money that a business is bringing in.
Profit¶
Profit is how much money is left over from the Turnover once the costs have been taken away. Generally there are two types of profit
Gross Profit¶
In E-commerce, Gross Profit is the turnover minus the costs of the goods being sold. An item that sells for £100 and costs £80 to purchase from the wholesaler makes a Gross Profit of £20.
Net Profit¶
Net profit is the final amount of profit after all direct and indirect costs are taken away.
Margin¶
Margin and profit are very closely related, but where Profit is about actual monetary values, Margin is expressed as a percentage.
So on an item that sells for £100 and costs £80 to purchase from the wholesaler, the margin is 20%
Markup¶
Another related term is Markup. This is related to Margin but must not be confused. Markup is a percentage of the cost price that is added on to create the selling price. So an item that costs £10 with a markup of 20% will sell for £12 and will have a Margin of 16.66%
Technical Debt¶
Technical debt is a metaphor that is used to describe the costs associated with providing sub optimal but faster solutions.
When faced with an urgent requirement for a solution, the correct course of action is possibly to provide a "quick and dirty" solution now with a view to replacing it with a robust solution at some point in the future.
All the time that the quick and dirty solution is in place, it will be costing the E-Commerce business in the form of increased developer time requirements and increased risk.
This is analogous to taking out a cash loan in order to purchase an item now rather than in the future. The total cost will be higher than if you save the money and then make the purchase. The reason for this is that you will not only pay the full purchase amount for the itme, but will also pay interest on the loan until it is paid off.
One important point to make about Technical Debt is that it is inevitable and often a good thing if used carefully, but it needs to be kept under control and generally there must be a plan to pay it off.
Continuing with the analogy of a financial loan. You might decide to take out a mortgage in order to purchase a house. This is a significant debt but can generally be regarded as a fairly sensible one to take on. However if you have just taken out a mortgage, you should think twice about taking out a loan in order to purchase an expensive holiday. You can clearly live without a holiday to Barbados, but having somewhere to live is a fundamental need.
In our domain, this could be the technical debt of fixing a major checkout issue by making an edit directly on a live server without going through a formal release process. The checkout is priority number one and if there is a quick solution to bring it back online then it should probably be taken. However if there is a bug with a non essential system such as customers being able to view their order history, then we should definitely not be editing on the live server and should stick to our formal test and release process.
Read More:
Priorities¶
When making decisions, the first thing that you need to be clear on are the priorities and their relative importance.
When dealing with e-commerce businesses, the priority has to be that the site is up and able to perform its primary role of displaying products and providing a checkout process. If this fundamental process breaks then the business loses money. If it stays broken for long enough then the business will go bust. At this point, any other priority is moot.
So that means that our first priority is that the checkout process is working:
1. Checkout process working¶
We can subdivide this into its component parts, which form the user journey funnel from elsewhere on the site and towards the checkout.
-
The website as a whole is working
-
Category and search are working
-
Product pages are working
-
The basket is working
-
The checkout process is working
It could be quite common that any of these steps might be partially working. There could be intermittent faults, performance or stability issues or there could be issues that only affect a certain subset of visitors such as users on specific devices, browsers, geolocations etc.
It might be that if an issue is only affecting a very small percentage of users then the issue is deemed not worth fixing. Fixing this issue would incur huge costs and would yield a very small benefit that could take an indeterminately long time to break even and cover the initial outlay.
2. Making more money¶
Assuming that an e-commerce business website is functioning then the next focus will be to increase sales.
There is a very simply formula or triangle for determining how much money an e-commerce business website will make:
(Traffic x Conversion Rate) x Average Order Value
If we want to increase the amount of money an E-commerce business i making, then we need to increase one of these three factors and that will drive up the total turnover for the e-commerce business website.
Traffic¶
This is simply the number of visitors to the site. Assuming a conversion rate of 10% and a current visitor rate of 10,000 per day then that means 1000 orders per day. Assuming an average order value of £10 then the daily turnover is £10,000.
If we increase traffic to 15,000 visitors per day then we can therefore expect turnover to rise to £15,000.
Things that affect traffic include:
-
Search Engine Optimisation and rankings
-
Pay per click search engine advertising
-
Online advertising
-
Affiliate marketing
-
Offline advertising
There are many things that we can implement or improve to support these traffic generating channels.
Conversion Rate¶
This is the percentage of visitors that become buying customers. If our current conversion rate is 1% and we are currently getting 10,000 visitors per day, then that means 100 orders per day. Based on an average order value of £100 then that means a daily turnover of £10,000.
If we increase the conversion rate to 2% then that means 200 orders per day and a turnover of £20,000.
Thing that affect conversion rate include:
-
The speed of the website
-
The stability of the website
-
Bugs that cause users issues when trying to work through the order process
-
Usability of the website design, across different devices
-
The visual appearance of the website
-
The trustability of the website
Average Order Value¶
Simply enough this is the average amount that customers spend on a single order. Clearly if we can increase this amount then the total turnover will go up. If on 1000 orders per day, we have an average order value of £10 then we are turning over £10,000. If we can increase this to £12 average order value, then turnover increases correspondingly to £12,000.
Things that affect average order value include:
-
Upsells
-
Cross sells
-
Special offers and promotions
-
Free shipping thresholds and corresponding user prompts (spend £10 more to get free shipping)
3. Saving More Money¶
Any business can make more profit by spending less money whilst maintaining the same level of turnover.
Saving money means that the difference between the Gross Profit and the Net Profit is reduced.
There are many things that we can do to help E-Commerce businesses save money, for example:
Reducing Server Resource Requirements¶
If we make the code run more efficiently then fewer server resources are required to support the same level of business.
Things like implementing or fine tuning caching systems, profiling and optimising code and profiling and tuning database queries can all make a big difference.
Improving Marketing Efficiency¶
By reducing the marketing spend on wasted clicks, we can save the business money. This might mean improving the quality of data feeds or assisting with the configuration of pay per click systems so that badly performing terms are downgraded or excluded.
Automating Business Processes¶
If there is a time consuming business process that has to be performed manually by paid staff, then we have an opportunity to save the E-Commerce business a potentially significant amount of money by automating that process.
Reducing Technical Debt¶
Technical debt is generally something that is costing the E-Commerce business money over time. Technical debt can make development tasks more complex and risky which then incurs more developer time to achieve a desired outcome than could possibly be required.
4. Losing Less Money¶
This one might sound like it's exactly the same as "Saving More Money" and in some ways it is, but I wanted to make a clear distinction between things that can objectively and predictably save money versus things that cause money to be lost in a more chaotic and unpredictable way.
The main scenarios that can cause an E-Commerce business to lose money include outages and bugs, user errors, developer errors and other unexpected occurrences.
An E-Commerce business might lose money if a data feeds system suddenly starts providing inaccurate or incorrect data which then means that the advertising spend is being lost on wasted clicks.
A deployment that goes badly could cause the business to lose money because the website suffers and extended period of downtime. Of course this is closely related to priority #1.
The solutions to losing less money are covered by things such as:
-
Comprehensive and automated testing
-
Robust and reversible deployment practices
-
Continuous Integration and deployment
-
Secure and reliable data management and backups
-
Clear and comprehensive documentation
-
User training
-
Developer training
5. Growing the Business¶
A healthy business always wants to grow. Once the business is in a good way in terms of stability, turnover and profitability, then chances are there is a desire to grow the business. There are many ways a business will want to grow such as launching new products or services, moving into new markets and geolocations.
For our purposes, our role is likely to be on providing new functionality and assisting or handling in the processing and importing of new data.
Whilst this is clearly a priority, it is important to note that it is less of a priority than all of the previous priorities. There is no point launching a shiny new feature that is actually full of bugs and that could jeopardise the conversion rate of the main website business.
6. Having A High Quality Codebase¶
Assuming all the other priorities are being taken care of, then an E-Commerce business is going to want to ensure that the code that is powering it's business is of the highest possible quality. They do not want to be locked into a specific development service provider due to the fact that the code is convoluted and overly complex and requires extensive prior experience to understand all of it's quirks.
Bear in mind that any code quality issues that affect the previous priorities are by definition included in the satisfaction of those priorities. At this point we are simply talking about the general code quality, not things like bugs that prevent the checkout working properly.
Things we can do to ensure a high quality codebase include:
-
Using and adhering to coding standards
-
Ensuring extensive automated testing and static analysis is performed and passing
-
Incorporating a manual code review step into each major release
-
Ensuring everything is as documented as possible
-
Reducing the number of disparate third party code vendors down to the minimum
Decision Making Hierarchy¶
It is important to know who is responsible for making a decision*,***_ especially if that person is not you_**.
There is a clear hierarchy for decision making when providing technical solutions to an E-Commerce business. For most businesses that hierarchy will look something like this:
-
The Client
-
The Chairman
The Chairman is the head of the Board of Directors and is ultimately in charge
-
Other Directors
Other members of the Board of Directors
- The CEO - Chief Executive Officer
-
This is the highest level of management, reporting directly to the Board and responsible for all day to day business
1 | |
The highest level of management of the technical side fo the business, to which we are generally contributing to. Reports to the CEO
1 | |
The person who we are most likely to be in touch with on a daily basis and who reports directly to the CTO and/or CEO. The E-Commerce manager will be responsible for most decisions by the Client.
1 2 3 | |
This is the most senior technical person at Edmonds Commerce who takes ultimate responsibility for all decision, whether or not they are involved in making them
1 | |
This is the most senior developer and who may be requested to be involved in a decision making process. They are not responsible for decisions that they were not involved in though
1 | |
The project manager is responsible for all decisions within a project and should ensure that any contentious or risky decisions are raised with the CTO and/or the Senior Developer
1 | |
The lead developer of the project should be the single most knowledgeable person with regards to the technical aspects of a project. They will take responsibility for making technical decisions and are also responsible for ensuring that contentious or risky decisions are escalated
1 | |
A single feature has likely been developed by a single developer and so this person is the single most knowledgeable person with regards to this feature. They will be responsible for the majority of decisions on this feature, though must ensure that decisions are escalated as required.
1 | |
All developers on a project are responsible for decisions in a project and ensuring that they provide assistance as required to the decision maker
1 | |
In the rare case that there is no other person available or able to make a decision with regards to a project, then a generally senior developer may have to step in
At any point in time, you may have more than one position in the hierarchy, for example you might be the project lead and also the lead developer of a specific feature.
You are responsible for a decision when and only when the cost/benefit and risk analysis is clear. Furthermore, if a decision is going to incur significant cost, even if the benefits clearly outweigh the costs, then the decision should be escalated.
Escalation¶
In the likely scenario that you are not the person who should be making the decision then it is your role to escalate the decision up the hierarchy.
When escalating a decision, it is your role to provide comprehensive and clear information to ensure that the decision maker has all of the relevant facts and has the best chance of making the right decision and to definitely avoid making the wrong decision.
It is quite rare that we should ever be responsible for escalating a decision beyond the E-Commerce manager of the client. Any decision to escalate the decision within the Client is beyond our scope of responsibilities.
Cost, Benefits and Risks¶
Any potential action is likely to incur a cost and should hopefully yield a benefit. Any change to a complex system incurs an almost unavoidable risk, though this can be reduced to a minimum.
When making a decision, you are comparing the costs with the benefits and taking account of the possible risks in order to make your decision.
Costs¶
The costs to a business for making a decision are largely financial and include developer time plus any extra resources, licences or other costs.
Benefits¶
The benefits to a business are largely financial such as improving turnover, profitability etc. They might also be less tangible benefits such as reducing risk.
Risks¶
Along with the obvious costs and benefits, there is a also the element of risk. Risk can include extra unexpected costs or can include putting one of the priorities of the E-Commerce business at risk.
Risks for a business are that any of the priorities might suffer. For example a major platform upgrade could affect the fundamental stability of the system and even result in the checkout not working, priority #1.
A major user interface overhaul could hurt the conversion rate and therefore priority #2.
Implementing a new admin process with a clunky UI and sparse documentation can affect admin staff efficiency thus hurting priority #3.
Installing a new third party module that has questionable code quality, no tests and an excessively database driven configuration could mean a big spike in Technical Debt which then hurts priority #4.
Allowing the specification and scope of a new feature to grow unchecked can seriously hurt the time requirement and cost and this can then cause problems with priority #5.
Bringing in third party developers who are significantly cheaper can seem like a great idea and really helps with #priority 3, **but the knock on issues around technical debt and stability can then hurt every other priority, not least of which is **#priority 6
First the Simple Scenarios:¶
Where the benefit greatly outweighs the cost and there is little risk **then the it is likely that the correct **decision is to proceed with the action.
Where the potential action would incur significant costs and the potential benefit is very small, then it is likely that the correct decision is not to proceed with the action.
When the potential action could provide known benefits but the costs and/or the risks are potentially very significant and it is not known how significant they will be then is it likely that the correct decision is not to proceed with the action.
Where the potential action has known significant costs and could potentially provide significant benefits but it is not known how likely this is or how significant they will be, it is not clear what the decision should be, but it is more probable that the correct decision is to proceed with the action.
More Complex Scenarios:¶
Where the cost/benefit analysis does not fit into any of the above scenarios then there is no clear decision and it becomes a judgement call.
At this point, the chances are that you are not the correct person in the decision making hierarchy and you should simply represent the facts as clearly as possible to the decision maker.
Simplified Thought Process¶
When making a decision, you should be conforming to the best of your abilities that the benefits **outweigh the **costs + risks.
The Formula¶
take action = benefits > (costs + risks)
Client vs Edmonds Commerce Costs, Benefits and Risks¶
One point that is worth clarifying is that when making a decision or deciding whether to escalate, you should be clear about the difference between the Client and Edmonds Commerce
It may well be that for the client a decision is relatively low risk, but for Edmonds Commerce the opposite is true.
For example, you might decide to implement a feature using a new fangled technology that you are very comfortable with. The risk to the client is fairly low. However the risk to Edmonds Commerce is quite high - we will have to support that feature going forwards and if you are the only developer who can work on it then this is a risky decision. You might get hit by a bus tomorrow!
Our first priority is always to take care of the Client and ensure that the the **benefits > (costs + risks) **makes sense for the client. But we also need to make sure that we are balancing our internal costs + risks along with these.
Opportunity Cost¶
Whenever choosing to do something, one of the costs is the thing you didn't choose to do.
If you go to a shop and spend your spare change on a chocolate bar and a bag of crisps, then you may not have the left over cash required to purchase a sandwich and an apple. This is the opportunity cost.
When making technical decisions, one choice often precludes another. If we choose to use a certain ORM library then we have prevented ourselves form using an alternative and incompatible ORM in the future.
If we decide to write all of our code using the latest features of PHP 7.2 then we have removed the option to run this code on any server that is only running PHP 7.0.
Wherever possible we should minimise opportunity cost. One nice way to think about this is that there is a risk **that a decision now will mean we are unable to make the **right decision in the future.
Scenarios to Think About¶
Here are a few decision making scenarios for you to think about
For each scenario, assume you are the Project Lead Developer. You need to think about:
-
Should you make the decision or escalate (and to whom)
-
What is the right **decision**
-
Are there any wrong **decisions**
Checkout Broken for Adblock Users¶
Magento 2 has built in support for Google Analytics which provides really good business information that can assist greatly in the decision making process. Previously the client has made it abundantly clear that they regard this functionality as vital to their business operations.
Unfortunately, if this feature is enabled then the checkout process is broken for anyone using an ad-blocking plugin in their browser. Your rough analysis shows that this could be affecting anywhere between 10-20% of the current site visitors. Effectively this means that the conversion rate is taking a 20% hit.
What is the correct decision?¶
-
Disable the Google Analytics Functionality so that the Checkout performs Correctly and Conversion Rate is maximised
-
Accept the Issue as Technical Debt which you hope will be resolved with a future upgrade of the platform
Multiple Critical Issues¶
You are in a situation where a site is not working correctly due to an unexpected and massive increase in load. Someone in marketing decided to email the entire user base an amazingly great but time limited special offer - the order must be placed today.
This has caused three major issues to appear:
-
The home page and other critical path pages are taking over 10 seconds to load
-
The checkout is randomly displaying the user credentials of people other than the logged in user
-
The admin staff are not able to perform product updates as the page simply takes to long to load.
You have reviewed the three issues and we only realistically have the time to solve one of them. This means that the opportunity cost of fixing one issue is the potential ability to fix the other 2.
Client Requests Crazy Feature¶
The client has requested a new feature which to you seems like an almost certain **wrong decision. **The would like to include a chunk of javascript on every page which renders a huge and complex widget that displays videos about a product. The widget has proven unreliable and is killing performance on live.
What should you do?
-
Refuse to implement this feature
-
Implement the feature