Best Practices for Project Teams

From PhUSE Wiki
Jump to: navigation, search

Scope and Objectives

Working group project teams will succeed if goals are clearly stated and all members are engaged in the project team process. Group participation, subject matter interest and steady progress are key factors to this engagement.

These best practices are intended to help project team leaders keep their members engaged, in order to have a successful outcome from their group. Leadership should foster ownership in the project team process from all members, by delegating responsibilities and providing a clear path of progress towards the team goals.

Some principles to keep in mind:

  • Keep it simple – Identify and clarify and your goals.
  • Keep it small – Break projects into small manageable pieces.
  • Keep it moving – Use interim milestones for momentum and demonstration of value.

Instructions

Once a Working Group Project is set and ready to go, here are best practices to keep project teams on track and productive, practices which help teams accomplish their goals and keep team members engaged.

Project Set-up Practices Header text
Leadership
  • Project Lead: Select the project leader. Co-leads are advised for division of duties and co-strategy for overcoming obstacles.
  • PM: Assign a Project Manager, if the scope requires it, to help with logistics.
  • Contributors: Ensure that there are enough members of the team to provide cross-functional input, as well as subject matter expertise.
Determine participation requirements
  • Meeting frequency: Meetings should occur at least once every 2 weeks to ensure continued progress.
  • Meeting time: Select a day/time that suits all or majority of members.
  • Time Expectations: Set expectations for the time commitment to the project and the expectation that everyone MUST contribute by taking assignments and speaking up.
Note: Leads must be able to commit to doing much of the heavy lifting.
Set Communication Plan
  • High level: Who leads team communication; sets up meetings, sends team emails …
  • Details: What type of meeting and project documentation is kept, where is it stored, who has access. Find the tools that work best for your needs.
Identify Tasks
  • High level: Define the major tasks and timelines in the project. Ensure that the team understands what is going to be accomplished within the time line.
  • Details: Per task – define task deliverables, milestones, final due date and member responsibilities. Use sub-teams as needed.
Meeting tips
Meet as planned, cancel only when unavoidable.
  • Have a back-up meeting leader to take over when needed.
Send agenda well ahead of meeting day with topics and discussion durations.
  • Reinforce outstanding action items in the agenda email to ensure team members remember their responsibilities.
Time management is important to meet due dates.
  • Stick to the meeting agenda and avoid adding more agenda items than time will permit.
  • Control meeting discussion times to avoid run-over. Take discussions offline when possible.
Delegate responsibilities
Assign action items at each meeting to encourage participation and to ensure moving forward.
  • Each member should make an individual contribution to the meeting rather than just be a “listener”.
Invite Stakeholders/SMEs
Involve stakeholders from outside the team when required to add input or direction.
  • Approval from stakeholders may be required before proceeding with tasks.
  • Seek advice from subject matter experts when needed, rather than waste meeting time discussing assumptions.
Use sub-teams
Use sub-teams when a project has multiple deliverables.
  • Divide into sub-teams to do small deliverables meeting more frequently.
  • Do not have too many people in a sub-team (3-5).
  • Using sub-teams, the full project group may only need to meet monthly.
  • Sub-team drafts will go to the full team for review.
Finalize deliverables
Documentation/finalization.
  • All references to industry and regulatory guidance must be footnoted. Links are also helpful, even when there’s a risk that the link may be broken in the future.
  • Deliverables must not infer FDA direction. Wording such as ”The beginning of the effort leading to this white paper came from the FDA computational science center (CBER and CDER)” is not advised. A better way to say this is, “The beginning of the effort leading to this white paper came from the Pharmaceuticals Users Software Exchange (PhUSE) Computational Science Symposium where FDA and industry partnered to tackle various standards challenges…”
  • Review deliverables to a small circle of “family and friends” outside of the project, select subject matter experts who you know will provide feedback.
  • Send all final deliverables to your Working Group Lead for review who will forward them to the CSS Steering Committee for review.
  • There is a documented Steering Committee Review Process on the Wiki.
  • Ensure your project Wiki page is updated to reflect the status and the location of the final deliverable.