If the ‘Build vs Buy’ tool clearly suggests you develop your own custom application, take a deep breath and review the statistics below.  (And if the tool suggested you should probably Buy, you may still be interested in seeing the latest research and questions to ponder....)

I.T. Analysis Experts, Standish Group, found in 2009, only 32 percent of all software projects succeeded!  24 percent failed or were never used, and 44 percent ran over time, over budget and/or didn’t have all the requirements!^[i] 

So this is where your research really hits the road.  Review the following questions, and where you don’t have definitive answers, you are going to need to do some digging and documenting.  Discuss questions and findings with your key end users to ensure you consider the most important and necessary factors.

A.  Do you have a good sense of the project effort involved to develop your custom application?   It takes the combined time and talents of a number of people, as well as other resources to formally design, architect, develop, test and deliver a software application.  The breadth and complexity, the time you have to build it and the budget you have to work with will all influence the end result.

Using what you have learned so far about your key end users as well as the features and UI, create a spreadsheet, and in a column, draft a list of all the project personnel you think you will need.  These are people not only developing the application, but approving your project plan and budget, assisting you with the management, etc.. 

Below the list of project personnel, in the same column, add the software, hardware and related resources that will be required for your application.  Do the best you can researching and documenting this information.  Ask your key end users for help. 

For the most part, Exercise 4 presupposes that you have an I.T. department with software developers, who have the time, resources and capabilities to respond to work on this project.  If they cannot respond for whatever reason, though, you may then have to look at recruiting, training, increased employee benefits, workspace, and management costs.  Add appropriate items to your list of people and resources if you do not have software developers.

B.  Do you know your approximate budget and roughly how complex the application is?  Consider a simple, web-based application of 10-15 screens that has minimal data entry, calculation and storage requirements and is designed for less than 1000 users.  Is your application more or less complex than this?  (Determining complexity of applications is a blog series unto itself, so do your best guesstimating for now.)

For a very simple application like that above, if 2 developers each make $25 per hour, work 8 hours per day, 5 days per week over 8 weeks, that equals $16,000.  Is that within your budget?  Do these developers have the necessary skills to ‘hit the ground running’ or will they need time and training to get up to speed?  Do they require the guidance of a business analyst, project manager, or software development lead?  Have you considered the cost for design and project meetings as well as computers, other hardware, and software needed? 

Add a new column to your spreadsheet created in sub-section a. above and note your estimated project costs.  Total all those costs. 

Some other considerations - - Can you afford to expand the project if it goes over time, over budget or the initial requirements change?  Do you have a KILL point in mind if the project is taking too long, is costing too much or is not going to provide what you need in your application?   Make a note of your KILL point limits for each factor, and discuss with your key end users and stakeholders.

C.  Have you considered the costs of post implementation maintenance and support? That is, once your application is up and running, who will continue to update your application and to support and train the people using it?  What are those costs?  According to Mark Lutchen, head of Pricewaterhouse Coopers IT Effectiveness practice, “...70 percent of software costs occur after implementation.”^[ii]  In other words, the time, money and effort that you estimate as the ‘cost of the application’ is just the tip of the iceberg.  As technology and your needs evolve, your application will also need to be updated.  In addition, the costs of training and support need to be factored into department budgets – yours or someone else’s or perhaps both.  Application support and maintenance contracts can be the bread and butter of I.T. consulting companies for good reason.   There is always a need for support, training and updating of an application following its initial release.

Start a new row on your resources and costs spreadsheet.  Multiply the cost of your project by 70 percent.  Divide by the expected lifecycle of the application, up to approximately 8 years, according to Mark Lutchen^[iii].  This is the annual maintenance and support budget.  Is it acceptable to you, your I.T. department or other stakeholders?

D.  Do you have sufficient time before you need to launch your application? With the web based application in mind from sub-section b. above, additional time and costs need to be factored in to address software bugs as well as changes in requirements as you see the application take shape.  (The latter is referred to as scope change and both ‘bug fixes’ and scope change are inevitable in projects.)  If you have a set launch date, do you have the money and resources to get your application built and tested well before that proposed date to take these ‘bug fixes’ and scope changes into account?

Whatever your research has told you, it is usually safe to double or triple all cost as well as time estimates in consideration of the staggering statistics from The Standish Group above.  In a new row in your spreadsheet, double then triple the initial project cost.  Also, add two new columns to the right of your resource list costs.  Estimate their start date available, then estimate the end date they are required.  Total the days or months, then add a third and fourth column doubling then tripling those end dates as well.

Custom application development is not for the faint of heart.  Review the above sections and questions carefully and discuss with your key end user group and other important stakeholders.  Perhaps you may decide to reconsider your tentative decision to Build a software application.  You may wish to go back and try worksheet Exercise 3 again, or at the very least, Exercise 4 may have given you some important factors to consider with respect to your timelines, budget and the extent of the features/UI you would like in your custom application. Considered individually, the timelines, cost or scope could be somewhat daunting, but furthermore, changing any one of those aspects will have a significant impact on the other two and that will ultimately impact the quality of your application as well as the final outcome.^[iv]

Are you ready to take the plunge into the world of software application development, or have you already done so?  What are your biggest concerns before beginning, or, if you have already implemented a custom application, was it a success, partial success or a failure?  What valuable lessons did you learn?  Our readers would love to hear from you, please comment below!