Tuesday, 10 August 2010
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!
[i] The Standish Group Newsroom, Chaos Report 2009. Boston Massachusetts, April 23, 2009. http://www1.standishgroup.com/newsroom/chaos_2009.php
[ii] Polly S. Traylor, InfoWorld, November, 2009. http://www.infoworld.com/d/applications/build-or-buy-it-applications-676
[iii] Polly S. Traylor, InfoWorld, November, 2009. http://www.infoworld.com/d/applications/build-or-buy-it-applications-676
[iv] Project management triangle. Wikipedia. Last modified June 15, 2010. http://en.wikipedia.org/wiki/Project_management_triangle
Wednesday, 12 August 2009
From the RN Journal, Jennifer Predhomme (BScN) reports on the effects that have been shown in testing PDA use in the Hospital setting. A great analysis from both sides, including the identification of risks of introducing a PDA program into a hospital. Her findings may surprise you:
Wednesday, 08 July 2009
This past week I was honored to be in attendance at the 3rd Annual Society for Prehospital Educators in Canada's (SPEC) AGM and Conference in St. John's, Newfoundland.
Great Big Solutions continues to be a proud supporter of this Society and the annual event, in its continuing efforts to promote national collaboration amongst Prehospital educators.
I was privileged to meet many new faces, even those of which we have been working with over the years and hadn't had the opportunity to meet in person until now.
One of the most prevalent topics of the conference was Simulation training. So many of the educators around the country are expanding their use of Simulation in their programs to enhance the skills of their students. This topic at the event spanned everything from the use of Stress Innoculation and Cortisol testing, to Clinical Simulation Centers in hospitals, to the evaluation of student judgement in the Clinical Setting using high-fidelity simulation.
Simulation and its use in Prehospital programs has been debated recently, especially in discussions relating to the national competency profile for Paramedics in Canada. There seems to be a push towards more Simulation experience as a tool for students to capture experience in high-risk, low-frequency skills. With all of the evidence for simulation being proven as an environment that can enhance a learner's skill set in this area, it becomes (to me) a question of WHY it hasn't been as widely accepted as a proven tool in the field of Paramedicine training; when it comes to program budgets and investing in the technology, simulation time (%) allotted to Paramedic programs as compared to other Health Science fields, frequent high-fidelity experience to be recognized equally as less frequent experience on patients in the field.
We are interested in opening up this conversation to the Educators of all Health Science programs across the country, as in the end it affects all of us. The more information and opinions we can share, the more changes we can make in the end.
Please comment if you have something to share about simulation training. Are there research projects that you think would be advantageous to perform in order to address some of the concerns from the other side?
My thanks again to the members and executive of SPEC for including Great Big Solutions in their recent event.
Thanks, and happy tracking!
Thursday, 02 July 2009
The Canadian Pharmacy Technician Educators Association (CPTEA) invited Great Big Solutions to speak about CompTracker at their recent conference at Fanshawe College in London, Ontario, on June 20, 2009.
Rod Wolchyn from Great Big Solutions was on hand to present the concept of electronic student tracking, and answer any questions that might arise from the Educators in attendance.
Educators representing about 30 Canadian colleges and universities were present, from every region of the country. The instructors from our existing CompTracker Community (currently using CompTracker) commented on how their colleagues' programs have benefited since using our software.
We will be arranging demos of the latest version, CompTracker 5.0, as soon as its available late this summer, so if you'd like to have a sneak peek just give us a call!
If you think your industry might benefit from using CompTracker and would like us to speak at your school or Conference, please feel free to get in touch and arrange a presentation!
Wednesday, 10 June 2009
SPEC Conference St John's, June 30 - July 3, 2009
Great Big Solutions and CompTracker are once again proud sponsors of this year's event. I had a great time mingling in Victoria last year, and hope to see you this year also!
Speakers include leading pre-hospital educators from across Canada from B.C. to Newfoundland and Labrador. Presentations include:
Kathryn Fraser from Great Big Solutions will be in attendance from July 2-3, in case you have burning questions about CompTracker or want to grab a coffee!
Download the brochure for more information and how to attend: