The landscape is changing. In recent years, we’ve seen explosive growth in the need to analyze massive volumes of information from disparate sources both structured and unstructured.  Say you recently helped stage an environment from 100 data sources and 10 source systems for an estimated audience serving 10,000 users. Ten weeks later, due to the sudden success of your integration efforts many new demands are in your backlog, your audience has quickly grown to 100,000 users. Users need help interacting with and handling the new data. Three months after that, the same thing happens—and year over year, you find your user size is growing at a monumental pace.

It’s time to evaluate your infrastructure’s maturing needs.  True or not, one fact is incontrovertible, a data hungry audience needs access to a bewildering array of just-in-time data, analysis, aggregation/disaggregation tools that intersect along a multitude of points (e.g. demographic, geographic, psychographic, behavioral, product related, etc.). Worse, it’s not enough to just house the data from your in-house information system and be able to query it. You also have to be able to generate a variety of data files, summary tables and queries that will satisfy from the most generic to the most customized requirements of an end-user/consumer/client.

You are now at a point where your users are crying for their daily interactive BI dashboards and you are not sure if this new initiative can get off the ground on time and on budget.  Enter the Feasibility Study. This assessment is designed to provide a foundation for a roadmap, help identify potential risks, and provide insight and support in guiding next steps for your project. It would also allow a development team to review timelines and needs for the project. Moreover, it should put everything into perspective, stimulate internal discussions and at a minimum organize or orient teams to move in the right direction.

A typical feasibility assessment for a BI dashboard evaluates a build vs a buy scenario.  Depending on the size of your user community it may make more sense to build your BI tool in-house vs buying it from a major BI vendor.  For example, when faced with a target user community of 500,000 consumers, it may be economically infeasible to purchase a BI tool due to the per seat costs of licensing.  Thus, a base hypothesis in this type of feasibility analysis would only take an in-house build scenario into consideration rather than propose candidate BI solutions from other vendors as in a typical study.  As a result, not all feasibility assessments are created equal and a quality study should necessarily be preceded by a smaller scale pre-assessment in order to establish high level requirements.

Assuming the above in-house BI development scenario was the case, the following high level bullet points would cover such a feasibility study:

Schedule Feasibility

Depending on timeline requirements, propose a project plan using Waterfall, Agile, or a hybrid with a base timeline and rough project phases.  Pay particular attention to managing the backlog of requirements as it may be critical to project success, particularly in a time-constrained Agile centered project.  Another key to success is resource availability calculations and capacity planning. A high level risk assessment and mitigation plan also may be done here.

Technical Feasibility

• The data model recommendation is in this portion of the study. A common question here is whether to create a separate BI “reporting” database or one integrated into the corporate database. Next, decide on the most appropriate data model/schema congruent to the schedule, functional, and non-functional requirements of the project.
• A front end JavaScript framework would be part of the technical recommendation of the study. Criteria such as internal expertise in a particular framework, ease of coding (timeline constraints), and performance would be evaluated.
• Cloud vs on premise considerations should also be covered here.
• Quality assurance, deployment, and migration considerations should also be part of the scope of the study. In a large-scale, complex, and time-restricted project, the QA team is key to getting iterative releases out quickly and to do in parallel in order to free up some time in the development lifecycle.

Operational Feasibility

There are a number of considerations in the study when assessing how the new BI Dashboarding tool would affect operations, in part and as a whole, i.e.:

• Process – How the build will affect end users
• Evaluation – Benefits to the user community; how feature releases will be rolled out
• Implementation – Resourcing capacity requirements; what expertise is available or not, how this project impacts other projects in process
• Resistance – Consideration of change resistance for each release; what areas and individuals will be most resistant
• Strategies – Do new processes or structures need to be reviewed or implemented in order for the internal development to be effective?
• Adapt & Review – How much time the organization needs to adapt; how it will be reviewed and monitored, how change requests will be handled.

Economic Feasibility

The following budgetary aspects for an in-house build are of note:

• Hardware/software upgrades
• Fully-burdened cost of labor (salary + benefits)
• Support/maintenance costs for the application
• Expected operational costs
• Training costs for users to learn the application
• Costs to train developers in new/updated technologies
• Cost of recruiting/hiring developers in new/updated technologies

Political Feasibility

The following factors contributing to the political feasibility of a BI Dashboard project should be reflected upon:

• The presence of a (“strong”) project sponsor or champion has an impact on the probability of whether the project will be successfully realized
• The degree to which the final BI Dashboard will fulfil the requirements of the user community has an important impact on overall user reception (acceptance vs resistance)
• How well the project would be managed and realized (on time and on budget) would have an influence on the timeliness and quality of future releases and extending to future viability.

Overall Feasibility Score

• A feasibility assessment score with a rough order of magnitude should be presented based upon relative risk found in each feasibility section of the study (e.g., technical, schedule, operational, etc.)
• Allotting a single score may be a politically risky (and controversial) exercise in itself. As such, it should be established and communicated that these scores are highly subjective and theoretical and only represent the current situation. Should any criteria change, for example, expertise through resourcing, re-scoping of requirements, and so on, feasibility should change accordingly. An overall score should be taken only as a general guideline to assist in determining feasibility and project success. Several other factors uncertain, unknown, unforeseen or unaccounted for may further influence project feasibility.

An effective feasibility assessment can do more than just help provide justification and talking points to executives on selecting which projects to greenlight. Managers involved in a feasibility study can actually reuse much of the same foundation information to obtain valuable insight and to help support and to shape the entire project planning process.

Have you faced a ‘build versus buy’ scenario before, specifically with respect to a BI solution?  Share your top tips and recommendations by commenting below – we would love to hear about your experience!  If you are looking for assistance with a feasibility assessment, please contact our BI experts at NewIntelligence at info@newintelligence.ca.