As I explained in previous sections, cost components where the work of people is involved, are hardest to calculate. Time & material based items in your spreadsheet need some time component to create a number…

"How long would it take you to walk the marathon?" If some one asked me this question, am I able to answer it? I never walked 42 kilometres, but I think so. I once did half a marathon, so I have some indication (believe me, this was years ago). I would just multiply that time by two and add a little thing. So, although I didn't do the job previously, I can give a reasonable estimation on the duration. "How long would it take to make your own dress?" If some one asked me this question, I am in trouble. First, I would be worried by the question itself, and second, even if I tried, I would be unable to give you a proper estimate. I would know how to make a small web site. I would know how to make a excellent spaghetti. My best guess would be something in between the site and the pasta. Yep, we are now talking all about estimating. So, pick up the dice, and start rolling them…   Getting an estimate The best people to provide you with an estimate, are the people who will have to perform the task. First of all, they probably know what they are talking about. But most of all, it will be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time.  Getting a good estimate from e.g. a programmer is not just a task for the programmer himself. The project manager plays a critical role in getting quality numbers. He has to talk with the guy (or gal), to see why he thinks it will take 7 days… So, the project manager is a kind of shrink for the programmers. That's right. They just have to kick back and tell what comes to their minds, and that's it. Yeah, right, duh! The programmer, in this case, should take steps to ensure that his estimates are getting more and more accurate. He can do this by keeping statistics on how much time he spend on what. How accurate were his previous estimates, etc. I dug this quote up on an internet newsgroup: "My experience is that people work to deadlines. If an engineer estimates a task will take 4 weeks, they do *not* mean 4×40=160 Hrs. They mean its feasible that it will be done 4 weeks after the start, and the Engineer will put in as many or few hours as necessary to get it done. On one hand, the Engineer will be factoring in such things as other workload going on, planned days off, etc. On the other, most people will underestimate the time it actually takes, and the experienced manager will know how to "pad" (or in some cases shrink) the estimate based on the track record of the individual."

So basically, ask the people who will be involved. Make assumptions explicit. This will help some people to give you a number if they are not sure. Let them put large disclaimer notices on their statement. It's a guess. But that's enough for you right now.

3.4 Refining until the end

You have now a first rough draft of your spreadsheet, filled with number that will not be the truth. The coming period you will take steps to make sure it will not be far from the truth.

Now you know you need some complex interface between systems. Later on, you will know what kind of data will be exchanged, you will have a vendor to make a better estimate. You will end up with a better number.

Hardware specs will become more clear. Software licenses will become more detailed if you have narrowed down your potential vendors. Stick with the calculation. Remember always it's a way to communicate with the actual decision makers, as it's money that talks, it's in the end the only language they will understand.

Experience will tell you a lot. If you have done these kind of processes for years, you can probably produce some good statement with your eyes closed. But more likely you wouldn't been reading this guide .

But if you're not alone, and working for a company, there will be some valuable information out there. You just need to dig it up.  Look for rules of thumb, look for comparable projects and apply them.  If your company has some database with historical data on projects, that would be great. But some old geezers who have seen it all before may do the trick also.

Corporate rules of thumb may give you a clue about a fair price per user for a software license. For a specialized business application the consensus within your firm may be that $1500 would be a fair deal, e.g.  Without knowing exactly what system you will end up, you can fill in some data for software licenses. So management will get some feeling for the amount right from the start.

Also rules of thumb may be available on ratio's between components. So, by calculating a part, you will be able to deduct the others.  One I use is the ratio of the total cost divided between software:services:hardware, where every component will be roughly equal. Services, like people you need to do the implementation, are hardest to calculate. Be calculating all the software components you need, you can use the same amount to reserve for services you will take. It's no exact science, but normally serve it's purpose.

If your company has done already several software projects, you can put these past experiences to some great use: done already some complex interface between to systems? Use this information for your preliminary cost calculation. Have some hardware already? Use their cost to put into your spreadsheet, until you have some better specifications.

The numbers. They are the hardest part of total cost of ownership. You will need time to get them clearer and clearer. You start out with some wild guesses, and you will refine them over and over again as more information comes available. And in the end, you end up with an estimation. An informed prediction.

Just keep in mind why you need the numbers. They are used for decision making with software selection. For this particular purpose it's ok to use a prediction. Actually, it's all you will have. It beats deciding based upon nothing.

This section will tell you all about the process of filling in the blanks; getting the numbers.

 

3.1 Don't be afraid

You will have to provide numbers with a high level of uncertainty, you will not know exactly everything; but still, you have to tell the story, as early as possible.

This may seem a little unnatural for you, if you are used to be more or less sure before speaking to your managers. Consider the following section taken from “The Microwave Way to Software Project Management”, the software project management guide I host on this site:

  "Son, what do you want to do when you grow up?" "Well, dad, I have no idea. Because I'm just 8 years old I haven't evaluated my options yet. Hormonal changes will probably alter my preferences and with the pace of development in technology, it's hard to say what kind of new jobs will emerge in the future anyway." If your kid creates a sentence like this, be afraid, be very afraid… A 'normal' child would just say: "Fireman, dad." Dad will smile, open a trust fund to put his son through college in the future, and will not slap him when on the kids' 20th birthday finishes his first year in medical school. That's a familiar situation! Now Dad talks to his boss… "Well, Project Manager (a.k.a. Dad), when will it be ready, and what will it cost?" "Boss, I have no idea. The 'it' you are referring to is undefined, the requirements are changing. The responsibilities are unclear, new people are assigned to the project from the user groups every day. It's best I take it one day at a time, we go incremental. I can tell you what the first increment will cost and when it will be ready… but don't ask me how many increments it will take. If we ever finish at all." Should be familiar also. Dad is a professional Software Project Manager, he knows Planning (capital intended) and has learned by experience that if he can't keep the promise, he will not provide one. Funny though, that the two 'familiar' scenario's involve the same man. Why it is funny? Even though he knows that the changes his son becoming an actual fireman will be slim, Dad is satisfied with the answer and saves money based upon whatever assumptions he has. He has no idea if his son will go to college, if so, when, and he has no clue what it will actually cost at that time. But still, he reserves money for the future of his son. What might be Dads problem with 'it', which happens to be an information system? The answer provided to his boss is honest and probably the truth. However, his boss is not waiting for such an answer, he must have some statements to be able to run his business. So, even though his statements are true (let's assume), is it fair to claim that you have no idea? Fair to whom? To himself… well, he made his point; he told the exact view he has in his mind. But is it fair to just consider his own well being? Should he provide some statements to his Boss although he is highly unsure? Actually, the overall well being of the company is also in Dad his interest; if it goes bankrupt, he has no job (and his son will have no college fund). To keep the business healthy, the Boss has to have some vision on the future… How long will my people be involved in this project (so, out of their day-to-day operations). How much money do I have to reserve for this endeavor (you know, income and expenses should be inline with each other to run a business)? So, in his own interest he should provide some statements, just like his son. Consider why his Boss needs the claims for the future. First of all to anticipate expenses and extra resources, but also, to determine the overall course. All related activities within the company should be in tune with the strategy of this project. It's like crossing the ocean, you don't have to know the exact path you will sail, but just knowing that you aim to hit the coast at the opposite side, will help you plan a welcome committee at the other end. Some kind of vision will help the Boss steer the complete business in a direction, which will benefit Dad, his project, and the stability of his job, so in the end will help raising his son. Â

2.6 Example cost structure

This paragraph will describe an example on how to construct a cost structure by just talking about the software that needs to be selected.

Consider the following situation…

The subject is some new business application. It will be bought from a vendor (so it's not gonna be some new development). The department which will use the new software consists of 25 employees who will all be users of the system.

From a technical point of view, the system should fit into the current infrastructure of the department. No network changes should be required and no new workstations should be purchased; the stuff should run on the existing PCs. A server can be bought if there's not enough room to host it on some existing hardware. So we will calculate for the worst case (buying new).

This is all pretty global as you would agree. But let's see with what we can come up with.

-                     Software licenses for 25 users

-                     Maintenance for the software

-                     Hardware (server)

-                     Maintenance on the hardware

If we make use of some existing components (PCs, infrastructure) for a complete result we should include the cost for them also. Although we don't purchase anything new, they are actually costs that are needed to run the system as a whole. Most of the time, current costs are available and perfectly suited for this purpose.

The IT department has calculated that for the amount of users and for the amount of applications these users have, the annual cost for the infrastructure is $25,000 just related to the new system, and for workstations it is $15,000. All equipment is already written off, so there are just annual costs.

-    Hardware (workstations) annual cost:    
            $ 15,000

-    Infrastructure annual cost:                 
            $ 25,000

For the comparison of the new systems, these costs have no influence, as they for all be considered the same. But they should be included, even just to make everyone aware you thought of it.

A very quick scan on the potential candidates for the new application, learned that most of them just use a good old fashioned client-server model, and they all use a database from a third party.

So, this creates for us extra cost components:

-                     Database licenses 25 users

-                     Database maintenance over these licenses

The department at hand has a pretty general workflow, it's not expected to have certain aspects that are so specific that major changes to an existing software package is needed. However, past experiences have learned this particular organization, to reserve for software changes, just in case.

The new software has to communicate with several other systems, from the same department and from other parts of the company. Also, the old, legacy system that will be replaced, contains valuable data about customers. This data is considered to be the crown jewels of the business and the new database should at least contain a larger part of this information.

-                     Changes to software

-                     Interfaces to several systems

-                     Data conversion (from old to new system)

The department itself has no IT people, so the installation of the system should be done completely be the vendor. However, the system will be maintained by the companies central IT department. As with all other information systems within this company, the central department should receive money from the business for this effort.

And there for the following items should be listed:

-                     Software installation by vendor

-                     Hardware installation by vendor

-                     General system maintenance IT dept.

This story will continue for a while. Think about all tasks needed to implement the system e.g. You will catch on pretty soon.

The results can be put into a nice table or spreadsheet. I put I or C for either cost or investment.

		2004	2005	2006	2007
Products
Software licenses for 25 users	I
Hardware (server)	I
Database licenses 25 users	I
Services
Changes to software	I
Interfaces to several systems	C
Data conversion (from old to new system)	C
Software installation by vendor	C
Hardware installation by vendor	C
Annual cost
Maintenance for the software
Maintenance on the hardware
Database maintenance over licenses
General system maintenance IT dept.
Hardware (workstations) annual cost		15,000	15,000	15,000	15,000
Infrastructure annual cost		25,000	25,000	25,000	25,000

"What cost this system in the window?" "Well, $12,000." And of we go with just 12,000 bucks to make the software work. Sounds familiar? It's funny how most of the time, people remember that they need some machines, or need some cables, but forget that actually hands do the work within the project, and that the persons attached to the hands are very expensive and are actually costs. So, you on day one: "we need hands, they cost money."

You can't go into to much detail at this moment in time, and you shouldn't have to. But you can setup a nice cost structure that will not be to far from reality for your project. Just think about the stuff that will be bought, and imagine what should be done, globally, with it to get it working. For the server, you need to install it, test it and roll it out. Software should be analyzed, specified, build, installed, tested and rolled out. And so on, and so forth.

If you think about it yourself, and talk to people. Don't go overboard in detail.

Easily forgotten, but part of an total cost of ownership, are the cost for the internal people, the people of the company or department themselves that are part of the project team. If fifty of your colleagues should follow a training  for 1 day, they simply cost money.  Don't make the mistake about thinking "I pay them anyway." If you are comparing e.g. software based upon these calculations, a difficult, not-user-friendly system may be cheaper first, but can cost you double in the end on internal cost (and mostly loosing production, and not generating any profits, like you should).

2.4 Annual or returning costs

You have an aunt that you invited once for dinner, and now she keeps coming back? In this document she is called "annual" or "returning" cost. You thought you paid for something, but things keep on coming, over and over, every year.

E.g. maintenance fees are a good example. You pay every year 20% of price to be able to call a help desk, or to have an engineer on site within the blink of an eye. Maintenance is a good example, but also think about routine jobs that have to take place to keep your system healthy, like regular updates. Most of the time you don't have to pay directly to a vendor, but your own people have to do it, test it and roll it out. Your fellow employees don't work for nothing.

Now we are getting to a point you might want to consult your accounting department or your financial controler; a discussion about cost versus investments of software and related items. I will describe the subject as a understand it. A financial genius will provide you perhaps with a more detailed, more correct story. I will tell you just enough in simple terms.

Every cost item can be treated in the books in two ways: as cost, then the amount of money spent on the item is booked directly in the period you actually purchase it; or as an investment, then the total cost will be spread over a larger period in the accounting logs.

If I let someone install a server this week, and the vendor will charge me $1000 for it, if you look in the financial schedule for this week, you will see directly my 1000 bucks. If I buy also this week 30 software licenses, which cost me $3000, the accounting department can book $1000 this week, $1000 for next year, and another thousand the year after that.

Typically things that will be used over a longer period (couple of years) can be treated as an investment. So the server itself can be regarded as an investment; the installation is definitely cost. But like I said, your financial whiz -kids can fill you in on this one.

Why is this important? Well, departments typically work based on budgets. If they have a budget for this year, that doesn't mean all the cost for a new software system will be subtracted from this years budget. By taking into account the investments, management can see how the new system will influence their current budget, and the ones in the years to come.

The following questions should be answered by your financial man or woman:

• What is the write-off period (over how many years can we spread the cost?)
• And what are the write-off percentages for each year (perhaps you don't spread the costs equally over all the years)?

To summarize, consider the following example: a $3000 server is an investment. The write-off period is 3 years, and the percentages are 40-20-40. In the end your spreadsheet would like something like this…

Item	2002	2003	2004	Total
Server	$1200	$600	$1200	$3000

The whole process of total cost of ownership starts by putting up an nice spreadsheet. It's the file you should nourish, it's the digital companion you should always have with you (or in good old hardcopy) during e.g. software selection process. As you will know, a spreadsheet begins with specifying some categories, some items where, later on, you will put numbers next to. The cost structure.

Experience and common sense will get you a long why setting up the cost structure for TCO. Typical components are hardware, licenses and some cost for network alterations. But I'm now getting ahead of myself.

2.1 Stuff vs People

Buying a computer is one thing, getting it running and available for users to work with is another. From a cost perspective you have the purchase of the product, in this case the computer, and the bill for the people installing and troubleshooting the thing. You have costs for products, stuff, things and costs for people.

It seems like an open door, but in nature they are very different. Buying things is easy -getting the right stuff is the hard part. But once you have a rather clear idea about what to purchase, calculating the cost is like 1-2-3. They're fixed numbers and the accuracy of the amounts is pretty ok. A vendor can tell you without to much room for error the price for a certain computer.

Enter people. Now, they are difficult to calculate. The estimate on how long a certain job will take is a very nasty one, and plays therefor a different role within the cost structure of the TCO.

2.2 Fixed price vs Time &Material

It's not completely true what I told you about the cost of people in the previous paragraph; you can have people working for you for a fixed amount of dollars. A service performed by resources can have a fixed price; regardless how long the task will take, you will pay one certain predefined amount of money.

The opposite of a fixed price deal, is time & material based. For this type of deal you will only agree on a fee (per hour, per day, whatever), and for every hour spend, the vendor will send you a bill.Cost is in this way always determined in retrospect. This makes it difficult to calculate, as the hours that will be spent on a task may range from a "wild guess" to a "pretty good informed guess".

Why then this 'total cost of ownership'? Again, simple. Because a lot of times only part of the cost is considered, and after a while the brown stuff hits the fan; unexpected bills turn their ugly heads up. If I learned one thing in all these years, it's that managers never like unexpected things, especially the ones of the paying kind.

When a company decides it's time for some information system, normally someone is assigned to fill in the answer to the urging question: which system? I assume, you are that one, the poor sucker responsible for pushing the car up onto the mountain.

From day one, you lay down this issue of cost. From day one you should make everyone aware you're going for the full Monty, the whole enchilada, the total cost. If you tell a business manager software will cost $10,000, he will assume that's what he has to pay in the end. You will assume he knows you're talking about just the software licenses, and not about hardware and infrastructure, and not even beginning to top the subject on implementation cost.

The first day you have no clue about the cost. At least you don't have a clue about the amount. You do know buying and implementing software will have several components that make up the cost. You know you need something it runs on, you know you need some programmer to interface to different systems. They don't.

By laying down all the cards from the start, you avoid surprises. You will get valuable helping hands from the managers if you tell them what your questions are from day one. You will be amazed.

And if you aren't sure, you do know, after finishing this tutorial, you can rest assure. You will be able to make a good and informed impression on your first date with the one with the wallet.