13 rules for KM pilots

---

Here's a checklist from the archives.

I'm not sure where it came from originally, but it's a good checklist for KM pilots.


1. The results have to be clear enough to provide an answer (pilots don’t make management decisions ). A pilot may be requested by the sponsor to avoid making a decision between a number of options. Be wary of putting anything that requires an organisational/management decision into a pilot. You can avoid this by revisiting the objectives of the pilot with the sponsor).

2. The people you choose to pilot have to be ‘up for it.’  There will always be issues with a pilot. It is sometimes better to pilot with a group who show the most enthusiasm even if they are not the target audience of the pilot. This will enable you to check processes and procedures first, particularly if the pilot is around new ways of working. You can then invite a more appropriate and targeted community for the main pilot).

3. Avoid checking technical issues within the remit of a pilot. Questions around ‘can we do it’ should be resolved outside of any pilots. You can avoid this by revisiting top-level objectives with your sponsor and asking questions such as are you looking for new ways of working, what are your criteria for success

4. Avoid placing all responsibilities on your project manager. Using a group of three - a project manager (for business processes), a finance person (to look at the budget for the pilot and whether financial benefits are being achieved) and a KM specialist

5. Sponsorship is not sponsorship unless it brings funding. Ensure your sponsor understands that they will not always be able to guarantee savings as a result of the pilot, they may have to spend money to save money - it may be a return in future benefits such as derisking. You may to quantify the cost of derisking at project initiation stage to assess whether the project is worth the cost.

6. A project by definition is throwaway

7. Target project champions who understand where the business is going and why they are adding to that vision

8. Minor scope creep is an important and necessary step within a pilot

9. Technology should not drive the pilot, the pilot should drive the technology

10. Focus on the business processes which each business area identifies will make the most savings

11. Be prepared to factor in additional costs to help pilot users keep up to date. New systems or processes may cause users delays in their day job. Service Level Agreements may not be able to be changed for short periods of time, so you may have to factor in additional funding to help them keep up to date with their date job

12. When a pilot ends, ensure that users understand where any funding ends. If they wish to continue with the process/system, help them look at what can be done to extend pilot arrangements

13. stablish a mechanism for selecting what to pilot. This could be looking at objectives as they arise, revisiting high level aims and going back to the sponsor to agree costs.