Have you compared results with your key colleagues and are you in agreement, to a good extent, on the key features and user interface that the application must have?  Are you in agreement about the short and long term costs, resources and timelines to implement?  Have you decided on a packaged, custom built application or blended approach? 

If you’ve been able to get agreement on the above, you have done exceptionally well and will make a great project champion!  (And prepare for I.T. firms to start asking for your resume!)  This initial phase can be the most challenging part of the project.  Once the decision is made, the project often develops a life (and a head of steam) of its own. 

If you have been unable to obtain agreement, you are not alone.  You may need to revisit the biggest stumbling blocks and see if you can come to terms.  Or perhaps you feel discouraged and tempted to abandon the project altogether – but don’t give up!  The work you’ve invested, despite lack of a clear outcome, is extremely valuable.  It should point you towards those key factors standing in the way of a decision on whether ‘To Build or Buy’.  Once those factors are isolated, you can focus on them specifically without other distractions.  

This may be a good time to share some of the remaining load with a Software Development Business Analyst or a Solutions Specialist.  With your invaluable, in-depth knowledge of the project and requirements, a third party can take over the reins and oversee final negotiations while you provide firm direction.  It may not be possible to get complete agreement, but when communication is open, issues are thoroughly researched and decisions are given alongside the rationale behind them, project participants may be agreeable to proceed after all.

To sum up this Blog Series, you may have realized that the more you research, the more complex it may be to decide whether ‘To Build or to Buy’ a software application.  But really, that’s a good thing! 

It’s far better to appreciate the complexity now than to potentially have a VERY EXPENSIVE, unknown, unused and unwanted application that keeps rearing its ugly head during your budget discussions for years to come. 

Whatever your choice, we wish you much success.

How have your productivity projects gone in the past?  Do you have any further advice for our readers?  Please comment.  We’d love to keep the conversation going!

This Exercise assumes you are leaning more towards Buying an off-the-shelf application rather than Building one.  Still, if you are considering the latter, you may be interested in off-the-shelf application considerations....

Take a moment to reflect back on your application’s key features and user interface from Exercise 2.  How many key features did you document?  Are they all of equal, #1 importance?  Can any be reduced in importance or set aside for now?  It may be exceptionally difficult if not impossible to find a suitable off-the-shelf application if all of your requirements are an equally high, #1 priority or #2 for that matter.   Realistically, you’re going to need to consider prioritizing your requirements and to look for an application that meets the most important priorities for now.

Imagine your requirements in a bell curve like the graph shown below.  On a scale of 1 to 5 with 1 being Highest and 5 being Lowest, the majority of your requirements should fall in the 2 to 4 range. 



Using your results from Exercise 2 or the To Build or Buy Worksheet Tool from Exercise 3, try, as best you can, to prioritize your requirements using a bell curve type of distribution.  In a spreadsheet, list the features in rows going down and the priorities in columns going across.  Put a number 1 in the appropriate row/column intersection.  Then, total your numbers for each column.  You can eyeball your results to roughly evaluate the distribution.  Alternatively, you can take the total number for each column divided by the total number of all requirements and calculate the percentage. 

If your results are very skewed from a bell curve type of distribution, review your list of priorities again.  Go through this process with your key contacts.  Chances are, they may see things from a different perspective and can help you ‘normalize’ the curve. 

After you have a more even bell curve of requirements, your product research begins.  Search engines, blogs, and industry colleagues may provide some promising suggestions.  If your search turns up few/no results, your I.T. department, software product or consulting companies or a Software Product Specialist may be able to point you in a helpful direction.

At the end of the day, if you find an off-the-shelf application that meets more than 75% of your highest priority requirements (i.e., #1 – 3 or 4) this may be most cost effective for your organization in the long run.  Mark Lutchen, head of Pricewaterhouse Coopers IT Effectiveness practice and former global CIO said “Everybody knows that the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance.”¹

If possible, evaluate more than one off-the-shelf application before narrowing down your list.  Product webinars or one-on-one demo’s could give you a good sense as to whether an application will meet your highest priority requirements.  Invite key colleagues to attend a follow up webinar or demo if you find a promising solution or two.  Include your I.T. staff in the process and the decision making if implementation of the product will impact them in any way.  Product brochures may also contain helpful information to assist you in doing an initial comparison of product versus product.  Also document if the company offers a pilot, risk free trial or other offer suited to your needs.    

Once you have obtained a shortlist of solutions, compare them against each other based on your #1 - #3 (4) priorities.  Which is the best fit?  What is the initial cost and effort to implement?  Remember to include the costs of documentation, training, support and even software and hardware updates following implementation.  Those maintenance and support costs can really add up after your initial purchase.

Finally, it bears mentioning – again – to try and limit the #1 or highest priority requirements that you and your colleagues may have.  (Do you sense this is a recurring theme in this type of endeavour?)  Not reigning in the scope of what you absolutely need could end up being cost, time and/or resource prohibitive and your application may never see the light of day....

Minimizing the number of your highest priority requirements can be a major challenge.  Have you gone through this process?  How were you able to manage it?  If you’re struggling with it, perhaps we can help.  We and our readers would love to hear your words of wisdom on this difficult, but ultimately rewarding process.

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