We've been specifying a rather large app for inventory management and customer sales. The scope is pretty large and the cost of development is making the suits nervous. I've been contending that it'll be just as painful to buy an app and try to customize it or worse yet, change our business to fit the software's capabilities.
What are your experiences with this? How can you pitch that building the app in house is better than buying a more inflexible solution?
How can you pitch that building the app in house is better than buying a more inflexable solution?
I can't. If it's not a part of your core business, contract it out to an expert in that field, or buy it off the shelf.
You do some shopping around to find one that fits the bill or nearly fits it. If need be, you get the folks who build it to customize it.
It has been my experience that the labor costs of building something outside one's core area tend to run higher in most cases than the cost to buy the pre-built solution.
Unless you have corporate plans to get into that area... that's a different story.
If you can justify that the application will gain significant competitive advantage then it is worth investing the time.
However hard it is for us to admit - sometimes it is better to start with an off the shelf solution. Perhaps you'll be lucky and find an opensource application that you can modify.
As well as the time that development takes, there is also the risk to be taken into consideration.
One has to properly compare and try the pre-built offerings before an informed decision can be taken.
If it's a core business function -- do it yourself, no matter what.
More info here. http://www.joelonsoftware.com/articles/fog0000000007.html
My experience: I became project manager of a content management system. The project, when I took over, was 4 years late and several million dollars over budget.
When originally considered, it had been decided to use Zope because it was open-source and "we can extend it to do what we need". It was felt that it would be cheaper to simply customize it rather than buy a proprietary product.
Unfortunately, it required too much customization for our needs so a contract was signed with the Zope corp. to customize it for us (Zope 3 was built based on our needs). Due to poor management, the project specs continuously changed so the Zope people were never able to give a working product to us.
When I came onboard, I was able to kill off the project and we ended up buying an OTS product that met most of our needs well enough that we could use it. Though they spent 5 years and millions of dollars on Zope, we never once got a product that we could even user test, much less put into production.
So, my advice is to ensure that your in-house version can actually be built in-house. Any outside assistance you may require needs to be heavily negotiated and the contract managed correctly.
You may consider using an open-source product and building upon it. Just be aware of the limitations it may have and how much work your in-house programmers may need to do to it. If you have the talent, time, and money then rolling your own will probably be better in the long run.
If you do buy OTS, ensure that it has good API and other developer support so you don't have to have all customization done by the company itself.
In my experience, the gut feeling of most developers is that we should build everything in-house, because
Usually, the argument put to management is that it's more flexible and we have full control over the software if changes need to be made in the future, and we have knowledge of the source code if problems need addressing. There is some truth and value to this point of view.
What developers often fail to realise -- I've certainly been guilty of this myself -- is that developing anything in-house will take time, this development effort does cost the company money, the first version will be riddled with bugs, and there are probably gaps in requirements that will take even more time and money in the future (although in your case it sounds like you're doing a good job of capturing requirements since the suits are already nervous at the size of the project). The prevailing industry view seems to be that, overall, this costs more than buying off-the-shelf, if such a pre-built solution can be found.
I think what the developers are really trying to say is that it's just considerably more fun to write a new implementation of some well-understood business function (as I imagine inventory management and customer sales is) than it is to trawl the Internet looking for possible off-the-shelf solutions and having the responsibility of evaluating them in some very dull weeks of testing. Enjoyment at work might matter more to the developers involved than the company's financial fortunes.
It depends on the software needs you have.
Since some companies specialize in applications for specific purposes you may find that their software although possibly expensive have overcome all the hurdles that you aren't aware of yet as well as considered many of the application interactions that you may have not thought of.
Sounds to me like you need to put out an RFI to the public domain. You may find that a vendor already has a solution for you, that actually does what you need, that can be deployed this month/quarter at a reasonable cost vs. developing an in-house solution.
If the RFIs come back with no good results, Then consider the in-house development as the best option.