Blueprint vs Prototype vs Pilot: Which Is Right?

By Marc J. Schiller

You’re in the early planning stages for a new project with substantial functions and a huge user base. A SAP upgrade, for instance, or a new customer service module. Whatever the project is, stakeholder sign-off and approval will be critical. And you’ll need more than formal design documents to make that happen.

Don’t misunderstand me—this hardcore documentation is necessary to build the system. It does the important work of expressing the technical requirements from an IT perspective. These dry technical documents, however, won’t grab your stakeholders’ approval and commitment. Doing that requires walking them through an experience of the system.

This is true for any technical building project.

Just imagine you want to build your dream house. You meet with an architect and he tries to persuade you to hire him but hands over nothing more than a list of raw building materials and the assurance, “Don’t worry, it’ll be great!”

Would you hire this architect? Of course not!

In a different scenario, he hands you an architectural drawing so you understand his overall plans. And then he provides you with a scale model of your new home. And afterwards he walks you through a 3D CAD rendering of the home he wants to build for you. With each increasingly detailed—and visceral—representation of your future dream house, you become more excited and engaged. And, at the end, when he asks for your business, you are even more likely to say, “Yes!”

Your stakeholders require a similar level of engagement before they sign-off on your projects. And, as an IT person, you have your own set of deliverables to elicit it: the blueprint, the prototype (paper-based or system) and the pilot.

They are four great options, but which get your stakeholders excited about your new project?

Before we address that question, let’s be clear about what is meant by each term: 

1. The blueprint: An architectural representation of the system. It gives a sense of the modules and functionality provided and how it all bolts together.

2. The prototype: Essentially, a mockup of the system, which can come in one of two forms:

2a. Paper prototype: It provides a non-functioning but visual walk-through of much of the system, and how it’d be experienced by users, using design screen mockups.

2b. System prototype: A slimmed-down version of the system where users can experience some significant percentage of the functionality, but with limited customization and dummy data.

3. The pilot: A working version of the system, often with just core functionality provided in vanilla form (but it can include more than that). The essential user functionality is in place, with real data, operating at one or a couple sites, and it delivers live user reactions.

Four Guidelines for Selecting the Right Option

Here are a few guidelines to how to decide which option is best for which situation. Obviously, there isn’t one right choice for all situations. Which of the above “tools” is required to drive the appropriate level of stakeholder engagement depends on a number of factors (not to mention the size of your available budget). There are, however, a few guidelines that I can share with you that you can use to figure out the right answer for your particular situation.

1. Every systems project with a price tag over $50,000 should have a blueprint.

It doesn’t have to be a complex and fancy blueprint, but it needs to visually show the basic components and functionality of the proposed system and how it fits into the existing systems environment.

Why $50,000? Because that’s about the cost of one solid full-time equivalent for six months. And it’s also about the entry-level cost for a real system. Could it cost less? Sure. Might there be cases where a blueprint isn’t needed because the project only encompasses enhancements to an existing system? Yes. But as a general rule, if you are about to spend $50,000 or more on a systems project that touches users, you should have a good blueprint to show them what they get. A blueprint is also useful as an expectation management tool for the project.

2. Paper prototypes are fine for new systems.

If you are implementing a system to provide users with new functionality or to cover an area where they currently have little meaningful systems support, then a paper prototype isn’t only sufficient, it’s preferable. The paper prototype gives the user community a real sense of what they will get, and it gives you a valuable tool for feedback and review before a full-scale build.

3. If you are replacing an entrenched system, you’ll need a systems prototype.

As much as the user community may want a new system (and that’s hardly a given), if the new system doesn’t give them everything they had in the past (and more) from day one, you’ll encounter trouble. And since we know it’s impossible to provide exactly that, you and your stakeholders will benefit greatly from a hands-on experience with a systems prototype.

The user community may complain at first about changing systems, but they will come around as they play with a systems prototype—and in the process they will see that things can be done a bit differently than they’re accustomed to without the world collapsing around them.

4. A major change requires a pilot.

No getting around it. If you are consolidating three different ERP systems into one instance of SAP operating in 10 countries across three continents, you are going to have to do a pilot. Too much can go wrong, there are too many competing interests, and there is no way everyone will be happy with the proposed system. So, a live working system and a small-scale pilot implementation will absorb the shock waves and pay huge dividends in the long term.