Building Valuable Pilot Projects

By Bruce Johnson

A pilot/prototype project is the most effective way to gain support, endorsement, and funding for data warehouse/analytic efforts.  It provides an opportunity to demonstrate success, value, and proficiency.  Yet, the success of a pilot project is dependent upon several key characteristics.

In this article we are going to outline what a successful pilot/prototype project would look like, define what success means, and outline some of the key characteristics required.


Pilot Goals

We build pilot projects for data warehouses to gain the support, endorsement, and funding to further build out solutions.  Thus, it is important to make sure pilot projects keep centered on the value and goals that will enable the greater solution to be charted.  Here are a few key target goals of a pilot project:

  • Gain trust – build faith from leadership that you are able to do what you say you can do and that it will have value that is meaningful to the company.  I have talked to many IT resources that have stated firmly that they want nothing to do with sales.  Those same resources often ask me why the companies I work for have always needed and committed resources to data warehouses.  It is all about helping them see a strong value equation.  Most business leaders are savvy enough to know that technology for technology sake is foolish.
  • Demonstrate value (actual business usage) and cost effectiveness.  If a pilot cannot demonstrate these characteristics, there is little to no hope of building anything more than that – this is exactly why IT focused pilots are so frowned up and rarely go further than the pilot stage.
  • Demonstrate proficiency – When going forward to ask for funding for greater efforts, leadership wants to have faith and credibility in those that are seeking endorsement.  A pilot provides an opportunity to impress leadership with knowledge, skill, and ability to implement (this is sometimes lacking in IT – my focus for most of the last decade has been in healthcare and there is a strong lack of confidence in the ability of IT to deliver valuable, cost-effective solutions.
  • Demonstrate architecture – This is one of the most frequently skirted key goals.  Unfortunately, ignoring this goal can have dire consequences for all future goals and plans.  What happens when people build quick and dirty pilots that have no founding architecture?  Typically, those who benefit see that they don’t need a solid/sound architecture and because they received value quickly, desire that you just keep building – not to mention the fact that it was cheap and now a much larger price tag is being proposed to do more.  A seasoned veteran will be able (not that they will) to clearly articulate why such solutions would result in inconsistent data, fragmented tools and solutions, and limited future flexibility/scalability.  Those that challenge this typically just haven’t figured out how to do a partial architecture build out.  Long-term organizational planning success – for larger efforts are significantly impacted by this.
  • For healthcare specifically, it is important to demonstrate security and privacy of data and applications.  Many, if not most, healthcare data warehouse pilots ignore sound security/privacy design in their solutions.   From discussions with several who have done this, it seems the thought is something like “that is something we can build into the real solution once we get approval to go forward”.  While there is some logic to that, there is tremendous exposure in not having this foundational element in place (it doesn’t have to be mature or the final solution, but it must protect what you are building).  If the pilot is loved and excitement generated, it would be hard to imagine a worse feeling than going for full approval to go forward only to have security/compliance shut the project/effort down and suggest a completely different approach (this seems to happen a lot).  If you have read my prior columns, you will recall how I strongly recommend engaging and working closely with security/compliance officers in all planning and building efforts so that when any efforts go through to leadership there are no surprises.
  • Demonstrate development approach that you propose taking (a project that builds upon a framework completely different than the solution you will propose will generate user excitement, but IT leadership must question the reasoning and feasibility – what have you proven).  As organizations take a more formal role in governing and overseeing the development of all applications, the scrutiny paid to each plan grows.  As data warehouses themselves are traditionally wrought with failure and overspending, particular attention will be paid to these efforts.  Being able to clearly demonstrate and articulate your approach and why it is so effective becomes very important.
  • Pilot tools – Choosing tools that can grow with you and effectively support a pilot are important.  Too often organizations focus on large tools/technologies that take a lot to get up and running (require strong frameworks and development learning).  I would suggest starting with small, simple tools that are known to be effective (like Crystal Reports).  Keep in mind that a lot of vendors will offer their tools for free for the pilot in hopes that a successful pilot will translate into a purchase.  If you have a strategic vendor already established in your organization and depth of tool knowledge/experience, consider those tools (as long as the need correlates to something that will have significant value to your customer with ease of access and navigation).


Picking A Pilot

One of the biggest challenges most resources have in picking an appropriate pilot project goes back to focusing on what you are trying to proof.  Here are some considerations to target when looking for something that will be effective:

  • Identifying a champion that is an early adopter – make sure you target a pilot that has an active, respected champion.  This person should be known for driving things through, having a positive approach, and communicating well.  An early adopter means that they do not shy away from new/novel ways of looking at things, but more embrace learning and experimenting.  If you give them something of value, they will make sure everyone knows it.
  • Pick low hanging fruit – When investigating opportunities for pilots, there are seemingly endless use cases that can come up.  Make sure that you don’t go after high-value or high-visibility efforts that have major roadblocks, like: data is not captured, data not of high-quality, security/privacy issues are major, solution required is very costly and time intensive.  As simple as this seems, it is very common and exactly why so many pilot projects get started, but never finish.  Don’t let priorities occur by those that have the loudest voice or carry the biggest stick.  You definitely want to target those individuals, but not just take whatever they ask for (you probably won’t be able to satisfy them).
  • Ideally a pilot that satisfies multiple needs to multiple organizations will have more value than a solution for one person.  While you will have one person excited about it, you have now isolated what you have done to your champion.  With a few minor modifications to planning and approach, you can add a tool that can bring value to many.
  • Make sure to evaluate the level of technology depth.  While reports, dashboards, and scorecards make great pilots, occasionally a data mining effort might be the most valuable.  The key is to consider the ability to target something that you can demonstrate success within a matter of months.  Remember to focus on an interface that is easy to navigate and understand – when demonstrating success of an effort such as this, you will have an audience that will be able to see value and future, but if the demo is too technical, you will lose them right away.  If it is too flashy, it will seem like a sales pitch or significant budget request.


End Results

When a pilot project is completed, there should be a final presentation to the leadership that both endorsed and funded it.  A successful pilot will be easily apparent by these characteristics being clearly evident in the presentation:

  • Establish and socialize goals/plans, approach, and accountability – then deliver.  Make sure your champion understands what you recommend and is keeping your progress in front of the key leaders that will eventually decide whether your larger effort can go forward.
  • Value – make sure to keep time in the plan to establish specific examples of value and demand before you go to leadership to close out the pilot and ask for support/funding for next steps.
  • One of our most effective pilot efforts is comprised of:
    • Providing a solution in only a few months that demonstrates an enterprise data warehouse framework loaded with real data
    • Having targeted use cases that directly provide specific value to urgent needs (like monitoring 30 day readmission rates)
    • Building a technology framework that is scalable and flexible – will support initial pilot, but also grow to support many other needs (this framework/architecture is the secret sauce that enables all success)
    • Formal security/privacy built into the pilot with reports that identify all queries and who has accessed what data
    • Provide a query interface that others across the organization can use to test simple hypotheses about grouping of data (like identification of cohorts across diseases)



A successful pilot project is a critical step in building a program/approach for larger solutions that have broad value to an organization.  If I had to pick one focus to remember in choosing, picking, and building a pilot, it would be to target a high-value need that is all about providing the business with something they need.  This is often best accomplished by using simple technology tools, not trying to build a flashy/sexy solution, but a functional, easy to use one (few options, easy flow/navigation, targeted audience of early adopters).  Clearly articulate what you are going to do and then be on time and on budget – do what you said you would do.

About the Author

Bruce has over 20 years of IT experience focused on data / application architecture, and IT management, mostly relating to Data Warehousing. His work spans the industries of healthcare, finance, travel, transportation, retailing, and other areas working formally as an IT architect, manager/director, and consultant. Bruce has successfully engaged business leadership in understanding the value of enterprise data management and establishing the backing and funding to build enterprise data architecture programs for large companies. He has taught classes to business and IT resources ranging from data modeling and ETL architecture to specific BI/ETL tools and subjects like “getting business value from BI tools”. He enjoys speaking at conferences and seminars on data delivery and data architectures. Bruce D. Johnson is the Managing director of Data Architecture, Strategy, and Governance for Recombinant Data (a healthcare solutions provider) and can be reached at

Free Expert Consultation