Friday, December 9, 2011

Lessons Learned from Apple, 3M and Johnson & Johnson


By Angela Childs

Three companies that changed the conversation.
 
What do these three companies have in common?  They all have invented products that dominate the space.  When you have a cut, do you ask for an adhesive bandage?  If you did, you'd probably hear "you want a what?"  I know I'd ask for a band-aid.  Their brand name is now what we call bandages regardless of who makes them.  Another example - there has been some progress made by all those other companies to get us to call adhesive notes “sticky notes” but they’re post-it notes and they will always be post-it notes.   I could go on with other examples, but we get it and this is already a long post.

Apple has created a similar phenomenon...twice.  In the MP3 player space there are iPods or…everything else.  For tablets, you have the iPad and…everything else.  Whichever side of the Apple argument you fall on, love them or hate them, no other manufacturer has been able to rise above the noise of a competitive marketplace. 

Where am I going with this?  Would you believe it’s to that old build vs. buy conversation?  Yep, I’m going there.   

When you think "Should we just do it ourselves?" what should you consider?

When the topic is developing software, my mind always jumps to the future first.  I start thinking day-forward, after implementation.  You might think I’m wondering what the burden of end user support will be on the IT staff, but that’s not number one on my list.  The first thing I think about is on-going development and not just enhancements and the inevitable changes required to stay in step with changes in business over time, but the pure technical development required.  If there were never any enhancements and you never had to make changes to the core requirements, you’d still need to update what you built to stay compatible with changing operating systems, databases, browsers, etc. 

After weighing the risk of day forward compatibility development, I leap back to the beginning.  To develop something properly you need to analyze the business requirements, develop a scope of work, estimate the time requirements, assign costs, then get agreement internally on cost and scope.  This front end work requires a set of skills that is different from that of a developer – more often than not.  Now we’re developing a team, ideally an experienced team, all working on this project. 

Next I’m on to the development itself.  You have development tasks, project management, change control, risk mitigation, testing, documentation, implementation, and training.  If this is development on something that’s not directly related to your core business – do you know enough to know what you should be worried about in terms of risk?  I haven’t even gotten to IT resources for day to day end user support.

When we really start to break down the concept of build vs. buy, we go from the question “Could we develop this ourselves?” to “Do we want to develop this ourselves?” 

It’s a similar discussion when it comes to whether or not a backlog scanning project should be done internally or outsourced.  Like with a software development project, it boils down to resources, time, cost and risk.  You need to have people that can do it, the hardware and software required, enough time available, a person or persons that can manage the people and the process, and a quality control mechanism.  What you get back from the effort is related to what you put in to the effort so you need to make sure you have a good process and good controls.

So what does this have to do with the beginning of this post?  Commit to what you do and do it really well.  We need focus and we need to be thoughtful.  We need to look at everything that we could do and then pick what we should do.  We need to set ourselves up to succeed, not sprinkle the path with pitfalls.  We won’t all cause a paradigm shift, or develop a product that becomes the next genericized trademark, but we can have products and services that are competitive and highly regarded; and we can enjoy that success.  

So what’s the answer - should you build or buy?  Seriously?  Are you joking?  Did I not just blather on for almost 700 words explaining that this is not an easy yes/no.  

Having your own build vs. buy dilemma?  Contact us and we'll help you weigh the pros and cons.

Go ahead, give us your biggest problem.

With offices in five states, more than 500 installations and document scanning facilities that convert over five million pages a month IOS knows what it takes to solve your document challenges.

Talk with our experts

Share this post