When implementing project lifecycle management software, like ARES PRISM, it is a common practice to select a pilot project that represents a cross section of characteristics likely to be encountered.
There are a number of reasons and purposes for this piloting approach:
You can test the capabilities of the new project cost control software.- The initial investment can be kept modest by using a pilot project.
- It can provide an early return on investment.
- Helps build a core group of experienced personnel.
- Can bring to light the need for improvements in company business practices (such as commonly used coding structures).
- Enables an infrastructure model for integration of information between existing tools and the new PRISM tool.
To have a successful pilot project, an organization needs to carefully select a project that is the right size, complexity, duration, and is at the right stage. It is important to have buy-in from leadership and to ensure the that the appropriate people are participating in the pilot project.
A pilot project as described above is often integrated into a staged software implementation plan, but a pilot project can also be used to aid in the decision to use the tool before a significant investment is made. The pilot project can also take place after the commitment to purchase the software as a means for initial testing and compliance. Think of the pilot project as the front-end engineering design phase of your implementation project.
You do not have to prove the pilot on a large and complex project— A simple project often has advantages. There are, of course, some disadvantages of a simple project which could be overcome by selecting an appropriate project. You may need to determine your priorities and values before you can decide on an appropriate pilot project. For example, if you desire to test a standard coding structure very thoroughly, then a simple project may not be adequate. However, a pilot project is not the only way to test a coding structure.
Advantages & Disadvantages: Choosing a Simple Pilot Project Versus a Complex Pilot Project
1. Size & Complexity
- A simple pilot is less likely to involve so many people that it interrupts normal business. This avoids the risk of added time to others before a firm commitment has been made.
- The simple project may be less likely to pose a risk to the business.
- The simple pilot can usually test the software to determine if it fits the business. You should be able to determine what business units will be impacted and how you can balance the impact to them with the benefits which may be accrued by others.
- The simple project can determine what benefits are likely and what barriers are likely to be encountered. Therefore, the project needs to be complex enough to test the barriers, but simple enough to avoid unnecessary impacts to others.
- A simple pilot is likely to involve shorter duration than one which is more complex. A shorter duration may be an advantage to enable you to realize the benefits of the new tool. However, duration of a pilot project can be managed by phasing into an implementation. If the complexity of the project is not a barrier for your pilot project, then the duration of the pilot project does not necessarily need be a determining factor.
2. Duration
The duration for your pilot project is not the same as the duration of the project that you choose to create your
pilot. The length of the project chosen is likely to be typical of the projects in your business, because you should pilot with a project that is typical for your business. Your pilot project is likely to endure for only a portion of the life of the project which you choose as the pilot. Setup for a pilot project requires more effort than running and maintaining the pilot. Dependent on the state of the project selected, a pilot project could be up and running in as little as two weeks or could take up to 6 or 8 weeks. You should run and maintain a pilot project for at least two reporting cycles, thus allowing time to document your findings and make any adjustments needed in configuration.
Documentation does not stop with findings. During your pilot project, you will begin to design and develop how you plan to use and implement the tool. Decisions need to be made, such as what systems and processes will provide information to the tool. Business processes should be reviewed to determine ones that may be missing or need adjustment in order to work properly with the tool selected. It is also important to document what capabilities or ways of using the tool provide the highest productivity and responds best to your needs. Your statement of purpose should document the limits of what you plan to do (your scope) and indicate what is expected to be future improvements or expansions of those limits and plans (your desired future state).
3. Stage of Project
It is best to begin the pilot study at the stage of a project which will provide you with a good test of the tool. Since a pilot is only for a limited duration of the project, then almost any stage of a project can provide for a successful pilot, with the exception of the last stage of a project. Choosing a project near initiation has the advantage of avoiding duplication of effort by responsible personnel. A project in its middle stages would certainly represent your business better and provide for more information for testing. However, it may be far enough along that it is not likely that the current way of doing business would not be abandoned, thus requiring a duplication of effort to keep it going as well as develop the pilot project in the new tool. If a project can be found that is transitioning from one stage to another (say from Engineering to Construction) perhaps you can convince others to abandon their current systems and not duplicate efforts. This would be ideal.
So, you may need to choose between the advantages of an early stage project and the middle stage project. I have found the early stage project to normally be adequate as a test and that the benefits of the single system operation to outweigh the more thorough test of the middle stage project. But if that ideal project can be found then proceed with it.
4. A Leader Who Sees Value
You need a leader who believes in the value of the tool – a champion of sorts. Since your pilot may only take place for a couple of months, the pilot does not necessarily demonstrate the value of the tool in its entirety. However, the pilot project should be able to demonstrate that the benefits are achievable and that the tool is useful for the purposes desired by management. Be sure to understand the value that leadership places on the tool and illustrate that value with your pilot project. With proper leadership, it is easier to gain agreement from other teams or departments that will need to participate in the use of the tool as there is greater vision of the purposes and the benefits of the new tool.
5. The Right Team
The right people on your pilot project will aid you in capturing the benefits of the tool, which could be critical to those early returns on investment. Without the participation of the right people the core experience needed will not be developed upon which to build your future implementation. Additionally, any knowledge related to coding structures and other related processes will be less likely to be transferred accurately for future implementation. The right persons should include those who are working on the selected project. Total dedication may not be feasible; however, the more input and visibility given to the pilot will allow for a more successful test and enhance the future implementation processes.
Conclusion:
A successful pilot project can provide the information needed to aid in determining the use of and implementation of a new project lifecycle management solution, like ARES PRISM. The early benefits noted are an attractive part of the pilot project. Choose the project so that it enables a reasonable test of the tool, but avoids the complications that may hamper the larger projects. Obtain those early benefits and your leadership team will likely stand behind you when the implementation requires others to be impacted. Using an appropriate project in your pilot will enable you to develop an effective plan to implement the tool and anticipate some of the hurdles. Your pilot project personnel will be able to get early experience and share that experience with others during the more critical period of implementation.
Interested in More Software Implementation Tips?
Take advantage of the helpful risk mitigation strategies available in this white paper: Top Risk Mitigation Strategies – A Proven Software Implementation Plan for Integrated Project Controls. Explore 10 of the most common risks associated with software solution implementation and learn how to effectively mitigate them with proven project controls implementation strategies.
Best-in-class organizations invest in enterprise solutions, but sometimes the implementation fails to deliver a Return on Investment (ROI) because these risks were not recognized and managed. This paper offers strategies to mitigate these risks and implement your chosen solution successfully using a proven project controls software implementation plan.