This chapter and the one which follows are, even more usual, an overview of considerations - they do not give details! In the whole area of finance, expert advice is normally essential.
You should study the relevant material which is developed in Bott, Coleman, Eaton & Rowland, or similar textbooks, which go into greater detail. One of the reasons for continuing to recommend this as a specified textbook is the clarity of its description of financial issues - a clarity which has been much praised by former generations of TBS accounting specialists!
Our problem, as professional computer scientists, is that anyone involved in technical work or in management must have some understanding! It is, quite simply, impossible to work at any sort of promoted level in an organisation without having some grasp of the basics of company finance. In particular we must all understand:
Over this chapter and the next we look in turn at these five areas.
It is very easy to appreciate that there are costs associated with any particular activity. Forming a basis on which to calculate or even estimate these is not always so easy. The accountants try to make things easier by identifying a number of different areas.
These are the most obvious, and the easiest to calculate ...
... from the simple formula, (relevant hours) * (hourly salary)
But it's not quite as simple as that, for we also have extra payments automatically required as a simple consequence of making a salary payment
all in all, we are paying perhaps 1.4 * ("obvious" salary costs)
These too are not quite as obvious as they appear at first sight! Indeed, they're quite tricky and far removed form the simple thought that the cost of getting a computer is what you have to pay for it when you go into the shop.
The difficulty is that the computer, indeed any piece of equipment, retains a value (a varying value, as time passes) and we have to find a way of coping with that.
The costs of any piece of equipment naturally falls into two distinct parts, one fixed, one variable.
Very simple, in principle:
although it disguises two potential complications. Firstly, it may be necessary to spread this cost over a period of time. Secondly, we mightn't actually be in a position to say what the value of the piece of equipment is going to be at the end of its period of service.
We can get round both these consideration by considering the idea of "depreciation", where we apply some sort of formula to calculate a drop in value over a period of time. There are two standard ways of doing this, straight line and variable depreciation ("variable" here is a title, the name of a pattern of depreciation ... we have not yet got to the issues of the variable equipment costs). The straight line graph shows an item being depreciated uniformly over a period of twelve years (meaning that after four year it has reduced to two-thirds of its initial value) and might be appropriate for something like a set of furnishings. The variable graph shows a depreciating balance calculation, where the item loses each year a third of its value at the start of the year; it might be appropriate for a motor vehicle, maybe even for a small computer network.
The most obvious examples of a variable equipment cost concern vehicles, in particular cars: the annual sums required for servicing, or the purchase of replacement tyres, are both dependent on the mileage driven.
Similar things occur in computing, but they tend to be regarded in other categories of costing rather than as an equipment cost; for example, the annual cost of software licences (which varies with the requirements of the time) or - at least in a pre-broad band world - of net access.
Note that it may (sometimes will) be necessary to include also the "opportunity cost" of the equipment, described at the end of this costing section.
For example, floppy discs or, these days, CDs, and printing supplies.
Beware the need, if items are purchased from stock amd then issued and used as required (which is what most of us do, even at a domestic level), to use the appropriate purchase price....
...which may vary with vendor and maybe with time.
Here is a clear instance where the need to keep financial records suggests quite strongly how we should be operating, in this case how we should handle our stock: perhaps on a FIFO basis (see material in 'Programming Techniques' class!), by forming our stock into a queue?
Inevitably there will be other miscellaneous but direct costs; we use the appropriate actual price, exactly as for consumables
But in addition to all the immediate costs of some particular project, there is a variety of general costs which need to be shared over all the projects, costs to be divided between several project costings on some defined basis. These are, if you like, the indirect costs experienced by the company just by virtue of its existence.
For example, we have to consider
There is no single, right way of dealing with these, but do remember:
Taking all these together, we have the cost of the activity
But there is one other aspect of costing still to be mentioned ... "Opportunity Cost"
This appears very often in the context of the purchase of a piece of equipment, but it is a valid consideration for any project. The idea is simple: undertaking a project costs a certain amount of money, the sum of all the costs we've just been through. Either you have that money or you don't:
Thus you can thus easily evaluate whether or not a particular project or an equipment purchase represents a worthwhile financial strategy, by comparing the opportunity cost with the expected return.
Opportunity costs, though, are only relevant in special circumstances, when you are really keen to be able to evaluate an option.
Always remember that they are not the only consideration. A typical home PC costs perhaps £500. Equivalent at 2008 prices to an interest cost of some £25 per annum (that is, £25 each year). But if you actually want that computer the thought of the opportunity cost is unlikely to seem very relevant!
Given a cost, we can calculate a price
... except that competition in the market place will effect changes in the percentage profit figure, as we struggle to achieve or maintain market share
... all of which is tricky!
In a software company, we will usually face the pricing of one of
and in addition we may need or wish to plan for the maintenance and development of work already completed.
The middle one of the three should be the hardest if we are to cost it properly! And supplementary questions start to become important:
For during preparation there will probably be no sales income (at least so far as that part of our company team is concerned)
... which leads us on, to investment assessment.
So, now we can prepare a budget!
And, if we have sufficient money to meet it, all is well.
If we haven't, we need to take into consideration ...
which brings us to the ideas of "cash flow analysis".
Essentially cash flow analysis is a neat trick ... a way of showing we can do something at less net cost than we'd thought!
The idea which drives these thoughts is that expenditure and income are out of phase:
As an example, think of the modern student experience
The biggest deficit in a period is the required working capital for that period
This cheapening of the whole process is obvious, if you think about it; for example, a student's need for money in the bank is reduced by temporary work
... which is just another way of saying that the working capital required for a year of student life is less than the total cost of that year.
What we do, is to prepare a regular (monthly perhaps?) statement of income and expenditure:
The maximum cumulative deficit in the period (a year, perhaps?) is the working capital needed for that period:
Obviously this makes most sense (or, if you like, the need for working capital is potentially reduced) when dealing with a range of products.
We can develop this idea to help assess alternative investment strategies,
In essence, what we do is to take account of the cost of providing capital
... and then worry about the surplus produced
... and the "pay back period", the period until we move into surplus.
But all this is starting to go into too much detail for general lectures in 'Professional Issues'; study the relevant material in Bott, Coleman, Eaton & Rowland, or in the textbook of your choosing -
Note that as a consequence some theoretically (or technically!) attractive propositions may get ruled out, because of their poor financial performance;
We have been talking about financial as opposed to technical (Computer Science) considerations.
But do remember other kinds of considerations also apply!
For example, environmental or human cost considerations:
It is unlikely that we as computer scientists will have to face environmental issues on this sort of scale (the problems associated with microchip production are probably as close as we would normally expect to get), but there are related ethical issues, such as being involved in work for socially undesirable projects. Think for a moment: there are plenty of possible examples!
The point is, to note that not always are our judgements driven by financial or even technical requirements!
|© Paul Goldfinch 2008||Next Chapter||Return to CS 302 Menu|