Blueprint, Prototype or Pilot: Which Is Right?
You’re in the early planning stages for a new project with substantial functions and a huge user base.
An 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!
But 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.
And, with each increasingly detailed—and visceral—representation of your future dream house, you become more excited and engaged.
Then, at the end, when he asks for your business, you are very likely to say, “Yes!”
Your stakeholders require a similar level of engagement before they sign-off on your projects.
How to Create Visceral Stakeholder Engagement with Your IT Project
As an IT person, you have your own set of deliverables to elicit visceral stakeholder engagement: The Blueprint, The Prototype (Paper-Based or System) and The Pilot.
Before we discuss which deliverable will get your stakeholders excited about your specific new project, let’s get clear about what we mean 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
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.
Another reason to use a pilot when implementing a major change, as opposed to just relying on a prototype, is that a failed pilot can be shelved or declared a stepping stone to the next version, but a full-scale implementation that goes wrong on the first rollout can kill your career.
Pay Attention to Your Stakeholders
The choice is yours, but make the choice with your stakeholders. It’s up to you, as the IT leader, to decide which of the aforementioned options is right for your project, but I suggest you include your stakeholders in the decision.
Consider sharing the above guidelines—and any other relevant information—with your stakeholders during an early steering committee meeting to help make the decision about which user experience tool to use in the project. Not only will it be easier to get the project funded but when it’s their choice, they are more likely to emphatically support it. And their support is vital to its eventual success.
