Projects in KaiNexus are often used for larger scope improvement efforts. They are typically top-down driven and often have multi-disciplinary teams which may include senior leaders, middle management, front-line staff, and subject matter and process improvement experts. Projects can be nested within Projects, and so are often used with strategy deployment.
We know that everyone does their Projects a little differently, so we don't have a KaiNexus methodology; instead, we provide an open framework from which to run your Projects.
- Origins: Only users with the appropriate permissions can create a Project.
- Content: A Project is made up of configurable fields (e.g. description, problem statement, current condition, target condition, etc.) and attributes (e.g. categories, priority, strategic initiative, etc.).
In addition, Improvements and Projects that all relate to the greater Project goal can be nested within the Project. For example, if you had a Project to reduce cost in your department, each idea to achieve that goal would be an Improvement, and each Improvement would have its own person (or team of people) working on it.
- Team: In a Project, you have a Sponsor, Facilitators, Leaders, and Participants. Many different people are submitting, assigning, working on, and approving Improvements.
- Sponsors and Participants are emailed immediately when an Improvement is completed or a Task is completed.
- Facilitators and Leaders are emailed immediately when an Improvement is added, an Improvement is completed, a Project is added, a Project is completed, or a Task is completed.
- Impact Report: Each Project has its own impact report that aggregates the impact of all of the nested Improvements within that Project. NOTE: Projects do not have Resolutions.
- Examples: Value Stream Map, Kaizen Event, Class, A3s*, PDSAs*
*The nature and scope of how the organization uses the framework will determine whether it is more effective to run it as a Project or Improvement.
Improvements in KaiNexus are typically used for smaller scope improvement efforts. They are typically bottom-up driven and often have either no team or much smaller teams than Projects.
Additionally, Improvements can be the building blocks of Projects. Improvements cannot be nested inside other Improvements.
Impact is measured at the Improvement level and not the Project level. They can be simple suggestions, ideas, and observations, or can be more structured such as A3s, PDSAs, or Opportunities for Improvements.
- Origins: Only users with the appropriate permissions can create an Improvement. Our customers configure their system to have at least one Improvement type that can be submitted by anyone in the organization.
- Content: An Improvement is made up of configurable fields (e.g. description, problem statement, current condition, target condition, etc.) and attributes (e.g. categories, priority, strategic initiative, etc.). Note: Other Improvements and Projects cannot be nested within an Improvement.
- Team: In an Improvement, the team consists of the Improvement's Author, the Responsible person, the Assigner, and an optional group of people (called Collaborators) who contribute to the work.
- Users will be notified when their relationship with the Improvement changes, such as when they are made the Responsible.
- Team members are notified about any status changes of the Improvement, such as when it becomes overdue or a resolution is submitted.
- Resolution: When an Improvement is completed, the Responsible person will log the impact of that work. That impact is then added to the aggregate metrics of the organization, that work area, and that individual. Note: Improvements do not have impact reports.
Tasks can be added to Improvements and Projects. These are usually simple to-dos and can be assigned to anyone, not just members of the Improvement or Project's team. For example, if the Improvement is to replace the printers in your office, a Task may be to look up where you can dispose of the old printers.
- Origins: Anyone on the parent Improvement or Project's team or who has permission to edit the Improvement or Project can create a Task.
However, you can only assign a Task to someone to whom you can assign an Improvement. If you cannot assign someone a Task, you can request their help with it. If you request someone’s help with a Task, they will need to accept that Task before it will be officially assigned to them.
- Content: A Task is made up of a title and a description.
- Team: In a Task, the team consists of the Task's Author, Assigner, Responsible Person, and an optional group of people (called Collaborators) who contribute to the work.
- Reports: There are no metrics associated with a Task.