Topics
Resources/Users | Purpose
Assigning tasks to resources and users... (as opposed to not assigning tasks to anyone)
- Ensures accountability
- Enables us to accurately assess resource demand so we can properly staff projects and ensure project timelines are realistic
Resources/Users | Creating
- Click Add to create a Resource/User...
- First Name = e.g., Clark
- Last Name = e.g., Kent
- Short Name = typically <First Name> <First Initial Last Name>, e.g. Clark K, or an alias, e.g., Superman. This is the name as it appears next to tasks in the Game Plan.
- Capacity (hrs/day) = Number of hours a resource works per day, e.g., 8 hrs/day
- Availability (hrs/day) = Amount of time a resource can work per day on project tasks (not otherwise busy in meetings, taking breaks, etc.), e.g., 5 hrs/day
- Username = The unique identification a person uses to sign in to Playbook, typically the user's email address. For Single Sign-On (SSO), it must match the user's email address in the corporate LDAP.
- Lifecycle
- Active = Resource has completed training, can be shown in all views, and can be assigned tasks.
- Not Active Yet = Resource has not completed training, can be shown in all views, and can be assigned tasks.
- Deactivated = Resource is removed from all views and cannot be assigned new tasks, however, the user can still log in if “Is Approved” is checked.
-
Type
- User = a person who will sign into Playbook, typically to update tasks and plans, etc.
- Resource = someone or something that will be assigned tasks but will not sign into Playbook
- Template = generically named resources used in template workflows, e.g., Mech Engr, Elec Engr, QA, etc.
- Equipment = e.g, Robots, Machinery, etc.
- Test Unit = e.g, Prototype Unit 1, Prototype Unit 2, Prototype Unit 3, etc.
- Resource Pool = a group representing a collection of resources, e.g., Document Control, Mechanical Engineering, Analysts, etc.
- Other / Person that won't sign in = a named person, e.g, Clark Kent. Tasks can be assigned to Clark but he won't be signing into Playbook as a user.
- Playbook Role
Playbook roles are described in the table below. Choose the role that best describes the user's role in Playbook, not their role in the organization or on the team. This also determines the user’s training curriculum. Only one role with an asterisk can be selected.
Playbook Role
Playbook Responsibilities * (Level 1) Read-Only
- Tasks are created and assigned to them for clearer visibility and resource loading
- Someone else updates their tasks in Playbook
- Only attend team huddles as requested
- Only attend team Rolling Wave Planning meetings as requested
* (Level 2) Casual User
- Tasks are typically created and assigned to them
- Update their tasks in Playbook, daily
- Only attend team huddles as requested
- Only attend team Rolling Wave Planning meetings as requested
* (Level 3) Core Team Member
- Update their tasks in Playbook, daily
- Often create and manage a few tasks at a time
- Regularly attend decentralized planning meetings
- Regularly attend team huddles
- Regularly attend Rolling Wave Planning meetings
* (Level 4) Summary Owner
- Update their tasks in Playbook, daily
- Designated as an owner of one or more summary tasks
- Acting as ‘Project Leader’ for their summary tasks
- Lead team huddles and decentralized planning meetings as needed
- Update their summary tasks in advance of Rolling Wave Planning meetings
- Assess the loading of the resources they utilize in their summary tasks and bring potential overloads to the Project Leader’s attention
* (Level 5) Project Leader
- Manage the plan structure and the integration between different workstreams
- Owner of Major Milestones and Buffers
- Manage trade-offs across disciplines and workstreams to minimize delays and get the best value for the customer
- Monitor threats to critical chain, impacts to buffers, & capture impact reasons
- Lead Rolling Wave Planning meetings
- Manage resource loading to ensure timelines are reasonable and resources are not overloaded
- Manage reports & buffer charts - provide updates to stakeholders
Manager/Director
- Lead the organizational change to effectively use Playbook Methods by demonstrating in-depth knowledge and by demonstrating adaptability to the new way of working
- Skills such as assessing team health, removing organizational impediments, making room for failure, and being able to coach are key (especially for teams and individuals new to Playbook methodology)
- Define the mission and vision for teams, recruit talent, and help them achieve their highest potential
Admin
User has access to the Admin page to perform administrative functions. Reports Admin
User can change and save Shared reports created by other people in the Dashboard. Contractor
Vendor/Supplier
- Is Approved, Is Locked Out & Failed Attempts
- Is Approved? = If checked, the user can sign in to Playbook. Uncheck when a user should no longer have access to Playbook.
- Is Locked Out? = If checked, there were too many unsuccessful login attempts (ten). See Failed Attempts.
- Failed Attempts = Number of times the user has attempted to sign in and failed due to entering the incorrect credentials. If a user is locked out, uncheck "Is Locked Out" and reset the Failed Attempts counter to zero.
- User-level Visibility Options
-
All unrestricted projects in user’s group and restricted projects user is active on = Employees
-
Only projects user is active on = Contractors, vendors, etc.
- All projects = Admins. Managers and Directors when Group visibility is unrestricted
- All projects in user's group = Managers and Directors when Group visibility is restricted
-
- Permissions
- Read/Write = Can view and save (most users)
- Read Only = Can view but cannot save
- Department (Click here for details about Departments)
- A user can only be in one department
- Also determines the Group the user is in
- Assigning Projects
- Only resources assigned to a project can be assigned tasks.
- All standard email notifications are in the "Misc. Other" project, therefore all users shall be assigned to the "Misc. Other" project.
- Only resources assigned to a project can be assigned tasks.
- Assigning Training (Click here for details about Role-based Training courses)
- There are five levels of training, from (Level 1) Read-Only to (Level 5) Project Leader .
- The user's Role determines their training curriculum, required and optional.
- For example, a Core Team Member's required training is (Level 3) Playbook for Core Team Members.
- If a Core Team Member wants to advance to a higher level role, they can be enrolled in the Advance to Summary Owner (Level 4) and Advance to Project Leader (Level 5) courses.
- Advance to... courses only include the training material not covered in the previous level therefore must be completed sequentially, e.g., the Advance to Summary Owner (Level 4) course covers additional topics not already covered in the Level 3 course and must be completed before starting the Advance to Project Leader (Level 5) course.
- When you enroll a user in training, an automatic email is sent to the user with the enrollment information. No need to Send Invitation (see below).
- Send Invitation
- When checked, an email is sent to the user with a link to set their password.
- Also includes training enrollment info.
- Typically used only when first creating the user's account.
- Do not check when you are only managing training enrollments as emails related to changes made to training enrollments are automatically sent.
- When checked, an email is sent to the user with a link to set their password.