Over the last few blog entries I’ve written a lot about how *not* to do things. This week I thought I would share some advice I’ve given in the past on how to do a successful pilot project.
It happens with any new technology: after some early adopters report some initial success, organizations often want to dip their toe in the water by implementing some sort of pilot project using said technology. (Someone once observed that every organization wants to be the absolute first to implement a proven technology.) As with most things, there is a right way and a wrong way to approach a pilot project—often called a “proof of concept.” Back in the day when I taught software development methods, these are some of the hints we used to give people on critical success factors when considering a pilot project.
Criteria One: Pick a project that is large enough to be interesting. And by interesting I mean have economic benefit. Your pilot project can’t be something that executives wouldn’t notice even if you complete it: the pilot should have some kind of measurable impact on the bottom line, either by increasing revenue, decreasing costs, or some combination of the two. Forget “intangible” benefits: make them tangible and measurable. If the end result of the pilot is a new system that’s supposed to make customers happy (intangible) then it should also make them buy more (increase revenue), churn less often (reduce costs), recommend your company to friends (increase revenue) or in some other measurable way make an economic impact to your organization. Bottom line: If no one notices that your pilot was implemented, it’s hard to declare success.
Criteria Two: Pick a project that is small enough to be doable. “Build the next Facebook” may be your ultimate goal, but it’s not a good pilot (not even for Facebook). Again, the reason is somewhat self-evident: the biggest, meanest, ugliest and messiest projects are the ones that are more likely to fail—for a variety of reasons. Small projects similar in nature and size to those your team has done before are more likely to be successful. At the very least, they are easier for team members to intellectually justify trying a new technology on: if at any point the new technology proves to be unusable, the team knows it can fall back on methods used on prior projects and still get the job done.
Criteria Three: Pick a project that can be a stepping stone to a larger project. If the pilot project is a “one-off” that has no relationship to other more mission critical projects, even a completed implementation may not ensure that the pilot is successful (if the end goal of the pilot is to not only get the project done but prove the value of the new technology). The best pilots are those that might be considered “phase one” of a multi-phase mission-critical system, rather than some stand-alone project that can’t be leveraged in the future. They can have value as a stand-alone deliverable, but they might have even more value as part of a larger and more comprehensive system.
Criteria Four: Get help. We don’t train craftsmen by handing them a book and telling them to go build a project. All mature tradecrafts have the notion of some kind of apprenticeship program, where people skilled in the trade can watch over newcomers and take corrective action when necessary to keep the project from being an utter disaster. The same is true with new technologies like social media. Organizations that go buy a COTS or open-source social media package and try to implement it themselves *might* be successful, while organizations that work with a knowledgeable partner increase their chances of success by a wide margin.
No comments:
Post a Comment