Stakeholder Management: 5 Ways to Resolve Conflict

/in /by

This week’s article comes from my fellow LinkedIn Learning author Natasha Kasimtseva.

Projects are the vehicle of change, and a key project manager competency is leading the team through rough waters of learning and evolving. Resource constraints, competing priorities and requirements, differences of opinion – these are a few examples of the sources of conflict that can impede project delivery. So how do we reconcile differences and resolve conflicts on a project? 

  • Recognize that conflict is not always a bad thing. Conflict can be an opportunity to enhance clarity and alignment. Say your team is resource-constrained and your key stakeholders disagree on which features to build first. This can be a great opportunity to go back to the drawing board and evaluate and rank features to make sure the ones with the most business value get implemented first. 
  • Pay extra attention to communication. Building lines of communication becomes more critical in the era of remote work. Information exchange that used to happen organically (“water-cooler” conversations, team lunches, informal touch-points) now have to be engineered using communication technology. Invite your team members to have coffee over Zoom or schedule an informal touch-point using MS Teams. 
  • Keep the project team on the same page. A Single Source of Truth for the team to lean on is a great way to reduce confusion and potential conflict. Project management software with real time reporting can be a great investment. Tools like JIRA and SharePoint can provide virtual space where the team members can retrieve necessary information to stay informed. 
  • Try short interactive meetings rather than lengthy project debriefs. More interactive methods like SCRUMS and STAND-UPs resolve misunderstanding between technical and business teams.  Shorter, more frequent meetings provide teams an open forum to remove roadblocks and collaborate. 
  • Focus on belonging and inclusion to create trust and respect within the team. As project managers, we often work with multi-disciplinary teams and have to be aware of different layers of diversity, including organizational and cultural. Aligning your team around common project goals and team values will build a stronger synergy and break up the silos. 

If you would like to learn more about managing project stakeholders and conflict resolution, check out these LinkedIn courses:

Project Management Foundations

Managing Project Stakeholders 

Mistakes to Avoid When Resolving Conflict 

Developing Cross-Cultural Intelligence

5 Ways to Increase Project Quality

/in /by

Photo by Adeolu Eletu from Unsplash

A big part of project success is meeting business objectives. Project quality is the degree to which a project meets its objectives. Here are five tips to ensure the quality of your project outcomes.

  • Don’t jump to the solution too quickly. The foundation of delivering quality is ensuring that your project solves the problem or supports the desired opportunity. To ensure that you deliver a quality solution, take the time to research the current tools, processes, strengths, and weaknesses in your business area.
  • Unfortunately, projects are often launched with a particular solution in mind. For example, if your organization runs a project to implement a new finance system when lack of financial control is due to poor control processes, the project is a waste of time and money. Do your homework to identify the problem and root cause before launching a project.
  • Build customer engagement from the project start. You need input from the right people to deliver a solution that supports the stakeholders’ needs—not only knowledgeable people, but people from each affected stakeholder group. Include those people as you gather requirements and don’t assume you understand the stakeholders’ needs. Otherwise, your project deliverables could go unused, when the unsatisfied stakeholders declare them unfit for the business.
  • Don’t shortcut testing. Testing is often scheduled at the end of the project. As deadlines loom, testing is often reduced to keep delivery schedules on track. Although that approach may deliver on time, the probability of product issues is high. To ensure quality project outcomes, make testing time sacred and include testing activities throughout your project lifecycle.  For example, reviews of paper deliverables, engineering models, mock business walkthroughs, and software prototypes will save you save time and money in the long run.
  • Focus on business processes. Two process-related activities are crucial, yet often overlooked. First, be sure to capture as-is processes, so your project doesn’t overlook business activities it needs to accommodate.  Second, update to-be business processes as deliverables are built and changes accommodated. If you don’t, staff training won’t cover the changes, which could lead to misunderstandings about what your product can and cannot do. To achieve business outcomes,  implement standard project activities to capture and document as-is and to-be business processes. As the team produces deliverables, it should also create and document the corresponding new or altered business processes.
  • Take human factors into account. Peter M. Senge said, “People don’t resist change. They resist being changed.” The perceived quality of your deliverables depends on your ability to bring your stakeholders along on your project’s change journey. Involve your stakeholders early, keep them informed as you progress, especially as changes are made. By doing so, you will increase your chances of your outcomes satisfying the business objectives.

For more about project quality, check out Daniel Stanton’s Project Management Foundations: Quality course.

Project sponsor and project customer: what’s the difference?

/in /by

In a recent LinkedIn Live session, someone asked, “What exactly is the difference between a project sponsor and a project customer? Sometimes, the sponsor is also the customer, but the roles have notable differences: 

Authorizing or terminating the project. The project comes about because the project customer has a problem to solve or opportunity to pounce on. And the project customer’s needs must be met for the project to be a success.

However, it’s the project sponsor who authorizes the project launch, usually by signing a Project Charter. (The Charter also names the project manager and lays out their responsibilities and authority to manage the project.) The sponsor can also cancel the project should business conditions change or due to poor project performance. The project sponsor typically consults with the project customer before launching or terminating the project. Bottom line, the sponsor makes the final decision.

Directing project governance. The sponsor owns responsibility for meeting the terms of the project’s business case.  The sponsor is responsible for managing the project manager, sharing project status, ensuring customer needs are met, authorizing risk response actions, and handling issues that the project manager can’t resolve. While much of the work related to these responsibilities sits with the project manager, the project sponsor has the ultimate responsibility to ensure the project is managed with sound business judgment.  On the other hand, the customer’s role is to comply with project governance and inform the project manager if governance is being compromised within the business area they represent. For example, customers need to analyze change management requests to ensure they are in the best interest of the customers’ business areas.

Funding. The source of funding may come from the sponsor’s budget or from the budgets of project customers. The project sponsor, however, controls allocation of funding for the project and management of any project contingency funds. Decisions on the release of funding to obtain project-related equipment, supplies, and contracted skills or to pay employees assigned to the project are made by the project sponsor. If finances are constrained, the customer typically helps prioritize deliverables. The customer and sponsor will discuss different business scenarios, and then the sponsor decides on the final prioritization.

Assigning and prioritizing project resource work. The customer informs the project manager of staffing constraints due to existing workloads, but that’s where their responsibility stops. The project sponsor allocates the skilled resources needed to complete project tasks. This allocation often involves prioritizing workloads, because many project resources don’t work full-time on projects. They have their “day jobs” and project work represents responsibilities over and above their normal workloads. The project sponsor often needs to relieve staff of some of their normal work responsibilities to allow project tasks to be completed on schedule. Project resources often report to managers other than the project sponsor, so negotiation is required to get the resources necessary to meet project deadlines.

For more about project sponsor and customer roles, check out my Project Management Foundations course.

Managing change in agile projects

/in /by

A learner in my LinkedIn Learning online project management course asked, “Is it true that agile methodologies don’t require change management to handle new requests?” Actually, change management is baked into the Agile approach. Here is how Agile manages change using the terminology of traditional project methodologies. 

There is a Change Control Board. In Agile, the team plays the role of the Change Control Board. When features are being developed and improvements are suggested, the team accepts or rejects them. When new features are proposed, the team determines whether they will be included in the product backlog. Like a traditional project approach, the team consists of both technical and business team members, so appropriate backgrounds come together to make change-related decisions. 

Change requests are received and evaluated. During each sprint, the team examines the work in progress and discusses improvements. This serves the same purpose as the submission and evaluation of change requests in traditional methodologies. Similarly, when additional features are added to the backlog, the team examines and prioritizes them. If the team prioritizes them to be completed within the project’s schedule and budget constraints, the features are delivered. 

The impacts of change are assessed. When a new feature is accepted, sized, added to the backlog plan and prioritized, the impacts on time and scope are evaluated. Sizing the feature describes the impact to cost. Adding the feature to the backlog changes the scope. If no features are removed when the new feature is added, then the scope is increased. If another feature is removed when the new feature is added because of time and/or cost considerations, that means the scope is managed according to the business value. 

Change requests are resolved and communicated. Features that are developed come from the backlog. Any feature added to the backlog during sprint cycles is the equivalent of a change. Delivery of that feature is essentially the same as resolving a change request. Communication of change resolution occurs through the backlog status boards, iteration plans and release plans.

For more about Agile projects, check out the LinkedIn Learning Agile learning path.

The Project Manager’s Relationship with Risk

/in /by

In a recent LinkedIn Live session, a viewer asked, “How did you learn to embrace risk-taking?” A project manager isn’t the risk-taker in a project—risk is inherent in every project. However, it’s true that project managers must embrace risk. Project managers need to understand the risks within their projects as well as what risk management entails.  The project manager also helps the entire team understand the project risks, strategies, and risk management approaches. Here are some things project managers can do to manage project risks effectively: 

Alert stakeholders to risks. Part of the definition of a project is “to create a unique service or product.” Uniqueness means risk will be present, so project risk comes with the territory. One project manager duty is to ensure that the organization fully understands those risks. The project manager is like the “risk consciousness” for the business. For all the risks identified in a project, the project manager should alert stakeholders and ensure that everyone understands the strategies for handling the risks should they occur. 

Watch for risk triggers. Risk triggers are typically conditions that arise prior to a risk coming to fruition. Watching for them is critical, because they provide early warning to prepare for taking action on the issue. Potential risk triggers could be delays due to busy personnel; delivery delays caused by COVID restrictions, or ships being stuck in canals! When a risk trigger occurs, jump in to update and review associated risks, impacts, and response activities. That way, you’ll be ready to handle the issue when it occurs.

Create a risk management culture. Many risk plans are written and then filed away to gather dust. A project manager can ensure this NEVER happens by embracing and promoting risk management. To regularly draw focus to risks, review upcoming risks in project briefings and status meetings. This integrates risk management into your project culture.

Keep the risk plan up to date. As the project progresses, things change. Update your risk plan accordingly.  

Manage risks your sponsor considers acceptable for the project. The job of the project manager is to ensure risks are understood – not to stop project sponsors from taking them. Taking risks is part of project delivery and a significant part of staying competitive in a quickly changing marketplace. Roll with it – and report status frequently so everyone understands where your project lies relative to its risks.

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

Photo by Anthony Da Cruz from Unsplash

Managing Project Contingency Funds

/in /by

Contingency funds come in handy for mitigating project risk and handling unexpected issues. How much contingency funding do you need? And how do you manage it?  Here are some tips:

Consider the cost of risk responses. After creating your risk management plan, estimate how much money you need to address the project’s high-probability risks. If the project has few risks, you might do this for medium-probability risks, too. The total cost for addressing risks is your initial estimate for contingency funding. Then, work with your sponsor to adjust and recommend contingency funding for the project based on the overall level of risk present in the project. (For example, a project might have few medium to high probability risks, but scads of low probability ones. In that case, you might add contingency to cover low probability risk that do come to fruition.)

Align contingency funds with the project business case. Organizations usually have required payback times, cost savings or profit improvement targets that must be met for a project to be approved. Calculate the impact of contingency funding on those financial targets. Ideally, the project will still satisfy business case criteria after the addition of contingency funds to the budget. However, increased costs for handling risks or other unexpected costs may mean the project doesn’t satisfy those business criteria. If the contingency funds needed jeopardize the project’s business case, revisit the project approach and costs, or reconsider whether to pursue the project. 

Determine who can release contingency funds. Before the project gets going, decide when contingency funds will be released, who authorizes them, and in what circumstances they will be released. Traditionally, the sponsor releases contingency funds. However, giving the project manager access to these funds when specific risks occur can increase efficiency and reduce the impact to the project. Document the decisions you make regarding how contingency funding will be released, so you don’t encounter roadblocks accessing the funds.

Track and return funds to contingency when possible. Keep track of the contingency funds already spent and still available in your contingency budget. If parts of your project end up costing less than planned, you might recategorize those unspent project funds to replenish your contingency budget. 

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

Managing Unacceptable Project Variances

/in /by

Projects never run exactly according to plan, so project variances are inevitable. To keep your projects on track, you need to take action when variances are about to become – or already are — unacceptable. Here are some tips for managing variances.

Respond quickly. Small variances in your schedule or costs can grow large before you know it. Don’t wait for the next project report to respond. As soon as you see variances, talk to your team to find out what’s going on. Maybe the accounting department made a payment earlier than planned to score a vendor’s price incentive. Or a key team member was out sick a few days. When there isn’t a reason for the variance, focus on what’s driving that variance and monitor it closely. If necessary, recommend changes to your sponsor for getting things back on track.

Focus on scope. Thoughtful examination of project scope often uncovers opportunities for saving time and cost. Break scope down into individual requirements and analyze each one’s business value to identify candidates for reducing scope. Often, the value a requirement provides isn’t worth the cost to produce it. These requirements are easy targets to reconsider when you’re looking for ways to reduce project variances.

Scrutinize resourcing. Seeking the best resources for your project typically yields the very best results. However, “very best” might not be necessary–or wise–if those resources create unacceptable cost or schedule variances. The best resources are usually the most expensive, especially with contracted personnel. Availability issues with your top internal resources can lead to schedule slippage. One way to save time and money is to review your resourcing plan and choose people who are more available who can produce deliverables for senior team members to review. For your contracted resources, see if less expensive alternatives can be used—again with senior internal staff reviewing the deliverables they produce.

Increase reporting. Project variances capture the attention of senior stakeholders. They expect you to live up to your title of project MANAGER! Immediately inform your stakeholders of any project variances so they don’t hear about the issue from others. Increase your report frequency to keep interested stakeholders abreast of how you are addressing the variances.

For more about managing project variances, check out my Project Management Foundations course.

What qualifies as a project?

/in /by

Photo by Lala Azizli on Unsplash

During a recent LinkedIn Live session, an attendee asked “What actually qualifies as a project when summarizing project management experience? Could it be creating a lesson plan or procuring items for a charity auction?” 

According to the Project Management Book of Knowledge (PMBOK®), a project is a temporary endeavor undertaken to create a unique project, service, or result.

Let’s dig a little deeper to see what qualifies as a project.

A project:

Satisfies a set of requirements. According to PMI®, projects create a unique product, service, or result. That unique result needs to satisfy some established requirements. Without requirements, you won’t know when your endeavor is complete. Although you can launch an Agile project without fully defined requirements, you still need some high-level requirements to get started.

Requires a sequenced schedule of activities. To qualify as a project, the project goal needs a purposefully sequenced series of task. Otherwise, you’re just working on your ongoing to-do list, which doesn’t qualify as a temporary endeavor.

Considers scope, time and costs. Fundamental to qualifying for projecthood, a project must produce a result that’s at least partially defined when it starts (scope), work with a schedule of tasks (time) and work within a budget (costs.) In other words, scope defines the project result; the schedule of tasks completes the scope within a timeframe, this making the project temporary; and people and other resources (which incur costs) are needed to complete the tasks.

You could argue that only two of these elements (scope, time and cost) are required.  Occasionally, a project won’t have a prescribed deadline or budget is not a major factor. If you’ve run projects that only require management of two of these three elements, you aren’t truly an experienced project manager. 

Produces benefits. A project delivers a unique product, service, or result; and it takes time and money to do so.  To justify that time, money, and effort, the result has to produce some kind of benefit to the organization.

Given these conditions, does creating a lesson plan or procuring items for a charity auction be considered a project? Yes!

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

Effective Project Management During the Pandemic

/in /by

In one of my recent LinkedIn Live broadcasts, someone asked how project management could evolve, given new and changing rules imposed by the pandemic. Here are a few key ways in which project management could adjust to be effective during the pandemic.

Focus on using tools for remote work effectively. More than ever, project management involves people working remotely, which amplifies the need for contact and useful communication tools. Those shiny new team management tools available today provide new communication and collaboration capabilities. However, without establishing new habits, those tools might be used improperly (or not at all) leading to missed or mangled messages. To ensure tools for remote work actually work, get with the team to understand the habits and approaches they use from their home office.  Then, strive to align your stakeholders around a common set of practices.

Address work circumstances in project requirements and the requirement gathering process. The pandemic adds a whole new dimension to requirements collection. Team members and clients might work in offices, at home, or both. They might work different numbers of days per week in each location. They might work different work hours because of childcare responsibilities. These circumstances are a consideration both for the requirements gathering process as well as the project requirements themselves. The idea of belonging and inclusion that is popular thinking in the talent management world needs to be applied to projects. Project requirements should address how information and interactions are transferred and how integrations between processes and tools are managed. And the requirements process should support requirement gatherers and requirement providers working in different places and on different schedules. One things for sure — counting on people sharing information over the cubical wall is a thing of the past.

Robust communication planning. Communication needs are broader and more challenging. during the pandemic. How do you ensure stakeholders feel informed when you can’t see their reactions easily? The Project Management Institute (PMI) states the person who initiates communication is responsible for ensuring it’s received and understood. That takes serious work when stakeholders are dispersed and remotely located. In a pandemic-era communication plan, center stage belongs to follow up calls, careful scrutiny of email replies, and diligent follow-up when no response is received.

Place emphasis on integration and interaction risks. Risk plans should emphasize specific risks associated with integration, interactions between staff members, and assumptions about serving clients. For example, we can’t assume transport or product delivery will be normal until the pandemic truly subsides. While things are improving in wealthier nations, virus-related impacts and restrictions could remain in other countries for some time to come.

More focus on organizational change management. Peter Senge is quoted as saying “People don’t resist change. They resist being changed.” Organizational change planning and execution needs to have greater emphasis in our pandemic-affected world. Change can be difficult because of isolation and the stressful changes people have to make. Be sure to focus on potential change fatigue and work hard to understand the magnitude of change people need to absorb. Also, consider how to provide more individual attention to stakeholders to ensure project business outcomes are realized through organizational change.

Do you have suggestions for other ways project management needs to adjust for pandemic realities? Let’s get a conversation going in the comments! The LinkedIn Learning library has some great courses about working and building relationships when working remotely. Go to the library and then search for “remote work.”

Budgeting in an Agile Environment

/in /by

Photo By Leon from Unsplash

In one of my recent LinkedIn Live broadcasts, an attendee asked about budgeting in an agile environment. Here are the steps for building and maintaining a sound budget for an agile project. 

Step 1. Determine your Minimum Viable Product (MVP). The MVP is the smallest possible product that will satisfy the most important business needs. To deliver value to your business as soon as possible, building the MVP (and nothing more) in your initial release is sensible. That way, you deliver the product faster with the smallest budget. As the MVP is used and more is understood, the business can fund development of additional functionality as needed.

Step 2. Build your estimate around people and time. With the MVP identified, the team can estimate how many people and sprints will be required to build and test those functions. This is an easy way to build an estimate. If you plan to have three developers for 12 two-week sprints, your initial estimate is the cost for 72 person-weeks (3*12*2) plus overhead costs needed in your organization.

Step 3. Adjust the number of people and sprints as you learn. Like any project, your initial estimate involves guesswork. As you build features and work through your backlog, you will probably need to adjust your budget. The team should proactively agree to when to re-evaluate the budget. After three to five sprints is a good rule of thumb. Like your original budget, the adjusted budget can be built based on the number of people and sprints, and the length of the sprints.

Step 4. Augment the budget for specific features. The priorities and needs of the business can change during your project.  In addition, discoveries or new ideas for features can surface. As a result, the business may decide to add or delete features and increase/decrease the budget accordingly. While this creates a bit of a moving feast with your project and budget, the changes are made to accommodate the needs of your product owner. 

Step 5. Keep stakeholders in the loop. Ensure your stakeholders are aware of the status of your budget. This is relatively easy with the agile approach. Whenever there are changes to the backlog (when scope is added or deleted,) you communicate those changes and the corresponding budgetary adjustment. By sharing the approved scope changes, you proactively answer any questions about why the budget has changed.

Managing your budget in an agile environment is a straightforward process as long as the agile team manages backlog features in conjunction with the product owner. Follow these steps and worrying about budget management will be a thing of the past! 

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

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