Choosing Project Team Leaders

/in /by

The right team leaders can help make your project a success. Here are sound strategies for assigning team leaders to your project. 

Add strength to your project leadership. Look for people who compliment and expand your skills. Be realistic about your own skills and how others can augment them. Tell your team leaders how their strengths can support you and the project. 

Increase visibility. Team leaders with visibility to critical stakeholders can help you promote your project in addition to providing critical skills. Shrewd project managers leverage relationships between team leaders and key stakeholders to review potential project priorities and directions. Team leaders can also obtain early opinions and impressions on project deliverables as they are being produced.

Instil confidence. People who are widely trusted add value as team leaders, because the organization is likely to follow their lead regarding changes or decisions. These confidence-building team leads might act as part-time deliverable reviewers. Their reviewer role provides a valuable quality check and can also boost stakeholder confidence. 

A Reality check – team leaders are often chosen for you. Managers often assign team leaders to your project. Therefore, it is important to develop good relationships with the managers who provide resources. Use the tips provided here as rationale when negotiating to get the best people assigned to your project. If your preferred resources aren’t made available, seek to have them assigned on “stand by” for risk mitigation purposes in the event you run into project issues. 

For more about resource management, check out Chris Croft’s Managing Resources Across Project Teams course.

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

Managing Variances

/in /by

Managing the variance from your project baseline is sound PM practice. Here are tips to determine acceptable triple constraint variances (scope, time, and cost) for your project:

Examine your company’s behavior. Your business is likely to have common approaches for managing scope, time, and costs. Your project should conform to those norms for tolerating scope changes, schedule slippage, or budget overruns. While some businesses focus on maintaining a tight budget and schedule, others, due to intense competition in the marketplace, may focus on fulfilling scope, even if it means going over budget or behind schedule. In other business environments, schedule is critical. Government laws that go into effect on a certain date must have supporting systems and processes ready to go when a law is enacted.

Scheduled events will affect acceptable variance. Many businesses work on marketing release schedules, so products need to be ready for demonstration at key trade shows or other marketing events. Little to no schedule slippage is tolerable in these instances. There may be some tolerance for scope reduction however, if the product still meets market expectations.

Cost savings as a project outcome will affect your variance targets. There is likely to be little to no tolerance for budget overruns when cost savings is the project justification. However, if the cost savings come from improved processes or low-cost product production, scope may be the constraint where variances are unacceptable. Process changes that form the project scope may need to be unchanged to fulfill the cost savings objectives. In some cases, increasing the budget may be acceptable to ensure the long-term cost savings are achieved.

As you approach the end of your project, acceptable schedule variance tends to be tightened. This is because you have less time to recover from any delays. Budget constraints may tighten as well. If you are under budget, however, your ability to accept cost overruns for specific tasks may improve toward the end of your project. Be careful however – just because you are under budget doesn’t mean you can overspend on a given item – management may be counting on the excess allocated funds to apply to another project.

For more about managing variances, 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.

SMART Requirements are Agile

/in /by

SMART guidelines are used to assess requirements in waterfall projects. They apply to agile projects as well:

Specific. In Agile, it doesn’t exist initially. Specific relates to the final product. Requirements are captured during development, not documented in advance. However, the end result typically goes beyond the detail and specificity of traditional requirements. When broad  requirements aren’t specific, they are typically broken down into several features in Agile, each of which provides specific functionality and can be more easily produced.

Measurable. The construction and evaluation of each feature focuses on measuring effectiveness. One of the most significant benefits of Agile is that performance and suitability measurement reviews are built into the development process. With a mindset towards prototyping, Agile features can be evaluated by users prior to implementation. When that cannot be done directly, for example, when a totally new business process is being created, the user-developer partnership used to build features in Agile reduces the risk of items failing to meet measurable business objectives.

Achievable. Feature sizing and prioritization ensures that achievability is regularly assessed. Features are examined for their integrity and ability to be produced during a sprint. Larger features are broken down into pieces that are more easily created, enhancing achievability. When the features can’t be broken down into manageable pieces, that’s a sign that they aren’t achievable. The developers and users can examine these features in real time to determine how critical they are and explore other ways to address the corresponding business need.

Realistic. In Agile, features are developed and accepted iteratively and in real time, versus weeks or months after requirements are documented in the traditional approach.  Agile lends itself to realistic outcomes and can accommodate the latest changes to business needs. The nature of Agile means the team learns about features and their capabilities more deeply, allowing users to make features more business-friendly. Feature capabilities have greater integrity and support better business processes.

Time-constrained. The sprint schedule is ideal for ensuring time constraints are placed on feature creation. In addition, there is the added value of being able to easily change timeframes when business priorities change. Reprioritization and re-stacking of features for each sprint provide an ongoing focus on development timeframes. While this time management approach isn’t perfect, features that require more time than anticipated to develop are re-evaluated and assigned to subsequent sprints as agreed by the Agile team.

 

For more about Agile, check out Doug Rose’s Agile Foundations course.

Why You Should Identify Risks Early

/in /by

Identifying risks early in a project is a best practice. Here are some benefits of this great approach.

Obtain critical information for project approval.  Without identifying risks early, an inappropriate project could be launched, wasting money and valuable stakeholder time. Instead, understanding the risks provides a balanced view of the value of project outcomes. The expected outcomes could be prioritized or enhanced based on the risks presented by the project team, making the project more viable. Or the project could be deemed inappropriate due to those risks.

Make your initial plans more realistic.  Project overviews, including high-level plans, provide context that helps drive project approval. Those initial plans must consider project risks to be valid. With risks identified, the team can define mitigation actions and include them in the plans. Risk information helps the management team make go/no-go project decisions in the best interest of the business. In addition increasing the integrity of the approval decision, it also proactively sets key stakeholders’ expectations.

Set a reasonable project budget.  Risk management often requires additional funds to cover the costs of actions or contracts needed to manage risk. And these can be expensive. Considering these costs early in project planning helps the sponsor set a reasonable project budget with greater likelihood of meeting business expectations.

Determine early staffing requirements. Addressing risks typically includes staffing considerations. Expensive, contracted specialized skills could be required to manage technical risks.  Alternatively, you could make sure internal technical team leaders work on your project. (However, internal team leaders’ time may be limited, which can extend your project schedule.)

Capturing risks early in your project allows for better and more comprehensive decision-making. Because decisions are good and management is more informed when approving projects,the likelihood of implementing business goals and strategies successfully increases.

For more about risk management, check out Bob McGannon’s course Project Management Foundations: Risk.

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