Some Caught Thoughts about BaseElements, Development and Billing
11/04/09 15:05 Filed in: FileMaker
Hang with me. All of the thoughts
mentioned in the subject line do come together. So,
follow along as I connect the dots.
I purchased BaseElements from Goya Party Ltd (http://www.goya.com.au/) last summer while at DevCon in Phoenix. Goya likes to refer to this tool as “a database for your database”.
What does it do? It imports the Database Design Report from FMP Advanced to give you a complete cross-reference of every element in your solution. From fields to script steps, layouts to custom functions. Everything is included, everything is cross-referenced. One very handy feature I found was finding scripts that aren’t being used in addition to finding other errors. It lists all of the items in your solution that have errors or are unreferenced (which includes script steps that are without a reference, such as in a template you've created).
As I started to say, I purchased BaseElements last summer. I hadn’t really used it until I was completing a major project for a school district. I created the DDR, launched BaseElements and let it do it’s thing with the XML-formatted DDR. Right away I found four things that needed to be corrected in my solution (and I thought I had done a good job in finding possible problems).
Just before running the report I had submitted the second bill for the work completed to date. In the invoice I listed the number of layouts, scripts, custom graphics, and fields as a point of reference for “justifying” my work. I guess I wanted to publicly tell myself, and the customer, that what I had done equated to the dollar amount being charged. In reality I was looking for a benchmark; some type of verifiable data as a point of reference. After invoicing the customer I listened to a podcast in which Jonathan Stark talked about a concept he calls “Value-based Billing”. The podcast in question was produced March 2, 2009 for FileMakerTalk. While I’m not nearly at his level in development, I thought to myself that his approach has merit over just billing for hours. After all, how many of us work at the same efficiency level hour by hour. Or, how many of us are always just focusing on the work to be done during that hour. For that matter, how about the time you spend getting something right just to please yourself or to figure out another way to attack a problem. In other words, the time spent isn’t the only thing that gives value to the solution as far as the customer is concerned. There can be more value in a system than the time it took in development. For some of us, there can be more time spent messing with the solution than the value in the eyes of the client.
As I looked at the analysis produced by BaseElements (see illustration), I thought to myself: “Right there is the empirical data I’m looking for”. There it is: Tables, TOs, fields, scripts, steps, layouts, value lists, functions, and calculations. Add them all up and you have a value that represents your time; a tangible reference point. In a way, these numbers tell me if I'm within a reasonable guideline of what's being billed.
So, what’s it worth? Well, that’s for you to figure out … and me, too. Each unit isn’t worth a dollar but each unit is worth something even if it's just 35 cents. That “something” is of dollar value to the client which, after all, is why you’re charging the client.
Here’s a suggestion. Along the way to a final product, stop at certain points and do an analysis on what you’ve completed. Put this information into a worksheet and note the information. Then, compare these reference points and see how the solution has grown “in value” numerically and financially. If you do time-based billing, compare the time to the total of all those discrete elements.
As a point of reference I've included a snapshot of the analysis of a much simpler solution I produced a few years ago. This was one of my first efforts for which I charged. The net result is this, the amount of time and effort has a definite relationship to all these measurable elements.
Byron Songer
I purchased BaseElements from Goya Party Ltd (http://www.goya.com.au/) last summer while at DevCon in Phoenix. Goya likes to refer to this tool as “a database for your database”.
What does it do? It imports the Database Design Report from FMP Advanced to give you a complete cross-reference of every element in your solution. From fields to script steps, layouts to custom functions. Everything is included, everything is cross-referenced. One very handy feature I found was finding scripts that aren’t being used in addition to finding other errors. It lists all of the items in your solution that have errors or are unreferenced (which includes script steps that are without a reference, such as in a template you've created).
As I started to say, I purchased BaseElements last summer. I hadn’t really used it until I was completing a major project for a school district. I created the DDR, launched BaseElements and let it do it’s thing with the XML-formatted DDR. Right away I found four things that needed to be corrected in my solution (and I thought I had done a good job in finding possible problems).
Just before running the report I had submitted the second bill for the work completed to date. In the invoice I listed the number of layouts, scripts, custom graphics, and fields as a point of reference for “justifying” my work. I guess I wanted to publicly tell myself, and the customer, that what I had done equated to the dollar amount being charged. In reality I was looking for a benchmark; some type of verifiable data as a point of reference. After invoicing the customer I listened to a podcast in which Jonathan Stark talked about a concept he calls “Value-based Billing”. The podcast in question was produced March 2, 2009 for FileMakerTalk. While I’m not nearly at his level in development, I thought to myself that his approach has merit over just billing for hours. After all, how many of us work at the same efficiency level hour by hour. Or, how many of us are always just focusing on the work to be done during that hour. For that matter, how about the time you spend getting something right just to please yourself or to figure out another way to attack a problem. In other words, the time spent isn’t the only thing that gives value to the solution as far as the customer is concerned. There can be more value in a system than the time it took in development. For some of us, there can be more time spent messing with the solution than the value in the eyes of the client.
As I looked at the analysis produced by BaseElements (see illustration), I thought to myself: “Right there is the empirical data I’m looking for”. There it is: Tables, TOs, fields, scripts, steps, layouts, value lists, functions, and calculations. Add them all up and you have a value that represents your time; a tangible reference point. In a way, these numbers tell me if I'm within a reasonable guideline of what's being billed.
So, what’s it worth? Well, that’s for you to figure out … and me, too. Each unit isn’t worth a dollar but each unit is worth something even if it's just 35 cents. That “something” is of dollar value to the client which, after all, is why you’re charging the client.
Here’s a suggestion. Along the way to a final product, stop at certain points and do an analysis on what you’ve completed. Put this information into a worksheet and note the information. Then, compare these reference points and see how the solution has grown “in value” numerically and financially. If you do time-based billing, compare the time to the total of all those discrete elements.
As a point of reference I've included a snapshot of the analysis of a much simpler solution I produced a few years ago. This was one of my first efforts for which I charged. The net result is this, the amount of time and effort has a definite relationship to all these measurable elements.
Byron Songer