Small and Medium Business

What does it cost you to provide the revenue generating service or product upon which you and your employees depend for a living and your customers depend for value?  Can you break down that cost into individual parts and determine if, in fact, you are getting the best value for your investment?

While it is likely these questions are of interest to you they are rarely easy questions to answer.  There are some industries though, where if you answer them correctly you can devastate the competition.  These are likely industries where one or more of your raw materials are in short supply and variable in quality and therefore value.  If you can capture the highest value product by paying a little more, then create the finished product for the same or less than your competition then your product can be higher quality at the same or lower cost.  Your competitive edge then is being the preferred customer of the raw material because you can pay more AND the preferred vendor of the finished product because you are the higher quality at the same or lower cost.  How can you achieve this?  By tackling that difficult problem of knowing your input costs through the entire product or service creation better than anyone you compete against. Once you know your costs and how to minimize them, it is also critical that the behaviors that minimize cost through the organization be easily and reliably replicated.

This is where a custom application can provide a big advantage over standard software.  If you use the same software that your competitor does then your competitor has the same opportunities to achieve the cost reductions.  You are limited in your tactics to methods that the standard software will support.  Your advantage is limited to being able to use the standard software better than your competitor.  The barrier to entry, should you succeed, is much lower because once your competitor sees your success they have the tools in hand to replicate that success, they just have to use it.

Custom software, on the other hand, is tailored exactly to your knowledge of your business.  The more information you can input into your software and manipulate the better and more granular your cost knowledge becomes.  When it is clear that doing something differently will make your costs go down or your quality or yield go up then changing the software to behave in that new way should be easier.  More importantly if you find a method that would not be supportable with the standard piece of software you are increasing the barrier to entry for your competition.

A company I worked with several years ago made their living buying a manufactured product that had seen better days (used) and selling pieces of that product in order to make a profit.  There were dozens of ways the product could be resold, whole for salvage, partial for salvage, pieces for reuse, pieces for specific salvage, and many others.  Each type of disposition had it’s own costs.  As a quick example:

• Sale as a whole salvage item
• - $100 = Whole Item Cost
• - $  25 = Labor to process from intake to sale as salvage
• +$150 = Whole Item Value Salvage
• =$  25 Profit
• Single part separation
• +$  75 Single part value separated from the whole
• - $  50 Labor to separate single part
• - $  10 Salvage value decrease of remaining whole
• - $  15 Inventory holding costs (space, time value of money, etc.) for single high value part

Separating the part from the whole becomes at best a break even. But, if you know your costs this accurately, and you can shave $20 off the three costs of breaking out the single part, now you can pay an extra $10 for the supply. Your competitor can not pay that much, or if they do they are paying too much. With overhead they could begin to loose money on every purchase. You either corner the market and make better profit on each of this particular item or you force your competitor to loose money which, over time, will kill them. Multiply this over hundreds of items which all could be separated in multiple ways and you can see that the modeling and management could be come extreme unless you had the proper tools.

While it is still a daunting task to get all the costs itemized, the potential value, especially if you can tightly control this information as a trade secret, is large. By creating a custom application and allowing only a few trusted employees to enter the key values under the proper protection agreements you can create a system that gives you a large competitive advantage AND a huge barrier to entry. The rules of the system are “under the covers” so even the employees who are working closely with the inputs and outputs and modifying the systems values still only see a “black box” when it comes to the rules. These employees might be able to do the same things in spreadsheets at a much lower cost but this makes it much harder to maintain the trade secrecy value of the information and the business far more dependent on that particular individual.

Every company is similar in one way, they all depend on people to get the work done at some level.  People require communication and communication is hard.  I have had the pleasure of working with and looking deeply into many companies in my career and invariably the hardest thing is getting and keeping people working the way you want and expect them too.  My favorite story is the story of the kids put in a row, you whisper a simple phrase in the ear of the child on the end and ask them to whisper it down the line from child to child being very sure they say exactly what they heard.  They will be rewarded at the end if the phrase the last child heard was near the phrase the first child remembers.  Invariably, even with only a very few children in the line, the last child states a phrase that bears little resemblance to the original.  Now think about day to day communications around your company and you will see time and time again where what you thought you said did not result in the behavior or response you intended.  Now multiply that problem among all the people in your organization and all the times that they depend on each other to answer a “how do I do this” question and you may see the problem in a new light.

One answer to this problem is procedure and policy manuals but frequently it is easier to ask the person next to you to repeat the policy than it is to look it up.  Then you repeat it to the next person that asks and guess what, you have just played the children game in real life.  The first person got the policy from another person and repeated it to you EXACTLY as it was stated in the original document correct?  Well, it is likely that it was not perfect, and so on and so on.

Computer programs are the interactive way of forcing consistent behavior. The policies are written into the program and the only way to successfully get the work done is to adhere to the policy or the program stops you, requiring that you “do it correctly”.  This is the equivalent of doing the activity with the book open checking that you did it correctly at each step.  One way to solve this problem is to buy the “standard” program or the framework…..these are the programs that were made for your industry or the SAP like general programs that are meant to be customizable to any industry.

One of the most uncanny aspects is that even if two companies look like they are direct competitors doing exactly the same thing when you look under the covers they are likely very different.  The differences are, in many cases, one of the reasons why some customers go to one company and some to another.  It may not always feel like this is the competitive edge, but the way you do business affects the way you communicate and that affects which customers you will attract.

A standard program forces you to work in a standard way.  To the extent that your niche is determined by the way you do business you put your company at risk.  For some companies the determining factor is not the data that is kept by the computer, in that case it is very clear that a packaged program is just fine.  A dental office, a doctors office, an insurance broker for a large insurance company that has software, perhaps a car dealer and others are businesses that most likely can be handled by a standard program.

But when you do things a little differently from the rest, and your adamant that this is important to you, then you are a candidate for custom application software.  One of our clients services thousands of clients in small transactions but a competitive advantage is customer intimacy.  How do you seem intimate with thousands of customers?  One of the things we built into the workflow was an easy way to remind the owner to send personal notes to clients on the schedule they were used to and other services to help the owner get that accomplished.   The program that all 100 employees work in every day embodies the rules of engagement that the owner has made a part of every transaction.  New agents coming into the business can not do it any other way.  Training requirements are eased, consistency is increased and the customers feel the close relationship without it killing the owners time.  She genuinely cares about her customers and now she can genuinely care about more of them.

What does custom application development look like when it’s done well?  While there may be other thoughts on this and other people using processes that are not exactly the same and getting good results I can guarantee that there are certain parts that MUST happen for a project to be successful.  If these are violated then, while you might get a working program, it will take too long and some functionality is likely to be compromised.

1.  Vision

2.  Functional Requirements

3.  Creation of Code

4.  Implementation of the program

Vision:  This step is sometimes done as part of the functional requirements.  The deliverable in this step is a list of the groups of people that will be affected by the program that results from this effort.  Each group is defined and the desired result for each is documented.  The groups are called Stakeholders or Actors.  A specific person may be in multiple groups but when they are acting in a certain role they become a part of that group.  Examples of Groups are Inside Sales, Outside Sales, Bookkeepers, Invoicing staff, Customer Service, Executive Staff.  Each of these stakeholder groups are likely to have a different view of the business and different needs from the system.  Each of these needs to be documented before you can determine the functional requirements.

Functional Requirements:  These are the specific things the program needs to do or data the program needs to keep in order to meet the needs of ALL the stakeholder groups.  The visual representation is not as important here as the capture of the information.  In fact use of screen representation can inhibit our ability to question the requirements in depth which is important to getting to the true needs of the system.  Frequently we are able to ask, “why is that important?” or “What is that really used for” and find out that the process that has been in place is really not the best. During this step we frequently find that business stakeholders are better served changing the process.  The best thing we hear from this step is, “we know our business better now than we did because of going through this process”.  The result of this is a list of the requirements that the system has to meet. This list is comprehensive but not static. There will be discoverys as we go through the building of the code.  A key value of the application development team is to be able to determine when this process is “enough”.   At the end of this process the definition should be enough to be able to provide a flat fee proposal to build and implement the project.

Building the code:  This process is iterative, once the main parts of the database are in place screens start getting created and from that point we go back and forth with the client validating that what they are seeing is, indeed, what they expected to see.  Questions come up and are answered, sometimes changes are made to the functional requirements to accept things that the team has discovered during this process.  In most cases the changes are minor although there are times, “ah ha” moments, when the team realizes something larger should be done to add a great deal of value.  These are few if the process in Functional Requirements is done right but when they happen they can have a great deal of value for only a small change in cost.

Implementation:  This process is usually quite easy because we have been in contact so often through the develpment process.  Stakeholders in all groups have had a very stong hand all along in building it so they know what to expect.  One part of the project that is usually somewhat interesting is the migration of data from an old system to a new system.  I will have an entire article about that in the future.

Done right the act of creating an application custom taylored to your business will take a significant amount of effort from both your development partner and yourself.  But that effort will be rewarded in a far smoother operation with more information available and the ability to do more work with less cost, in fact it is likely that you will be able to achieve things you had always wished for but could never make happen.   If these are high value things then the creation of the program is well worth the effort.

You have an idea for a computer program, what do you do if your not a programmer?  The marketing literature says it’s really easy but of course it’s not really your thing.  But if it’s that easy you know a guy who’s kid is a guru, he seems to know everything about computers and loves programming.  Then there is also the guy down the block who is a professional and says his company has done lot’s of good programs.  It is very compelling to hire a person who “knows how to program” and they listen to your idea and get started writing code.  Your question is how long will it take and the answer might be something like, well about 6 weeks or 3 months or some number.  A few weeks into the process you start seeing screens and other things that look like a computer program, you might be able to enter data, stuff like that.  A few weeks/months later it’s reported that more of the program is done.  As the time and money you expected to spend approaches you hear they are 90% done.  As the time and money you expected to spend is exceeded you start to hear things like, well there is this one part that we had to do differently but we are almost there.  You ask what that means and they show you.  But the way they “solved” the problem doesn’t really solve your problem even though technically it does some of what you asked, sort of.   You tell them that won’t work and you are told, well the way you want it will take another month we think.  After a big sigh you say ok and a month later you get told that it’s harder than they thought but they almost have it done.  In the mean time you have found several other things wrong with the program you ask them to fix.  A month later you ask about it and they say, oh well those other things got in the way but we fixed those and we are back on the big problem.  You wonder why they didn’t tell you that was going to happen, your still writing checks and can’t use the program.  And on it goes…….

While the exact scenario has lots of different ways of playing out, the point is that creating an important computer program is a non-trivial exercise.  It is an exercise that has much more to do with communication, problem solving, risk managment and goal seeking than it does with learning how to write code.   While many applications have gotten done like the one above they are at best more costly than they needed to be and have fewer functions than you wanted.  Likely they will have a shorter life and when needing enhancements will be much more prone to needing complete rewriting.

In the next article I will outline the basics of a real custom application project.  Just doing it in the proper steps, while helpful, is not a guarantee of success but if you get a developer who would never think of doing it any other way you at least have a chance of having one that knows the value of proper project management.

Every company is similar in one way, they all depend on people to get the work done at some level.  People require communication and communication is hard.  As a mater of fact there are quite a few difficult problems in business. This is what makes it both fun and frustrating. But one thing I believe, the better you get the hard parts done especially if your solution is unique, the better value you can bring to the table for your vendors, customers and employees and ultimately for you, the business owner.

Originally this article described one scenario where custom application development was of value. I have since created another article on another very different value that application development can bring. I hope to add more to this series in the future. Till then here are the two articles each with a different value proposition to a business, both very real examples I have seen in action where custom application programming created significant benefit to the companies who chose to invest.

Work Flow
Getting your company to operate the way you want it too is an amazingly difficult task. You post policy and procedure and repeatedly you find people not understanding it the way you expected, resulting in inconsistent and sometimes negative value for your clients. Work flow applications allow you to create a structure where the process must be followed. The rules of the process are built into the program. These programs work well when, to get the job done, the user must interact with the computer for a significant percentage of the time. It is so important though that you are beginning to see computers in places where they traditionally have not been. For instance in transportation where the computer now guides the dispatcher/dispatched rather than leaving it to the whim of the personalities.

Knowing your costs
In this example a companies competitive advantage is based on knowing the exact cost of a large number of inputs and possible outputs of their value process. The better they know the costs the better then can manage supply and labor creating a win for everyone. This article also touches on the value of custom application development to create intellectual property or trade secret value in your business.

This is a post about why Application Development has been a big part of my life for the last 25 years.   I started life more as a mechanic, from refrigerators to huge steam plants and journeyman Air Conditioning I loved fixing things.  In the 70’s though I got a job that allowed me to play on an early HP “personal” computer.  Two big cabinets and a monitor and keyboard, single user.  It was an engineering computer and had an early “basic” language on it.  I got hooked but could not afford to do anything with it till years later when the Commodore 64 was introduced.  From then on I could not get away from it.  I programmed early in the morning and late at night.  I taught myself databases and assembler code (the language of the machine itself) and loved it.   Eventually friends asked me to write programs for them and I hacked some things out and made a few bucks.  But one thing I figured out early on, reading the manual and then hacking away till something worked would be fine for awhile but even then there were people developing methodologies and processes to create better programs.  Mostly they worked on bigger programs for bigger companies but the principles were still the same.  So I made it my mission to learn all I could about how “the big boys” did it and bring the relevant amounts of that process and procedure to the work I was doing on small database projects.  In the process I developed a four step process modeled from many of the things I was learning.  I spent hours on the old Compuserve forums learning from the best in the business.  I sent my code out into the world to get criticised by them also.  That was tough, like sending your baby pictures out only to be told they aren’t that cute.  Eventually that changed and I started getting more kudo’s than cut’s thankfully.

Several things I learned over the years.  One, many people who program for a living don’t take the time to learn their craft and they typically have to fix and fix and re-fix problems.  Two, the right amount of project management is required for every project, none is NEVER the right amount.  You must go through the steps of defining what you are going to build, designing the way you are going to build it and then building it according to the design, testing that all the way.  For a small project the time it takes is minimal.  For a larger project, $100k to $500k the process must be more rigorous.  But it MUST be there even for projects you are just doing for fun yourself, or they will fail.  Three, all businesses, even ones that seem exactly alike from the outside, are not alike.  In fact most businesses take on the personality of their leaders and it’s an amazing and fun thing to see.  Four, communication is an art and not easy.  The biggest impediment to communication is the illusion that it’s actually happening.  If you could take a picture of the images in two people’s brain when they were talking you would, I’m sure, be amazed how different they were.  This means that if you are trying to build software, pure idea’s to start with, you have to question, and re-question what you thought you heard in order to get to the real picture.  That is fun and results in very interesting discoveries.  For instance most companies have words they use frequently that mean entirely different things depending on the context but they don’t even recognize it.  As a non-participant though the words cause immediate confusion.  Likely, though, frequently inside the company these same confusions occur but more subtly because people have learned to adjust.  This can be a source of inefficiency and conflict frequently with misunderstanding as to the source.  As an analyst trying to create a model of the business a computer can use I have to be very clear on definitions, computers are not good at situational meanings.  Through this process I have heard more than once, “I know my business better today than I did before you started”.  That is one of the greatest complements I have or will receive.   Last, for now, I frequently see application development that is done by modeling the individual views of each stakeholder and then trying to link those views together.  In fact there is always an underlying model for how the business runs which then can be viewed through various lenses at various angles to show the right person the right information at the right time.  Miss this and the program is inevitably very complex, bulky and not as effective.  Get the underlying model correct and all sorts of changes can occur for years without ever needing a rewrite.

I love teasing out the real underlying model of the business that serves all the stakeholders.  It’s like looking in a fog at first and poking around till you find the substance.  Application development is a passion for me.

Custom Application Development is not for every business.  In many cases there are standard programs off the shelf that can perform all the tasks you need sufficiently.  Of course programs like Microsoft Business Systems Accounting and Quickbooks and many others can and should handle standard accounting tasks.   They are good at it because Accounting is a very standardized process and is unlikely to be your competitive edge.  But small business is a reflection of the management team and frequently of one or two people who start a company.  Just as personalities are different companies are different and have their own personalities.  It is frequently the case that two companies that make competing products or have competing services actually operate completely differently.  In the competition for both customers and great employees that personality can make the difference between mediocre and great success. 

So how does Application Development fit in?  There are operations in many businesses that require a great deal of information and frequently that needs to be acted on by many people over a process.  Getting the right information to the right people at the right time using paper is cumbersome.  Computers have aided that process by managing it and frequently by not loosing the information on some one’s desk or in their briefcase.  But applications that are standardized can not handle the specific personality of your business and if that’s your niche, your competitive edge, then custom application development becomes an option. 

How do you know if this applies to you?  Do you have databases that have sprung up in Access or other personal databases that are now being relied on by many people?  Do you have someone who is creating huge unwieldy spreadsheets that many people need to keep up?  Do you a person called a programmer or Access guru that you live in fear will disappear?  All of these are indicators that you have a need.  Other indicators are frequent questions around the office like “Do you know if ……”, “What is the status of …..”, “Who knows where we are with ……”.  These are indicators that the right information is not available when needed. 

Squaretree has analysed many companies over the years and helped a good percentage of those.  Sometimes we decide with the client that Custom Application Development is not necessary for the circumstances, the systems and processes are likely to fit just fine in a standard program.  Many times though we are able to steer a company through a successful application development cycle that results in a reliable, manageable program that meets their needs and saves time and money through increases in productivity.

I wish I was asked this more often before projects get in trouble.  There are many application development projects that go well in this world that is clear.  But as a company that get’s called regularly to “finish” a project that is almost done, we see our share of projects that are completely off track.  Every time we hear someone say “the project is pretty close to done but the programmer got another job so we are wanting you to just finish it up” we cringe.  Only once in 15 years has the program been anything but a disaster when we have taken it over.  It is stunning and amazing to me how many projects go over budget and fail to get even 50% of the intended results.   Worse by the time it is discovered that these failing projects are on the wrong track so much investment has been made it is nearly impossible to bring yourself to see the truth. 

So what are the warning signs of a problem project? 

1.  Analysis and specification documents either don’t exist or lack detail.

A specification for a program should be extremely detailed before you start writing any code.  There should be few if any statements of a general nature such as, “keep information about customers inquiries”.  A statment like this should immediately bring questions such as “what is a customer inquiry?   Does it come from the web? phone? email? fax?  Is any question at all from a customer considered an inquiry?  Do you need to know what time?  do you need to know who answered it?  do you need to know what answer was given and when?  how are you going to use these records?  there are likely to be thousands over time how will you look them up?  etc. etc. etc.”   If you do not have documentation that answers questions at this level of detail you have a high risk project

2.  The coding was started months ago and you get a question that is so basic you wonder how they could possibly not know that.  

By the time coding starts the team should know more about your business than you do or almost so.  While this is not a red flag it’s a warning to look deeper at what is going on and make sure the coding and project team really knows what they are trying to build

3.  The project is late and you are being asked to put more programmers on. 

The first request like this might not be the death nell but if the team size starts increasing and there isn’t a clear concise plan for deliverables being met then you can definitely say you have a problem.   If the original project was anticipated to take 1 main programmer and you have to add a programmer that was not planed you can anticipate 50% of that programmers time on additional overhead.  So if the project has 1000 hours left adding a programer risks making it a 1250 hour project.  A second is probably the same and more than that on a 1000 project run the risk of increasing the overhead time by more than they will help the project finish.  If you started with 3 programmers and suddenly you have 8 and your Project Manager doesn’t have clear and quick deliverables they can show you they are hitting that are testable then you have a HUGE yellow flag that is most certainly really red

4.  The project has been nearly complete, 80 or 90%, for months. 

You’re in trouble, the current team can not help you, stop!   

Application Development is a high risk endevour.  Done correctly it can give your company a competitive advantage that can have a very high reward for a very long time.  Done incorrectly and it can sink your company.  There are processes that lessen the risk including great specification writing and analysis, project management, risk management analysis and others.  Even these must be handled with judgement and skill.  Without them failure is very nearly certain.