3 Simple Rules that can help any Software Implementation go better

The following is an example of the “3 Buckets” training that you should provide to your end users when implementing any new software solution.

The examples below are taken from a www.KPIFire.com implementation but the 3 Buckets concept can work for any software implementation. This is particularly useful for software that has many features and optional use cases. Users might be confused about how much of the tool they really need to learn and how much they MUST use. This concept of 3 Buckets will help you communicate to your end users in a way that will make your implementation a success and give you a pattern that you can build on in the future.

Start with Three Buckets:

Bucket #1- The Must Do Bucket: Minimum acceptable use.

Bucket #2: The Can Do Bucket: Things you can do with the software.

Bucket #3: Don’t Do: Things that the implementation committee does not want you to do.

Keep in mind, these are all just examples and you might put more or fewer items in each list. Also, the items you put in “Can Do” during your initial implementation, might become “must dos” later on as the comfort levels increase.

Use Case Example: Continuous Improvement

Use Case #1: Using KPI Fire for Process Improvement Projects.

Must Do: These are the steps required to meet the minimum acceptable usage of KPI Fire.

1. Enter all Improvement Projects with Target Financial benefit of over $10,000.
2. Project Leader & Sponsor to Complete the Project Charter Tab fields (Problem Statement, Goal Statement, Scope).
3. Add a Project Sponsor & Project leader to all Projects with status = Active.
4. Update all Active/Control projects at least 1 time per month.
5. Enter 12 months of Target/Estimated benefits for any Active project.
6. Enter Actuals for each month within 15 days of the following month.
7. All Level 2 managers must complete at least 2 process improvement projects per year

Can Do: These are things you are encouraged to do, but not required to do.

1. Select a workflow template such as DMAIC, or PDCA and manage the tasks per the workflow. Use the templates & file attachments to help you in performing the process improvement tasks (5Whys, Fishbone,CTQ Tree, etc)
2. Add additional team members to your projects.
3. Create new tasks in your own project for yourself or others.
4. Use KPI Fire for weekly project reviews within your team.
5. Use KPI Fire for daily tracking of tasks.

Don’t Do: Please don’t do these things in the software.

1. Do not create custom workflows, without involvement from Admins (list names).
2. Do not use the software for personal projects (such as building a tree house, or remodeling your kitchen).
3. Do not create new Benefit Accounts, without consultation with Finance team or sr management.
4. Do not use KPI Fire for requisition requests for standard equipment. (These should go through the IT help desk as there is an existing process).

Use Case Example: Strategy Execution

Use KPI Fire Huddleboards, or Grid view for Quarterly Business Reviews

For Strategy Execution Use Case

1. Create a 1 Huddleboard per Department, or for each department with accountable leader.

Must Do

1. Review 1–7 metrics with your reporting manager 1 time per quarter.
2. For any metric not in Green, show that you have a plan to return the metric to Green.

Can Do: These are things you are encouraged to do, but not required to do.

1. Identify minimum of 1 goal in each area: Financial, Stakeholder, Internal Business Process, and Culture/Capability.
2. Identify at least 1 metric per goal. Create monthly targets for each metric.
3. Review all goals and metrics on initial setup.
4. Create more than 1 goal per area.
5. Create more than 1 metric per goal
6. Update metrics more frequently (such as weekly or monthly).

Don’t Do

1. Do not create metrics that you do not intend to take ownership of and update on a regular basis (at least monthly).
2. Do not change targets after initial manager approval.

Using KPI Fire for Idea Funnel

1. Use KPI Fire “New Idea” option from web application, mobile app, or external form & encourage all staff to share ideas for improvement.
2. Best Practices:

Must Do:

1. All department managers MUST review all new idea suggestions within 30 days and prioritize as (High, Medium, Low).
2. Department managers must review all ideas in idea funnel at least once per quarter & adjust priority, effort, impact, risk as appropriate.
3. All ideas submitted must have a note if idea is canceled.
4. All employees are required to share 2 process improvement ideas per year.

Can Do:

1. Turn on notification alerts for each person to get daily, or weekly updates of tasks assigned to them.
2. Turn on notifications for new ideas submitted by department.
3. Send screenshots or links of existing ideas to other team members to ask them for input.
4. Managers can invite team members to add additional details to submitted ideas, or assign Project Leaders to advance Ideas to Projects.
5. Link ideas to strategies(Goals), or Key Performance (metrics).

Don’t Do:

1. Delete or cancel ideas without adding a note about why it is deleted.
2. Delete/Cancel/ or change status of ideas in other departments. (even if you have permissions/access). Talk to the Department leader first.

Use Case Example: Using Huddelboards in KPI Fire for Lean Daily Management

1. Create a Huddleboard for a specific department.
2. Best Practices

Must Do:

1. All members of Huddleboard commit to review the huddleboard at least 1 time per week.
2. Include 1–4 key metrics: Safety, Quality, Deliver, Costs

Can Do:

1. Include additional Metrics
2. Review the huddleboard more frequently (such as daily).
3. Department Leaders can assign individual metrics to specific team members for update, to share the work load, and to help the team members feel responsible for the number.
4. Add additional text boxes to track additional information the team feels is relevant.

Don’t Do:

1. Do not change huddleboards assigned to other departments. (Even if you happen to have user rights to do so).

Keep in mind, these are all just examples and you might put more or fewer items in each list. Also, the items you put in “Can Do” during your initial implementation, might become “must dos” later on as the comfort levels increase.