Build, Buy, or Customize?

I’m often asked to help nonprofits define a technology roadmap – that is, figuring out how to migrate their business from a legacy system(s) to a new solution(s) and beyond.  Along the way, the topic of customizing (or “customising,” as some of my friends spell it) a system to address specific requirements often comes up.

End-users ask, “can we make changes to the ‘out of the box’ software to meet specific needs?” The answer is typically “yes.”

In response, technology directors and CIOs ask, “I know we can customize this, but is it a good idea?”

As with everything in the consulting profession, the answer is “maybe.”  It depends on the needs of the organization, timeline considerations and constraints of resource and budget.  Those who have been through large custom build projects (or “bespoke” projects, as some of my friends call it) know these can be labor intensive, prone to risk, and come with a cost.

There is no easy answer to the question of build, buy, or customize.  And, as organizations grow, most will require custom development somewhere in their systems architecture at some point.  I’d encourage these decisions to be made with full awareness of the implications and downstream effects.  Here’s some food for thought on the topic that will hopefully make customization-related decisions easier next time it comes up, whether with vendors, internal business stakeholders, or developers:

You keep using that word “customization”

I do not think it means what you think it means.  Be sure to understand the nature of any proposed “customization” first in order to avoid misunderstanding.

Customization (like “strategy” or “template”) means different things to different people, and its meaning can vary widely depending on whether you’re talking to an executive, end-user, or technologist.

While I typically assume customization to require development of code (as opposed to “point and click” configurations), here’s a few examples that regularly come up in these types of discussions:

• JavaScript to tweak the front-end or presentation of a website
• Complex configurations or business process changes that still use the standard software
• Development of new functional areas, objects, or tables within a system
• Custom reports or other information delivery mechanisms
• 3rd-party applications, mobile apps, or integrations
• Changes to the underlying product that can only be made by the vendor
• Hacks made outside of the API or SDK, or other unsupported alterations to the software (please, please don’t do this!)

Focus on Business Drivers and Outcomes

Get crystal clear on what users and stakeholders are really trying to accomplish.  Put aside the technology for a moment:  Can the desired outcomes be documented and quantified?  Often not, but the exercise of trying to do so is often worth the effort.  Often development projects (or entire implementations) are initiated without a thorough understanding of the anticipated business value of the project (a few perspectives on the topic of business value), making it difficult to sell the project internally or to measure its success after its completion (a few of my thoughts on this topic).

Document Requirements

Once you understand what users are actually trying to accomplish, get requirements on paper.  Ensure that you fully understand needs before recommending or even discussing customizations.  Set the expectation with stakeholders that undocumented requirements won’t be considered to facilitate a thorough analysis of the actual business process and outcomes to be supported.  Keep in mind there is often (significant) work effort in documenting requirements, defining a solution, and agreeing on an approach, typically involving multiple resources and iterative review of specifications for both for stakeholders and the development team (whether in-house or external).  But, you’ll be glad you have documentation in hand if the solution doesn’t work exactly as expected, or new requirements are added by stakeholders and end-users as development progresses.

Consider the Standard Product

Are you sure a standard product can’t support your needs?  Be sure to double check, and consider alternatives such as changing business processes.  Customization simply in order to preserve business processes without a greater outcome is a recipe for disaster (as is implementing software without changes to business practices).  Software implementations are largely exercises in change management, so keep in mind that change to end user roles and existing processes can rarely be avoided even with significant development work.

Development approach

How will the team approach development?  Agile?  Waterfall?  Their offshore developers “just take care of it, no problem”?  Make sure you understand how your development team plans to work, and think through how to partner in the process.  Micromanaging developers will frustrate all parties involved, but rolling up the sleeves and staying engaged in the development process in a structured way will prevent surprises and disappointment when the solution is delivered.  If nothing else, confirm the core aspects of the customization will be thoroughly documented or commented in the code itself.

Think Green

Once you’re clear on the nature of the customization (or at least the various options for addressing a requirement), consider the long-term impact.  Is there an impact on upgrades, either major or minor?  How will the customization be supported over time, through a maintenance agreement, professional services, or internal resources?  How will change requests be handled:  in-house or through a contractor?  There may be scenarios where a customization has zero downstream effect, however I am not aware of them.  Please post to comments.

Quantify the Cost

Customizations often take many more hours to fully design, develop, test, document, and deploy, even without the ever-present risk of “scope creep” if requirements are not well documented or understood, or if the project isn’t managed extremely tightly.  (Or even if they are.)

Ensure any work effort estimates include design, development, testing, training, and other “soft” costs (some of my thoughts on hidden IT implementation costs).

Consider Rolling Your Own

I love organizations that are interested in taking ownership of a solution, rolling up their sleeves, and building tools from scratch – in fact, this is the best approach for some organizations and programs.  Evaluate your team:  Do you have the right skills sets and capacity in house?  What about development environments and tools?  Training on Solution Developer Kit (SDK) and Application Programming Interface (API)?  Access to platform SMEs and/or a community of developers who can train and “mentor” your staff?

Be Aware of Precedent

Custom development often begets more custom development.  Do you want to start (or persist) a culture of customization?  This works great for a lot of organizations with developers, unique needs, and/or a a DIY culture.  That said, organizations often change over time and lose personnel.  Make sure customizations don’t introduce risks related to sustainability or business continuity in the long term.

For what its worth, I find that customizations rarely come to fruition after thorough evaluation of the investment vs. yield, unless they represent a significant mission-delivery or revenue producing aspect of the organization, or without a demonstrable return on the investment (e.g. significant cost savings).  Ultimately, as with most technology decisions, it comes down to value and balance between needs of different areas of the organization.