Years ago I was an application programmer on a major computer and software conversion project at a large company. The ultimate goal was to execute a total cutover of all software and hardware at once, and then have all hands on deck to fight the inevitable fires as they came along. The fire fighting was intense — it lasted for nearly three months, and the company’s customer feedback was brutal.

From the trenches I saw a succession of project managers trying to keep this mega-conversion going for nearly two years as the project continued to escalate and grow larger. At the end of the project, at least three project managers had been fired.

Since then, the art and the science of project management has improved. In projects today, there is an almost universal adoption of the proof of concept, otherwise known as the pilot project. I am sure that some current project managers’ parents (and their mega-project war stories) had something to do with their children opting for smaller and more manageable IT projects.

Running pilot projects should be a staple in every manager’s bag of tricks for these three reasons:

  • Pilot projects enable stakeholders to see at an early stage if the project will be a success;
  • It is easier and much less painful to pull the plug on a smaller project at an early date — before too much time, money, and effort have been spent; and
  • If the pilot project was rough but the overall project objective is still good, it gives the project team and the manager an opportunity to adopt new strategies or to change their approaches.

Here are four best practices for small IT projects that managers should consider.

1: Remember the people aspects

One great thing about a small project is that, if it’s not going well, you can cancel the project and no one is so far invested that they won’t accept the decision, right? Not always. Benoit Hardy-Vallee, a former Gallup consultant, wrote, “Years ago, Gallup reported a key finding about human nature in the workplace: People have emotional needs, and if they are not attended to, the result is subpar performance and increased turnover. Even the best processes and systems are inefficient if the people who run them aren’t emotionally invested in the outcome.” He’s right.

If you pull the plug on a pilot project that isn’t working, you might not anger your boss or end user stakeholders, but remember the staff that reports to you on the project are also stakeholders — if too many pilot projects get pulled, you risk staff demoralization, and management begins to lose credibility.

2: Limit enhancement scope creep

Like large projects, small projects can quickly pick up extra enhancements that weren’t initially in the project scope. You should avoid this whenever possible. Enhancements to small projects while the projects are in progress increase time to complete and create more openings for project failure.

3: Aim for a 5:1 success rate

Your “win rate” on pilot projects should be at least five to one — anything less and staff and stakeholders will begin to question projects and methodology because everyone wants to be part of successful work.

4: Do post mortems on unsuccessful pilot projects

With today’s robust workloads, there is a tendency to just move on after a pilot project fails; instead, you and your staff then figure out how the issues can be avoided going forward.

An evolving art form

Even project managers who are masters at running pilot projects shouldn’t rest on their laurels, because small project management continues to evolve. What other best practices would you add to this list? Let us know in the discussion.