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.