Small and Medium Business

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.