Admin | Resources/Users

Return to the Admin Overview page

Topics

• Resources/Users | Purpose
• Resources/Users | Creating
  •  Lifecycle
  • Type
  • Role
  • Is Approved, Is Locked Out, Failed Attempts
  • User-level Visibility Options
  • Write Permissions
  • Assigning Department
  • Assigning Projects
  • Assigning Training
  • Send Invitation

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 = typically the user's email address to ensure it is unique. If using Single Sign-On (SSO), 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.
      
• Role
  Playbook roles are described in the table below. Choose the role that best describes the user's role in Playbook, not necessarily the same as 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 * Internal Read-Only	Tasks are created and assigned to them for better accountability and resource loading Someone else updates their tasks in Playbook Attend team huddles as requested Attend team Rolling Wave Planning meetings as requested
  Level 2 * Casual Team Member	Tasks are typically created and assigned to them Update their tasks in Playbook daily Attend team huddles as requested Attend team Rolling Wave Planning meetings as requested
  Level 3 * Core Team Member	Typically create and manage a few tasks at a time Update their tasks in Playbook daily Attend decentralized planning meetings Attend team huddles 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 ‘Mini-Project Leaders’ of 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 and bring potential overloads to 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 Playbook Methods by demonstrating in-depth knowledge and by demonstrating their 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 Methods) 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 in the Dashboard created by other people.
  Contractor
  Vendor/Supplier

• Is Approved, Is Locked Out & Failed Attempts
  • Is Approved? = If checked, the user is able to 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
    
• Write 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.
    
• Assigning Training
  • There are five levels of training, from Internal Read-Only (Level 1) to Project Leader (Level 5).
  • 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 needs or wants to advance to a higher level role, they can be enrolled in the "(Level 3 ⭢ 4) Advance to Summary Owner" and (Level 4 ⭢ 5) Advance to Project Leader" courses.
  • "Advance to..." courses must be completed sequentially, e.g., the "(Level 3 ⭢ 4 Advance to Summary Owner" course must be completed before starting the "(Level 4 ⭢ 5) Advance to Project Leader" course.
    
  • When you enroll a user in training, an automatic email is sent to the user with the enrollment information.
    

• 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.