Staffing Your Project Team

Great project managers always seem the get the best people for their projects. What’s their secret? Establishing relationships with management works best:

You sell your project directly. With a good relationship, you can discuss in detail the benefits and drawbacks of the project as well as the development opportunities for having the manager’s employees work on your project. The manager also gets an opportunity to talk about specific objectives they have for their employee, which you can support via the task assignments and guidance you provide.

You can perform part of the managers’ work. Giving support and feedback to your team members along with periodic appraisals of their work as the project progresses is very useful to assigning manager. You can make their job easier, especially if you write performance evaluations in the context of the manager’s growth objectives for their employees. Managers who feel confident you do this well will work with you more readily when you seek project team members.

You can ask for a favor. If you need in-demand skills, a good relationship with assigning managers significantly increases the chances you’ll get the in-demand resources you need. Trust-based relationships make it easier for managers to take a risk and assign the most in-demand staff members to your project, even in instances where it is helpful but not necessary.

You can change resources more readily. If you have issues with a resource, the assigning manager is more likely to listen to you and support replacing your team member. At the very least, they are more likely to work with you to help improve your team member’s performance.

The team members you get make or break your projects. Getting to know the managers who assign employees to your projects is the best way to ensure you get the people you need to successfully deliver expected outcomes.

For more about working with team members, check out Chris Croft’s Managing Resources Across Project Teams course.

The Missing Charter Element: Sponsor Responsibilities

A project charter details the project manager’s responsibilities, but typically not the sponsor’s. Here’s why you should document sponsor responsibilities, too.

Identify who manages senior stakeholder relationships. Sometimes, senior project stakeholders don’t know the sponsor. For project success, key stakeholders need to understand and trust the sponsor and his or her motives.  The charter should define how those stakeholders will be engaged. For example, the responsibility could lie with the sponsor, a sponsorship committee, or it could be delegated to the project manager. By including high-level responsibility for stakeholder engagement in the charter, you can ensure that someone manages these crucial stakeholder relationships.

Identify how project funds are acquired. Sponsors may not have the authority to release project funds, even from their own budgets when expenses exceed a certain threshold. It’s important to understand and agree in advance on how project funds are released. You might need to work with financial managers to identify the process and specific data needed to release funds. To ensure that money is available when needed, in the project charter, document this information and process as part of the responsibilities of the sponsor and the financial managers.

Technical decisions may require consultation. Decisions regarding technical considerations may require expertise the sponsor doesn’t have. In that case, the sponsor would need to consult with technical managers to ensure the integrity of those decisions. The project charter can specify the sponsor’s and technical managers’ responsibilities revolving around those consultations.

Sponsor’s time constraints may require delegation to others. Sponsorship often falls to a high-level manager. While that gives them sweeping authority to make decisions, they might not have the time to execute all of their responsibilities. In that case, some sponsorship authority may be delegated to other managers. These delegations should be clearly stated in the project charter.  In addition, the sponsor’s level of time commitment to the project should be documented.  As a project manager, you need access to your sponsor or the sponsor’s delegates to ensure decisions can be made in a timely fashion.

For more about sponsorship, check out my Project Management Foundations course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Don’t ask for a project deadline

Project managers often ask for a project deadline. That might be a bad idea. Here are reasons to propose a project deadline rather than request one:

You need to analyze before agreeing to a deadline. Until your project team analyzes the work required to achieve business outcomes, you can’t be sure the deadline provided is feasible. Why ask for a deadline if you can’t acknowledge or refute? Instead, perform analysis on the requested scope and propose a defendable deadline. While that deadline may not be accepted without negotiation, you can talk knowledgeably about the specific risks of bringing in your proposed deadline.

Employ a proactive approach to project management. Setting arbitrary deadlines is not a recommended practice in business! Why do it with projects? Discussing possibilities, approaches and the capabilities and capacity of your team members is more constructive than building a case for why a project deadline may or may not be feasible. These discussions allow project managers to extend the capabilities and control organizational leaders have to manage the business.

Protect how your management team is perceived by team members.  Impractical, arbitrary deadlines proposed by managers can erode the trust-based relationship between management and your team members. Managers who propose deadlines without understanding the complexity of the work can be perceived as out of touch or unappreciative of the work teams perform. Defining objectives and deadlines using a consultative approach between the team and management instills trust and helps ensure buy-in.

Support early discussion of options for the business. Ask the project team for their opinions about business objectives. that way, you won’t have to defend impractical deadlines. Instead, the team can propose scope and time trade-offs and alternative solutions to achieve those business outcomes.

For more about project scheduling and deadlines, check out my Project Management Foundations course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Breaking down tasks for your WBS

A Work Breakdown Structure (WBS) breaks down your project into the activities needed to meet project objectives. Here are tips for breaking down project activities:

Break tasks down into 8 – 40 hours of effort.  To help track progress, break down work so tasks can be completed within a week. If a process takes longer than a week, establish checkpoints that are 40 hours of effort or less. Note: Toward the end of your project when you have less time to handle delayed task completions without impacting your project, shorten task durations to 16 hours or less so you can manage proactively.

Assign tasks to an individual, if possible. Every task will be assigned to people. Ideally, one person should be able to complete the broken-down task. When multiple people work on a task, name a spokesperson to track progress and report status. A best practice is to have an informal discussion with the spokesperson so you know how they will coordinate work on the task.

Identify how you tell when the task is complete.    To track progress easily, document what each low-level task delivers so you confirm that the task is complete.  As project manager, you don’t have to confirm completion. Ensure that a subject matter expert can confirm completion for every task in your WBS.

Tasks should be clearly defined.  Two main tests can be used to assess clarity: Will a team member assigned to work on the task understand the task description? Can you tell what tasks will precede or follow from a particular task? Tasks contribute to the construction of a schedule and should be defined logically, so you can determine whether a specific sequence is needed (i.e., you must write software before you test it). Alternatively, you might be able to perform tasks in parallel, like defining the task of “painting the house” to “paint the east side of the house” which could be done in parallel with “paint the west side of the house.”

For more about work breakdown structures, check out my Project Management Foundations: Schedules course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.