In this Exercise, let’s start by reviewing Exercise 4 and build on what you discovered about your application development project, that is:

1. the people and their capabilities as well as the software, hardware and other resources required; availability of all resources;
   
2. the application’s complexity and Kill points for time, budget and scope;
3. the maintenance and support costs over time;
4. the anticipated launch date as well as the costs and timelines multiplied by a factor of 2 or 3 times.

What were your responses to the above?  Were you unsure or fairly confident about people’s skills, their availability and all the resources that might be needed?  Were you unsure or fairly confident about the application’s complexity, the effort it would take to build it, and also how much it could cost to support it over time?  Were you sure about the Kill points and would your key end user group agree with you?  Were you aware of how common scope change and bugs are in the application development process and how significantly they could impact the cost of your application and even double or triple your cost and/or time estimates? 

The more unsure you are of the information above, the more predictive it could be of a project at risk of failure or of running over budget, time or not meeting requirements.  From Exercise 4 and the Standish Group’s statistics, you will remember 68% of all I.T. projects fall under these categories.¹  Still, it is far better to know and accept what you don’t know now than to be in the midst of application development and losing sleep over the lack of progress you are making, the amount of time it is taking and/or the money it is costing. 

Given a substantial amount of uncertainty, you may want to reconsider your decision to Build a software application.  It may be time to obtain the services of a Software Development Business Analyst or a Solutions Specialist.  You may also want to look for an off-the-shelf solution or consider a blended approach. 

What is a blended approach?  If you can find a ready-made solution that meets many of your requirements, you may be able to plan internally or to contract for some customization immediately after the ‘off-the-shelf’ implementation that will ‘top up’ your application.  You may be able to get this additional development done internally.  Or, sometimes, off-the-shelf companies provide these services on a fee for service basis following implementation.  Another option could include contracting with a third party for the extra development to have modules or tools built to fill in some of the off-the-shelf software gaps.

Finally, one more question to consider - -  what is the driving force behind development of your  application?  If revenue or competitive advantage are crucial to your business, you may still want to spend the time, money, and effort on custom development according to Bob Laird, IT Chief Architect at MCI/Verizon.²  Weigh out the importance of revenue and competitive advantage to your business compared against the certainty or lack thereof of factors from Exercise 4, and summarized at the beginning of this Exercise. 

Are you closer to an answer?  Is a custom application still for you or have you reconsidered?  What was it that tipped the balance for you either way?

We and our readers would love to hear what you’ve decided to do and what was most compelling in your decision.

¹ The Standish Group Newsroom, Chaos Report 2009.  Boston Massachusetts, April 23, 2009.  http://www1.standishgroup.com/newsroom/chaos_2009.php

² Polly S. Traylor, InfoWorld, November, 2009.  http://www.infoworld.com/d/applications/build-or-buy-it-applications-676

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!

By now, you will have a good sense of who your key end user group is, and they will be on board with you in this endeavour.  You will also have a good idea of the features and user interface you would like for your application and this information has been documented and agreed to with your group, preferably, in electronic format.

Did you know that there is a spreadsheet tool that could help you calculate whether you should lean more towards whether ‘To Build or Buy’?  Try a workbook tool developed by Craig Borysowich, Chief Technology Tactician, Toolbox for IT:  “Using the Build vs Buy Decision Workbook” ²

As a proviso, when I started this blog series, the application I had in mind was web based and hardware independent, so some of the workbook questions were not relevant and skewed my results.  That said, it should be fairly obvious how your responses will impact the end results, so weight your answers accordingly.  Try the exercise a second time, changing some of your weighted responses to gauge the impact.  Regardless, the process of going through the exercise itself may give you reason to pause and reflect and to potentially consider some new factors.

See the page with a link to the worksheet just below.  Save the worksheet with the rest of your project documents for future reference and discussion.  Once this is done, and you’re ready to start, you may need to unprotect at least one worksheet.  If you’re using Excel 2007, click Review –> Unprotect Sheet or use Excel’s Help feature in other versions.  Click here for a link to the workbook page:  http://it.toolbox.com/blogs/enterprise-solutions/using-the-build-vs-buy-decision-workbook-12892

Note: Mr. Borysowich has detailed instructions in the use of the workbook via the link above.  Also, if you are  unfamiliar with some abbreviations, most can be found through Wikipedia.

As with Exercise 2 previously, you may want to complete this exercise independently to start, then compare results in a facilitated group session.  What were your results?  Were they similar or very different?  Were those differences a result of varying opinions, a lack of clarity about the application or something else? 

We would really appreciate your feedback about this exercise!  Let us know if it helped, if it didn’t and how.  Do you know of any other similar resources that could assist our readers?

In Exercise 4 next week, we will dig into some of the statistics and considerations to be aware of if your end results lean towards 'Building' your application.

 

^{________________________________________
2} Craig Borysowich, Toolbox for IT, ‘Using the Build vs Buy Decision Workbook’
http://it.toolbox.com/blogs/enterprise-solutions/using-the-build-vs-buy-decision-workbook-12892