We are about to wrap up a pilot project for the next generation of our bike sharing system (check it out at bcycle.com) and I thought that it might be a good time to talk a little bit about how and why we use pilot programs in the Innovation Center. One of the core tenets of our innovation process is that we prototype and pilot early and often. We’ve found that overdeveloping a pilot before real people get to check it out can actually kill the innovation process, and cause us to miss the most critical insights—so sometimes even an 80% solution is too much! Our very first public bike sharing program took the national stage last summer as the largest bike sharing event in U.S. history. What we learned there paved the way for the emergence of bcycle, and a new set of pilots to get bcycle off and running. Through the course of these big, real-life experiments we’ve learned a lot of salient lessons for managing pilot projects. We know there are a lot of folks out there innovating around health and hey, we like to share… so this is how we roll. Give it a read and let us know what you think.
Define success – what is the goal? Ask your sponsor and your team, “Why are we undertaking this project?” I used to work for a guy who’d often say, “What does success look like?” Defining success is about clearly articulating desired outcomes. In the innovation process it’s not just about being on time and under budget, but also about pushing the envelope a little further, closer to the next big thing. If your environment is as fluid as ours, expect the unexpected. You will often have to remind people what to focus on. Change is inevitable, keep your stakeholders abreast of it and manage their expectations. When we first started all this, success was defined as a functional bike sharing system for our employees to use to get from building to building, to get a little healthier and have a little fun along the way. The success of Freewheelin led us to push the envelope a little further . . . and paved the way for bcycle.
Measure it – if it gets measured it’ll get managed. Once you can articulate what success is figure out how you’re going to prove when you’ve reached it. Then, like Jim Collins says, confront the brutal facts. If your metrics point to a less than desirable outcome, make a change, and be decisive about it. Not all projects are created equal. Your measuring processes may be manual at first, this is ok. If and when the project allows for it, automate! Often with a pilot project you’re not going to know what to measure up front, so this process is iterative. Revisit this often until you get the right information at the right time.
Identify the right stakeholders – especially those with skin in the game. This should be obvious but quite frankly doesn’t always happen. With your internal stakeholders communicate progress often and celebrate the little successes. Build momentum. Get psychology on your side. Give your external stakeholders (customers or users) a voice too. They very well may come up with a better way to use your product or a better product altogether. Be open to this. We had stakeholders ranging from our customers, vendors, business partners, to our executives. Each had to be addressed differently. Doing this right in your projects will pay dividends.
Collaborate – keep the core team small. If you have too many people it can get messy and noisy. Once you’ve got ‘em: collaborate. Avoid those awful, poorly planned meetings. You know the type; you might have attended one today! We kept our status meetings to no longer than 30 minutes and held them first thing in the morning. This helped with focus and cohesion. Let the team use their day to get the real work done (imagine that!) and solve problems. Use Twitter for daily happenings (how long does it take to type 140 characters anyway?) and a wiki to capture lessons learned.
Facilitate decision making – if the project manager isn’t making the decisions he or she needs to have a hotline to the guys and gals that are. If you’re one of those guys or gals, be prepared—and get ready to be on call. My suggestion: get a capable PM and allow him or her plenty of latitude but set clear expectations on when and how to escalate issues.
Build float into the timeline – something is going to go wrong. Murphy is omniscient. I won’t buy a car without an airbag, and I won’t build a project schedule without some slack—both might crash. In all honesty, the probability is much higher if I’m driving. :)
Streamline – if your project management processes and procedures, like how to document, are too tedious, cumbersome, or time consuming you need to get new ones. We’re exploring the use of microblogging to capture meeting minutes—which I think is a brilliant use of a new technology to spice up an old chore (Use Twitter Search for #hcoc to follow the stream)
Lastly, stay flexible, roll with the punches, and keep pushing that envelope—you never know what you might stumble upon!
How do you use pilots in your business? We’d love to hear what you think…
Popularity: 1% [?]
