In support of my aforementioned goal to explore the topic of selling interactive services it seems obvious to tackle the biggest piece first: pricing. My approach to determining the appropriate price of any project has slowly changed over the last ten years. The most obvious revisions occurred when I went from a one man show, working out of my basement office to a member of a large team of people, building enterprise level web content management systems.
In the earlier days a new project might be approached in the following manner:
- Meet with the client one or more times in order to understand what they want to build.
- Go back to the office and mentally roll the concept around until comfortable. (In my case this would sometimes involve sketches on napkins and me wandering around the neighborhood talking to myself.)
- Eventually a number of hours to complete the project would emerge from the ether with little or no real documentation.
- I would then work backwards writing an estimate which accurately justifies the final cost.
As unprofessional as this method may seem, it actually worked fine. At that stage in my career I was working by myself with accountability to nobody (except my creditors). All which was required to successfully price a project in this phase was a number I felt comfortable with and the customer would agree to. In order for me to feel comfortable I simply had to think about the number long enough to be fairly certain I had ferreted out all the potential risk and mitigated it by adding more hours to the project.
Because this method does not naturally lend itself to low estimates, the projects were not exactly pouring through the door. At the time this was acceptable because a one man team with no scalability has a finite number of hours available to handle the work. Sometimes estimates were wrong on the high side and sometimes they were wrong on the low side but in the end it all seemed to even out. The bills got paid, I learned and my clients were adequately served.
Sadly...or not...those days are long gone. Adding one or more members to a one man team means there are two new requirements: More work and the ability to communicate about the work more efficiently. Also, as projects grow in scope and budget it is very common for the scoping process to involve two or more iterations on the statement of work. It is not uncommon for a smart CFO or other client side counterpart to begin to question the logic when features and requirements are added and removed from the scope of the project.
Of the two new requirements introduced by working within a team of two or more individuals let's take a closer look at the latter: The need to communicate more efficiently. In the context of selling interactive services the official document of record is the statement of work, proposal or other document which defines the scope, schedule and budget. This document allows us to communicate from the client to the project producer what it is we are building, how long we have to build it and when it needs to be complete. I use an SOW so I am going to talk specifically about them.
If the SOW is going to communicate more efficiently then it is important for it to be accurate the first time. What happens when a company generates SOW's which consistently describe applications with insufficient hours available to build them? Well, the truth is a couple of things are going to happen. First, there are going to be a lot of them. A project which has insufficient hours is likely to have a low price. Projects priced low do have a tendency to sell better than the opposite. Unfortunately the resulting boom in sales is short lived. When there are insufficient hours available to complete a project either the client's expectations will to be missed or the company will be forced to do work which has not been paid for. Either is an undesirable result for obvious reasons.
In order to accurately scope a project when drafting a statement of work the sales consultant must be armed with certain facts about the time required to accomplish given tasks. If this information can be communicated up and down the chain from the client to the development team quickly and flexibly through the sales consultant he can feel confident and sell better...which means sell more. I believe the tool which makes this possible is a standard pricing table.
So, in the next installment I will endeavor to break down a standard pricing table and see what can be learned.
No comments:
Post a Comment