Pilot projects are a convenient and cost effective way to prove a project delivery concept, or to prove the value of new tool or process to an organization. Pilot projects can be very effective in achieving these goals if they are planned and implemented properly. There is an old riddle that goes like this: Question: "How do you eat an elephant?” Answer: "One bite at a time”. Pilot projects are the way to take that first bite. If the elephant doesn’t taste good, don’t invest in the whole meal.
Don’t confuse a pilot project with a prototype. Prototypes are used to prove a concept, usually a technical or commercial one, while pilots are used to prove the delivery method. The concept cars auto makers show at car shows are a good example of prototypes, while the 10 Apollo missions which preceded the successful moon landing of Apollo 11 are good examples of pilot projects. Pilot projects may be used to prove technical concepts, as were some of the Apollo missions, but there is no hard connection and the goals of the pilot and prototype are different.
Pilot projects certainly aren’t suitable for every project. Not every project needs a pilot and not every project can be helped by one. The first step in defining the pilot project is to determine the need.
Determining the Need
Are you going to be implementing a new methodology, or new process? Will you be organizing, managing, or monitoring the work in a way that is radically different from the ways you have used in the past? If the answer to any of these questions is yes, you may have a candidate for a pilot project. Is the successful implementation of the project’s goals mission critical? Is this a project or program that your organization cannot afford to fail? If the answer to these questions is yes then you probably need to use a pilot project to refine your delivery techniques so as to mitigate the risks of failure.
To better illustrate my point, let me give you some examples of where pilot projects will help. The implementation of a new software development methodology is an example of an opportunity for a pilot project to help. Software development methodologies all have standard processes, procedures, and standards but their implementation in individual organizations will call for the customization of these in order to better fit the organization. Either that or the organization must re-invent itself to better use the new methodology, a difficult feat especially if the organization wishes to use more than one methodology. A pilot project organized for this purpose can teach the implementation team how to alter the stock processes, procedures, and standards to make implementation more efficient.
Implementing a new process or processes can also be helped by a pilot project. CMM and CMMI require a standardized set of processes for developing and managing software (regardless of the methodology used to develop it) and the programs are specifically tailored for pilots. CMM and CMMI level 2 call for the use of the standardized processes while level 3 call for their use across the organization.
Planning the Pilot
Your pilot should start with the same project management tools as a normal project. It should have a Project Charter, a Scope Statement or Statement of Work, a schedule and all the other project management tools used to manage a project. The goals and objectives in your Project Charter must include those that are specific to the pilot. These goals and objectives have to do with the learning from the pilot and their implementation into the next project. A valid goal might be to conduct a Lessons Learned for each phase and pass these along to the next phase and to the next project. Remember that the purpose of doing the pilot is to learn how to deliver the next project smoothly.
The work that you set out to do should include conducting the Lessons Learned sessions that are included in the projects goals. Sessions should be conducted at each project phase, but don’t forget that one of your pilot project’s goals will be to improve the performance of the pilot to test out the corrective measures and adjustments from your Lessons Learned so you may want to conduct them on a more frequent basis. Let’s take our rollout of CMMI level 2 processes as an example. We’ve singled out one group in our organization and one process area for our pilot and we’ve divided the implementation into phases (training, defining the processes, implementing the processes, etc.). We will need Lessons Learned sessions after each phase but we may want to establish an additional Lessons Learned after the first training session, or after each training session. We may also want to schedule Lessons Learned after each process is defined and after each implementation, or just after the first. Remember to plan for the archival and use of the lessons by the next project. You aren’t planning the next project but the lessons must be stored where they are easily retrievable and readable by the next project. This may influence your choice of documentation tools, storage approaches, and categorization techniques.
Your plan should include buffers during which you can incorporate the corrective actions and new techniques learned. Incorporation of the corrective actions and new techniques learned into the pilot project plans may take some time. Time may have to be allotted for the purchase of new tools, engagement of new resources, etc. While it is impossible to accurately predict how long this will take at the outset of your project, you will need to place some buffering into your plan.
Look for opportunities to make the plan flexible so that changes can be made during the implementation phase without excess pain. Pilot projects aren’t necessarily iterative (although they may be) but the plan will change much more than that of an ordinary project. Define a change management process that will support making the changes to the project your Lessons Learned will suggest without tying yourself into knots. The KISS principle (Keep it Simple Stupid) is the best process flow to follow in the case of changes from corrective actions or new techniques. Reserve the full blown approach for major changes to the key deliverables.
The Project Team
Try to choose team members who are comfortable taking risks; after all you’re doing a pilot project to break new ground. Choose team members who have taken part in pilot projects in the past, wherever possible. There is a certain amount of public relations involved in some pilot projects, especially those that implement a new process or methodology. For that reason choosing team members who are looked up to by their peers can be a tremendous help, both to the pilot and to subsequent projects because they will facilitate implementing the change. Resistance to change tends to break down when the people who pioneer the change are familiar and respected members of the organization.
Don’t forget to include the analytical skill set on the team. Team members who have some experience conducting or participating in Lessons Learned are valuable, as are those who have some experience in Root Cause Analysis. Your team members should also be ready to receive training in any new tools that your project plan calls for, or may call for.
Implementing the Plan
Implementing the plan for the pilot project calls for infinite patience on the project manager’s part. Failures, re-calibrations of the plan, and questions by the stakeholders are bound to be plentiful if there was a real need for the pilot in the first place. You will be called on to repeat the pilot project mantra to your stakeholders "The purpose of this project is not to prove that our plan is perfect but to create a perfect plan.” While the plan will include deliverables beyond the perfect plan for the next project, you must focus attention on the purpose of the pilot.
Don’t try to micro-manage the team. You should have people on your team who are the technical experts on the processes, methodologies, and technology your pilot is implementing so leave the detail work for them. Focus instead on how to best leverage the learning your team passes on to you.
Don’t fixate on the schedule. The schedule you defined during the planning phase of the project is probably not the right schedule for this project. You’re learning how to schedule the activities which will be used by the next project so you can expect some estimation to be out of whack. You need to review the plan to see what implications a bad estimate has on the rest of the activities, just as in any other project. The exception to this rule is when you are given a hard stop for the pilot. Your options when dealing with the hard stop and a schedule that can’t deliver to that date are to ask for a change to the schedule, to ask for a change to the deliverables (all except the Lessons Learned), or to ask for a change to the budget. Examine the project carefully before asking for an increase in the budget because an increased budget may not be effective in shrinking the schedule.
Your team should understand that the standards for success are not the same in this project as in a normal project. Instead of basing rewards on meeting deadlines or delivering products to specification try to lean towards accomplishments that improve the chances of the next project. The deliverables of the pilot cannot be totally discounted but shouldn’t outweigh the other goals.
One of the possible Lessons Learned from your pilot is that the program or project you are piloting is not feasible. A normal project will focus on the business case for implementing the project, while the pilot will focus on the feasibility. If the Lessons Learned indicate the project is no longer feasible the pilot should be terminated. The best time to make those decisions is at the Lessons Learned intervals. The decision to terminate the pilot will still be the executive sponsor’s or steering committee’s but they will need information from technical experts, not the business case. This is not to say that the business case cannot change during a pilot, but much less is known about the costs of the next project(s) during the pilot.
Closing out the Pilot
The project closeout should be marked with a final Lessons Learned. The lessons from this session should be archived with previous lessons and include lessons about the effectiveness of the corrective actions, new techniques, and new tools. Tailor the final Lessons Learned session to its intended use of refining the plans for the next project. To do that, couch suggestions for improvement in terms of the next project, not the current one.
Ensure the documents that capture the Lessons Learned are in a format that is easily accessible to the next project (e.g. .pdf, MS Word, WordPerfect), then archive them in a directory on which the next project team will have read access. Organizing the Lessons into groups by project phase or functional area will be helpful to the next project. Enabling access to the Subject Matter Experts (SMEs) by the next project team will also help the improvement process. Nothing aids communication of the Lesson like a first person account.
If you managed a successful pilot, the indication is clear that the rest of the projects in the program should be even more successful. If your pilot was not successful in meeting its goals and objectives you and your organization are faced with a decision: is the program feasible? Your responsibility here is to provide your executive sponsor or steering committee with all the information they need to make a sound decision, including your recommendation (if you are asked). You should attempt to put the information and recommendation in terms that your audience can understand and this may require you to interpret some technical terms. Marshal your technical experts to provide explanations of technical points, if your aren’t able to do this yourself.
Analyze the Business Case for impacts of recommendations of your Lessons Learned. What impact will the techniques and tools recommended by your Lessons Learned have on the cost of the program? Are all the benefits planned for the program still obtainable?
The methodology you use to manage your pilot project should be the standard one used by your organization, with the above exceptions. The methodology should be based on the best practices described in the PMBOK® 4th Edition. The best way to learn those best practices and enhance your career at the same time is to take a quality PMP® course or other PMP® exam preparation training, and then pass your PMP® Exam.