The Perfect Balance - Using Your Time and Money Wisely

Most software projects fail.

I am not sure what the exact statistics are now, but not long ago it was about 80% of software projects that failed. From what I still see, this hasn't changed much, if any. Just like with starting a business, when designing and building software, there is a very high failure rate.

So why do software projects fail so readily?

The vast majority of the time the project is destined to fail before it even starts. Poor planning and communication are the biggest problem.

Let me make this very clear: It is ALMOST NEVER the idea that is the problem. It is ALMOST NEVER the construction of the software that is the problem. It is more likely to be people pulling the trigger too quickly with too little preparation. Another common problem is little or no emphasis on good sales and marketing of the product but this is really part of that initial planning.

The Perfect Balance - Using Your Time and Money Wisely

So should you spend tons of time and money planning and documenting your project in great detail? No. There are always the extremes of too much and too little. Too little planning is what often leads to failure. Too much will drain your resources before you have something to start using and benefiting from. There is a happy medium.

To help ensure your software project is a success, the first step is to extract out the minimum number of features you can to get the application out there ready to use. This helps minimize the cost and time but it also reduces the complexity. Less complexity means it is easier to understand and build.

We like to encourage our clients to deliver their applications in small incremental chunks. This allows them to get something out and in use quickly and with a smaller monetary investment. That means you can start saving or making money (if that is the purpose of the tool) quicker and create a cash flow to pay for further development. In short, there is a much lower initial investment before the tool starts to pay for itself.

It also gets the application in front of users so you can start learning what they want. It is always surprising what feedback we get from users on what they like and don't like. Getting something out quickly helps you adjust the product and gain greater customer satisfaction and attract even more customers. It accelerates business growth.

So what is the cost of making a mistake up front? This really depends upon the severity of the mistake. Again, the smaller the initial application is, the easier it is to change and fix problems. It also means the fewer mistakes you would make up front before getting valuable feedback from your customers.

With a decent level of planning you can reduce the cost of mistakes dramatically. Remember, no matter how much planning you do, you WILL make mistakes. Mistakes are how we learn. Don't be afraid of them. However, you want to minimize the severity and also reduce the number of mistakes you could likely make.

This is where the perfect balance between too little and too much planning resides. You want to do just enough planning to eliminate the majority of possible mistakes and address the biggest potential problems. Then you move forward in small steps and learn. It is like a baby first learning to pick themselves off the floor, then to crawl, then to walk and only then to run. They fall down along the way but because they take these small steps they easily get right back up and do it again, even better the next time, until it is simple and easy.

So how do you know when you have spent enough time and not too much time planning? How do you know it is time to pull the trigger and start your build?

There are a few steps we take our clients through to makes sure we minimize the time and money investment up front and get started on building the software at the perfect time.

Picture What You Want - Analysis and Design

We begin all projects by sitting down with a client to draw out what their application will look like and how it will function.

This isn't the pretty graphical design look. While that is important, you first need to get an idea of what you want on the screens and how the screens must flow together. The graphics can be applied once this has been solidified.

What we are talking about here is sketching out on a white board or on paper what screens need to be built, what is on each of those screens, how the screens flow together and what happens as the user navigates through the system.

In most cases we have found that this process can be done in just three 2 - 3 hour sessions over the course of three weeks. This allows time for everyone to digest what was covered in each session and for us to document the design. This documentation follows the industry standards and will help subsequent design sessions move more quickly and also be critical in ensuring the build of the software is done as expected and done quickly.

Walk it Through - Usability Testing

In the final design session, we like to take a paper version of the application and place it in front of you, the client. This allows you to actually "use" your program before any time or money is spent on the build. It frequently results in finding disconnects between what you are thinking and what we are thinking and eliminates the miscommunication that can occur from time to time. It also allows everyone to see where the application is cumbersome or confusing to use.

At this stage sometimes features are added and sometimes they are removed or simplified.

This final session is most beneficial in making sure the application is easy and fun to use. It gives us the ability to feel what it is like to use the tool just as your end users or customers will. And if it makes you feel good, then it is likely to make them feel good. And if they feel good, it will compel them to use it.

The Architectural Plans - Solid and Simple Documentation

It is very rare to find systems that have good, solid architectural documentation. In fact, it is very rare to find systems that have any architectural documentation.

The documentation I am talking about here is that necessary for programmers to understand and work with the code. This is highly useful when bringing on new developers.

We inherit a number of applications that were written by other developers. We have NEVER (please let someone make this statement no longer true!) received useful documentation on how the application works when we got started. The best we have ever hoped for is to get some paltry documentation created by the developer AFTER we have asked for it and AFTER we have had to spend significant time trying to decipher their code.

What this translates to is high costs and time delays to you whenever you have to bring on new development staff. This happens when you grow. It happens when you need to let someone go or they leave. It happens, eventually. You should be prepared.

The sad thing is that developing the documentation isn't that difficult and it saves lots of time and money and avoids confusion and mistakes by the development staff.

We put together a small set of comprehensive documents that are both simple and easy to follow. It is like the architectural plans you get from an architect for a large construction project. These documents are critical in making sure the structure is built correctly. It also speeds up the construction and helps the project manager dole out tasks and monitor progress.

In short, these documents are critical in the success and efficiency of build and are done within that three week Analysis and Design. They improve the success of the build and lower costs and risk in the future as your development team changes.

Project Plan - Who, What, When and How Much

Also part of our three week Analysis and Design, we put together a detailed project plan for our customers. This plan maps out what individual tasks need to be done. It allows us to then assign tasks once build begins so everyone knows what they are responsible for and so nothing is missed. And it tells you how long the project will take and how much it will cost.

Unless you are working on a very small project, without a good project plan it is impossible to tell how long something will take or how much it will cost. Developers will try to estimate and sometimes they will be right but most often they are not. Developers are notorious for going over budget and taking too long. Quite often this is simply because they pull numbers out of their butt. They are not sure of everything they will need to do to complete the project because they haven't mapped it out. So they either under estimate because they left out critical tasks or they take their estimate and multiply by 4 or 10 which leads to gross over estimation. Regardless, it isn't accurate or reliable.

As a rough rule of thumb, any project over $10,000 should have a detailed project plan to ensure nothing is missed and keep the project on time and on budget.

With good architectural documentation, assembling a thorough detailed project plan is pretty straight forward. We provide this as part of the 3 week analysis and design process. It isn't difficult to do. Without it, the build is chaos and your time line and budget are at risk.

Your Path for Success

I am always surprised by how many people think that some initial preparation, documentation and a good project plan are considered too much overhead and not worth the time. The simple truth is that if you don't do a certain amount of this your project is highly likely to fail. At the very least, if you don't scope out your project sufficiently, you will probably build the wrong thing the first time and have to completely rebuild it a second time. This means double the cost and double the time to get it right.

Doing a good job with your analysis and design, getting good documentation and putting together a solid project plan doesn't take very long. If you find it taking more than a few weeks and you are focused on getting it done, you should probably consider breaking the project into smaller chunks. You may be making that initial project too complex.

Most software projects fail. Are you willing to risk failure on your next software project?