Small and Medium Business

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.

The buzz word of the year is Managed Services and virtually everyone is on the bandwagon.  But what really is a managed services company?  How do you tell if your service provider is just using the word and perhaps “flat rating” your service but really isn’t Managing your network? 

Let me give you a little history of managed services first then attempt to answer that question.  I am writing specifically about companies who service small network systems.  Small networks are from 10 users to about 250 users and typically span from 1 to 6 offices.   The companies who have helped with these networks in the past have been hamstrung by the lack of tools to help with the problem.  The networks developed as simple systems, usually built by a self taught network amature turned pro.  Maintenance was break fix only, meaning when something broke, you called and they fixed it…hopefully.  As time went on the best of the support people developed companies with planned programs periodically coming on site to do a system review of log’s and user information looking for hints of issues before they became big problems. Squaretree developed an elaborate checklist to write down disk usage and processor usage, etc. and graph them over time in the hope of seeing issues.  The problem, of course, was that you only could see what you could see the day you were on site.  If something happened after you left you’d never know till the user called.  Also the only professional test of the backup system was on the visit, users on site needed to be very aware of the backup system.  This frequently resulted in days or more of missed backups.  Finally the system was prone to other human errors.  One of the errors was the dreaded “user list”.  Frequently the benefit of reviewing the server performance records was overcome by the urgency of a list of user desires that seemed more important work when the tech came to the office.  The tech, trying to be accommodating, would take care of the issues and not have time to get to the system work.  It was a constant battle to get customers to understand that they were only causing themselves problems down the road.

All this time the hardware and software vendors were adding new and better ways for the systems to signal problems as early as possible.  Simple Network Management Protocol had been developing since the early 90’s and was getting applied to PC’s and Windows Management Instrumentation was added to the operating system.  At first the systems that could watch these tools and turn all the data into usable information were complex to manage and geared to large networks.  Approximately 3 years ago systems started to mature that would allow companies like Squaretree that were managing many small domains to take advantage of the same features and benefits as the large companies.  The best of the systems are still very expensive, 10’s of thousands of dollars, but that cost can be mitigated over many clients.  It is this technology that started the Managed Services movement.  Companies differentiate based on the way they use the tools and the systems they wrap around them.

More in the next installment

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.

Doing a ‘Best of Breed’ analysis every time a recommendation needs to be made is time consuming and costly and potentially subjective and, most important, likely to be superceded soon therafter. Microsoft consistently provides ‘Best of Breed’ or ‘Near Best of Breed’ products that are part of a unified vision to work together thus adding more value than the sum of the parts.  That is not to say when there is a significantly better product out there that has good market share we are blind, a case in point is our recommendation of Dreamweaver for web design.  But we weight those decisions with a long term view of the product, the company, the integration needs and many other factors. 

By trying to select the current ‘Best of Breed’ a company increases their costs for both selection and support while adding a degree of risk that the products will not work together as well as products created with a unified vision. This risk is higher probability of a lowered return on the investment.  This risk can be mitigated by very high standards in the selection process with an eye toward maximizing the ROI.  This can work well when you have thousands of people to select for and a small benefit is multiplied by that large number.  Typcially the Small and Medium businesses I serve do not have the upside potential benefit of a perfect selection that a multinational corporation would see.   For us the most appropriate approach is basing the architecture on Microsoft core vision and then carefully adding in the key ‘Best of Breed’ products if and when this becomes necessary.