Now that 2011 is behind us, I can reveal some insight into performance results for tactics offered this past year by so called (and usually self proclaimed) online marketing gurus. Several marketers I’ve met this past year consider themselves to be entrepreneurs and with this role in mind, they paid for and followed the advice of a few amiable marketing gurus. I put a simple spreadsheet together last week to tally up the results and see if any guru advice added to their bottom line. To make this a measurable and manageable exercise, I focused on one single piece of advice and used the cost to acquire this advice in my calculations. The learning was interesting; here is my short summary:

If you are a bear, you are a bear. If you are a dog, you are a dog. If you are a marketer, you are NOT an entrepreneur.

OK… now the longer version.

Marketing is about numbers and can be highly opportunistic in that, if something doesn’t work after a reasonable amount of testing, try something else. The numbers dictate the next action and thus, marketing (especially online marketing) is a very tactically oriented approach to success. Also, wrt online marketing, a marketer can jump from one product to the next quickly and easily by creating new lists of Customers and even by cross pollinating these lists.

The entrepreneur, on the other hand, is out to change the world with his or her vision. The best definition I’ve ever read on what an entrepreneur is, was written in 1975 by a professor at Harvard named Howard Stevenson.

“Entrepreneurship is the pursuit of opportunity without regard to resources currently controlled.”

This is categorically different from what marketers are tasked with. Marketers need resources that they can control or at least manipulate in order to achieve their objective. Entrepreneurs are strategic thinkers whereas marketers are tactical opportunists. This may sound a bit harsh but, please bear with me because my marketing oriented colleagues who see themselves as entrepreneurs have just gone belly up.

I’d like to help you avoid making a similar mistake by drawing your attention to one of the not so obvious yet, really poor recommendation made by these guru screwballs in the hopes that you heed my words of caution and can improve your business results at the same time.

The gurus stated as recently as December 2011 that entrepreneurs should put Customers to work to help improve the product and thus increase sales. They pitched ‘Ask Customers what they want, build it, deliver it and become fantastically wealthy in the process’. Fellow entrepreneurs and dear friends, this sounds easy enough and basic enough but it is a sure way to entrepreneurial failure. It is however a wonderful marketing tactic when used properly.

After a few years of sitting on the wall watching people act on such advice, we have come to the conclusion that this is a recipe for entrepreneurial business failure. There is one exception and that is the case where you wash, lather, rinse and repeat this cycle in as many different niches as possible. By our definition, this is not an entrepreneurial business model but rather an opportunistic approach to making money with slick marketing tactics. As a marketer, you can change direction as many times each month as you desire and you can continue to use process to drive your opportunistic fishing expeditions. If you catch a few thousand fish, you win and if your bucket is empty, you move on to the next hole. THe thing is that you do not build a sustainable business with this approach. You do however, have the possibility of earning a boatload of cash for yourself and your buddies until that niche dries up and you need to start all over again.

If an entrepreneur were to follow the guru’s advice, that business would very likely fail. The reasons are simple – part of every entrepreneur’s job is to invent the future. If you have a vision of improving a business model through the introduction of a new product or service, it is likely based upon your unique experiences in that industry. Your Customers have a tough enough time doing their own jobs. They don’t spend time trying to reinvent industries or improving how jobs are performed. Sure, every now and then you come across an exception. But you can’t bet the company on finding such a person within your Customer base.

Even more important to remember is that Customers typically don’t see the value in or need for a new product or service until they can either compare it with something that they use and know (perhaps a competitive product) or until they see a new product in action.

That means that if your firm is dependent on Customer feedback for innovation, you will always be behind the curve because Customers are only aware of a small sampling of what exists today. Resources and brainpower that could be applied to “inventing the future” at your firm will instead be used to catch up with features that lock the company into the past.

Your Customers can tell you about things that are broken and how they want to be made happy. Listen to them. Make them happy. But don’t rely on them to create the future road map for your product or service. That’s the takeaway here.

Since entrepreneurship is the pursuit of opportunity without regard to resources currently controlled, get out there and do your homework, create that vision and then build a business that adds value to a specific niche of Customers that are willing to pay for that value.

Every time you want to make any important decision, there are two possible courses of action. You can look at the array of choices that present themselves, pick the best available option and try to make it fit. Or, you can do what the true entrepreneur does: Figure out the best conceivable option and then make it available. Don’t ever ask your Customers where you should be headed. Just get up and lead instead.

Defining a budget for software development projects is something of an art form. Most cost projection tasks are the result of Client requirements, guesswork, gut feel and estimations that have little bearing on reality. Our Clients demand fair prices and solid proposals that they can go to their boss with for signature knowing that a reliable partner is standing by, waiting for the green light. These proposals need to be based on realistic estimations of our costs and our risks for delivering the level of quality that our Clients desire at a rate they can afford and in a time period that they want. Not many people are willing to discuss the topic but, the fact is, it has become a real challenge to deliver both a competitive quote and high quality result for Clients this past decade. The primary reason seems to be a lack of serious, responsible, dedicated and reliable individuals that are skilled in providing services on time, on budget and at the highest level of quality. One of our good fortunes is to have a strong team of A players already on board but a key component to delivering results that make our Clients happy is to deliver within 5% of our estimate.

Since hourly rates for coding, additional costs for rapid development and pricing of tools and other resources can fluctuate based on circumstances beyond our immediate control, we offer the following guidelines to help you create a consistent and justifiable budget that is also realistic.

The Basics
A budget is one of those pivotal tools that is used to make decisions in many areas of a company. When creating budgets please keep the GIGO rule in mind and input quality data as often as possible. For developers, budgets dictate the amount of time they can spend on specific areas of an application. For the project manager, it’s a baseline used to determine if the project is on track. For our Client, the budget correlates directly to the success of the effort. Regardless of circumstance, a number of basic philosophies can help your budgeting immensely by protecting it from subjective review. By understanding the basic concepts, and making sure that everyone involved understands them as well, you’ll be on the right track toward an accurate projection:

Identifying project costs 

When you’re identifying the costs of development, stay as close to reality as possible. Look at performance of the team members on past projects to get a feel for how long it will take them to program a given amount of code. Consult with your lead developer. Watch out for braggadocios estimates & consider multiplying your developer’s estimate by 3 to pad for your risk assessment stage. Remember to include costs for integration, meetings, security certificates, license fees, quality assurance, debugging, documentation, material costs, testing, deployment and planning time are all areas that need to be included in your estimate. Whether we will be billing our Client for these items or not, they are all valid and substantial expenses of a project. Including them will help you accurately measure the profitability of the solution down the road.

Be sure to itemize estimates for features that were not included in the specification. These are items that you suspect will be requested later on or those that would be beneficial to the final product. List these as options in your proposal and budget for them. Another good thing to up-sell is developer support time for about 60 days after launch. Often when a project is rolled out, support groups aren’t in place yet and thus many questions get deferred to the developers – plan for this eventuality.

Once you’ve got your costs outlined, it’s time to look at the probability of staying within those boundaries.

Risk
Risk assessment and assignment is very important to a successful budget. Without it, the crises that occur regularly and are an inherent part of any project, will affect your bottom line. Values in your estimate need to have this padding built in – it should not be considered a part of sales mark-up. Risk represents actual costs incurred over the course of development. Risk line items should include things like development team experience (or lack thereof), obscurity (supportability) of the technology used, planning time shortages, number of development teams, location of development teams, number of modular components, proximity and availability of the project driver, product dependencies such as databases or third-party software, server side technology, hosting configurations (cloud etc) and any unknowns.

Once you’ve determined your risk items, assign a scope and percentage to each. For example, if one part of your application is to be built in C and another in PHP, and your team consists mostly of C programmers, the PHP component may have a higher risk assignment under the ‘developer experience’ line item. The percent assigned should be applied only to the relevant portion of the project.

All projects have a certain amount of risk involved that can be attributed to human nature. People get sick, take vacation, disappear without notice etc. No one is an expert in everything. I always assign a percentage risk to this area – in addition to other considerations. Here is a sample of how we assess risk: An average 10-developer, 6-month project justifies a risk assessment of 7 percent of the total project costs. For longer projects and smaller teams, it will be higher; for shorter projects and larger teams, it will be lower. If your overall risk assessment is between 20 and 30 percent of the total project cost, you are within our operating norms.

Your actual total risk percentage will depend on your experience in evaluating the team and the pending effort. If, after calculating an estimate, your numbers are coming out too high, look at other projects delivered by your company. Did they actually fall within their budget? If not, your numbers may be justified. If so, you may be giving your team too little credit. Rectify project-to-project discrepancies before presenting your estimate to the project driver.

Regardless of how close you come to reality, a Client will be much happier if your project comes in below budget rather than over it; however, too high a risk value can create sticker shock, revealing inexperience and creating misgivings about your management abilities. By following the guidelines we’ve suggested and applying some common sense, you are more likely to deliver your upcoming projects on time, on budget and meeting your Client’s quality expectations. Remember that Time, Quality and Cost are interrelated. If you modify one of them, it will more than likely impact the others.