Search Not Just Numbers

Loading...

Tuesday, 30 November 2010

Lessons I didn't learn until I ran my own business - Lesson 2

Welcome to the second lesson in my occasional series, 5 Lessons I didn't learn until I ran my own business.


Lesson 2: Flexibility is far more important than you think


In the early days of my business, I wanted to make sure I had all of the building blocks in place for the business I wanted in the future. In many cases I made long term commitments to keep the costs down so that I would have a greater share of the income that would eventually come in. This is really faulty logic!


When sales weren't as anticipated, I still had these monthly overheads to cover, whether or not there were any sales - each month leaving me less and less room for manoeuvre. Instead of being able to focus on growing the business, you find yourself focussed on short term sales to feed the overheads and survive until next month.


If I was starting out now, I would focus on trying to make as many costs as possible variable rather than fixed (even if this means that the rates you actually pay are higher). Once you have a proven regular level of sales, you can revisit these and maybe make some longer term commitment to keep the cost down. But if you do, make sure this works for the minimum level of sales you can expect, keeping the flexibility for sales above this.


Ways to stay flexible:


Employees - Where possible use temporary staff, paid by the hour, or outsource to experts by the day as needed. Employ sales people on a commission-only basis or at least with a high commission element to their package.


Stocks - Look at sale or return, or consignment stock arrangements so that you only have to pay for stock you sell. Operate a Just-in-Time approach with suppliers to minimise stock holdings.


Premises - Look for easy-in, easy-out options on offices or workshop space, ideally with a one to three month notice period, so you can flex for the space you need, rather than be tied to the space you've committed to.


Capital purchases - Do you really need that capital item? If you do need it, could it be bought second-hand? Can you pay for it out of cash and avoid a monthly lease commitment? If this is not feasible, try to ensure that there is an exit route, e.g. that the outstanding finance will remain below the resale value, allowing you to get rid of it by stopping the payments.


Vehicles - Although these should be covered by Capital purchases above, I think they deserve a mention on their own. The question, "Do you really need it?" should be asked at least ten times before committing to a vehicle lease in the early days of your business. This is probably the easiest way to take on large monthly commitments that bring little benefit to the business. Trust me, I learned the hard way. You're only kidding yourself when you say the flash car is necessary to bring the business in. Clients/customers are unlikely to be impressed and will more likely drive a hard bargain as they think your margins can stand it.You are buying it because you want to - there is no business case. You need a reasonable car to get you around. When you are making the money, you can get the car you want.


Remember, if you have a 20% profit margin, for every £100 monthly overhead you commit to, you now need to sell an extra £500 to break even! And remember break-even just means earning nothing!




If you enjoyed this post, go to the top left corner of the blog, where you can subscribe for regular updates and your free report.

Thursday, 18 November 2010

Off-the-shelf or bespoke software - How to decide

I have been approached by a client to build a project planning spreadsheet, but given the client's very general requirements, I have pointed him towards an off-the-shelf, on-line solution that will be a much more cost-effective solution for him. This got me to thinking about that choice.

My previous post on how to decide between a spreadsheet or a database made the assumption that you had already decided that you needed a custom solution, but how do you come to that conclusion.

I will take a similar approach to that previous post and list what I think are the key points to consider:

1. How unique is what I need?
Is your requirement something very specific to you or your business or is it quite generic, even if that is just in your industry? The more generic the requirement, the more likely an excellent solution already exists.

2. Do I have some very exacting requirements about how I want the need met?
In a similar vein to point 1, even if you have what appears to be a generic requirement, you may want it implemented in a particular way. We recently developed an on-line time-sheet system for a client because for their business had some very specific ways they wanted to keep time-sheets.

3. Is it possible, or practical, to change the process?
To get the best from an off-the-shelf product, it is better if you can adapt your processes to suit the way the software works. In many cases, this leads to an improvement in the process anyway - but sometimes the current process is key to the business, or a change would cause too much disruption. A bespoke solution can be tailored to the process.

4. How complex is my requirement?
This one really comes down to comparative cost and development time. For a simple requirement, a bespoke solution can often cost little more than an off-the shelf package and be implemented as quickly, but it can be tailored to your exact needs. The more complex the requirement, the more incentive there is to tap into (possibly) years of development that have already gone into an off-the-shelf package where the development costs are shared with the other users, than to pay to re-invent the wheel yourself.

5. What is my budget?
As ever, this is always going to be a factor. In most cases the off-the-shelf package will be the cheapest option, however do bear in mind any costs of tailoring your processes to fit (see point 3).

6. Ultimately, does the package I want exist?
If your answers to the other questions suggest that an off-the-shelf package would be best for you. This is only of any use if an off-the-shelf package exists. Alternatively, you may have just identified a business opportunity!

If you do feel that you need a bespoke solution (either spreadsheet or on-line database), then visit us at Spreadsheets by Email where we can provide you with a cost-effective, fixed price solution.

If you enjoyed this post, go to the top left corner of the blog, where you can subscribe for regular updates and your free report.

Tuesday, 2 November 2010

Spreadsheet or database - How to decide

There are those who will tell you that every application should be a database and that spreadsheets should never be used, whereas others will look to address every problem with a spreadsheet. How do you decide what is best for your specific requirement?

As with most of these things, neither is right for every application. In this post I want to give you my thoughts about when I believe you should favour either - I would appreciate your views in the comment too, whether agreeing or opposing.

I thought the best way to address this would be as a series of questions about your specific requirement and some comments about how your answer might influence the decision.

I have assumed in the questions below that the decision has already been reached that a bespoke solution is required.

1. Does my application require access (and particularly editing) by multiple users at the same time?
Although there are ways to achieve this with a spreadsheet (for example using Sharepoint with Excel, or if you do not require the functionality of Excel, Google spreadsheets are great at this), a yes to this question should certainly push you down the database route. In most cases, if there is only one user then a spreadsheet is the most cost-effective option.

2. Will large amounts of data need to be held in the application?
If the data really does need to be held in the application, a yes would favour a database, however if the data is already held elsewhere (for example your accounting or ERP system), Excel is an excellent tool for reporting from the data.

3. What interaction (if any) does the application require with other applications?
As stated in point 2, Excel can be an excellent reporting tool from other applications where the data flow is one way (i.e. into Excel). If your application needs two-way communication with other applications, or if it needs to trigger real-time events, such as reminder emails, then a database would normally be more appropriate.

4. Who will use it?
Many users are comfortable with Excel and will find it easy to use, however it is much harder to make "idiot-proof". If you really want to lock it down in such a way that it can't be edited by the user at all, then a database may be more appropriate. With a reasonably competent Excel user, the ability to edit and enhance might be a positive for the spreadsheet solution.

5. Where are the users?
If everyone who might use the application is on the same network (and point 1 is not a major issue), then a spreadsheet held on the server might be what is needed. Alternatively, where the application performs a task (rather than holds data), multiple copies can be used - although this may need to be controlled. An on-line database can be great way to deal with multiple users who need to access the same data from anywhere as all they need is a web browser.

6. What is my budget?
In the real world, this one can't be ignored. Assuming that either approach could address your requirements, it will almost certainly be cheaper to pay a third party to have a spreadsheet built - in many cases you can do it yourself.

I hope this helps. If you need any help in deciding, please feel free to drop me an email. At Spreadsheets by Email we can help you with both spreadsheet solutions and online databases.


If you enjoyed this post, go to the top left corner of the blog, where you can subscribe for regular updates and your free report.