A Checklist for Shared Outcomes
Education and Training,
Human Aspects of PM,
Categories: Benefits Realization, Best Practices, Career Help, Change Management, Communication, Communication, Complexity, Education and Training, Ethics, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Leadership, Leadership, Lessons Learned, Mentoring, PMOs, Portfolio Management, Procurement, Program Management, Project Delivery, Project Failure, Project Planning, Roundtable, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
I was recently assigned to transform a procurement team into one that managed outsourcing partnerships. I realized the team was very disengaged, leaving the strategy up to me to define. There was no buy-in. The team and the partnerships were sure to fail.
But I was determined to make the team successful. For me, this meant it would be accountable for managing thriving partnerships and delivering superior outcomes.
To get things back on track, I had to first get alignment on goals. Setting shared goals can help to shape collaborative and accountable teams that produce desired outcomes.
Establishing goal alignment can be a difficult leadership challenge; however, leaders must gather the needs of all stakeholders and analyze their importance to achieve the desired organization outcome.
I often use this checklist to tackle this challenge:
I used this checklist during the procurement team project and it helped to reset and reinvigorate the team. Once we aligned around shared goals, team collaboration increased and the organization started to achieve the targeted business benefits.
If you’ve used a checklist like this before, where have you stumbled and how did you turn it around?
By Ramiro Rodrigues
When outsourcing a job to consultants and service providers, I’ve often found that achieving "agreement" with a client that a project is finalized is one of the most delicate times.
This is usually due to the fact that by closing the project the client knows that:
Scope verification—the process of formalizing the approval of a project scope—recommends progressive approvals are made as partial deliveries of the scope take place. This process, if well planned and applied, helps to minimize the weight of the final approval term.
The strategy I developed over many years of consulting work is something I call “ground preparation.” This strategy has four simple stages that need to be well distributed in the time near the project closure to increase your chances of a non-traumatic closure.
Let's review them:
1st Stage: As you move close to the end of the project, start the conversation, preferably face-to-face, with the stakeholder responsible for accepting the project.
2nd Stage: Send that same stakeholder a draft version of the project acceptance document that is as close as possible to the final version.
3rd Stage: After giving the stakeholder time to digest the draft, follow up to discuss any questions or concerns. Also, this is a good time to let them know when they can expect the final acceptance document.
4th Stage: Send the final version of the acceptance document and suggest that you collect it with, if applicable, some sort of closing event.
Of course, we are talking about a project that has successfully achieved its goals. But even projects that have had to be aborted or projects with a low degree of success at the end must be formally shut down. A lot of this strategy can be replicated whenever the end is imminent.
What are your strategies for closing down a project?
In my next post, I will review the characteristics of the acceptance term for internal customers.
By Kevin Korterud
I experienced my first agile project nearly a decade ago. At the time, agile was still an emerging concept. I remember thinking there were all sorts of activities going on that I had never seen on any of my projects. People were standing up for meetings, marker boards were filled with things called “stories” and delivery moved forward under the framework of a “sprint.”
At the center of this whirl of frenetic activity was a person who the team called a “scrum master.” At first, I thought this person was a project manager. But they were doing things that were outside of the traditional project management realm.
Since that first experience, agile has matured and continued to grow in popularity. This trend prompted me to examine the evolving role of the scrum master in complex agile delivery environments. Here are my observations:
1. Agile Delivery is Becoming Mature
Agile delivery teams used to function within isolated pockets. But, as the use of agile—as well as the size and complexity of solutions being delivered—grew, new methods, such as SAFe®, were developed to help orchestrate agile delivery across an organization.
With agile becoming more common in organizations as a delivery method, the overall need for scrum masters’ general process advice diminishes. Agile teams over time—as well as with the support of enterprise framework methods—will become more self-sufficient, which reduces the need for some of the current activities performed by scrum masters.
2. Higher Engagement and Direct Accountability
One of the guiding principles for scrum masters is that they are not supposed to intervene with the team and are not responsible for delivery outcomes.
While a focus on process advice was essential during the early days of agile, today’s larger and more complex solutions demand that delivery quality issues be identified as soon as possible. In addition, there is also a need to ensure on a more frequent basis that the solution being created will yield the desired business outcomes.
Given its proximity to agile delivery teams, the scrum master role is positioned to leverage a higher level of engagement and accountability. In addition to traditional agile process advice, scrum masters should also serve as a durable checkpoint for both delivery quality and alignment to business outcomes.
These checkpoint activities would include reviewing user story quality, monitoring non-functional requirements and checking solution designs against business needs. As other roles in agile delivery possess some form of delivery accountability, the scrum master must also become more engaged and accountable in order to remain relevant.
3. Emerging Project Managers Becoming Scrum Masters
While scrum masters are not meant to be project managers, that notion is preventing project managers from becoming scrum masters, especially earlier in their career. Emerging project managers invariably have some form of solution delivery experience. They know what makes for sound requirements (especially non-functional), designs, testing, quality and implementation plans.
As the level of complexity and scale increases with agile delivery, so does the need for some form of delivery oversight at the agile team level. With the scrum master position in their repertoire, teams would have developed competencies and know-how for scaled agile delivery, release train engineer, program manager, etc.
Scrum masters have played an essential role in the growth and adoption of agile as a practical means of delivery. Their direct interactions with agile delivery teams create a unique opportunity to expand their influence in generating valuable outcomes for end-users, consumers, customers, employees or suppliers. To do so, they need to further extend themselves— both in terms of skills and engagement—to remain relevant in today’s complex delivery environment.
How do you feel the scrum master role has evolved? Are newly minted project managers the scrum masters of tomorrow?
Imagine this scenario: You are the project manager of a new, strategic project of your company. Excited, you prepare the necessary documents and schedule the project's kick-off meeting.
The kick-off meeting seem to be going well, until you start presenting the necessities and you notice resistance coming from functional managers in ceding their resources.
And it’s only then you realize your mistake: You should have invited the project sponsor to the kick-off.
Kick-off meetings, which should take place between the end of the planning stage and the beginning of implementation, are of paramount importance to the success (or failure) of a project. And you must prepare.
For the project manager, the kick off is a great opportunity to ensure that your stakeholders are identified, to demonstrate that there is a common gain in the success of the project, to map out the stakeholder predispositions and to ensure that their respective roles are understood.
Here are four things to keep in mind:
1. The Invite List: You must have the other relevant stakeholders in the room—functional managers, the customer of the project product and all those who can have an influence, either positively or negatively.
2. The Meeting Infrastructure: The size of the room, amenities, coffee break and everything else that make the environment appropriate.
3. The Presentation: The kick-off meeting will be your moment to demonstrate that the project is well planned with mapped risks. But, keep your audience in mind. For example, the sponsor, usually an executive with no time to see the details, will be present at this meeting. Make your presentation concise and objective by showing that you have a clear vision of where you want to go.
4. The Sponsor: The great benefit of the kick-off meeting is to get commitment to the development and success of the project. Without it, the project manager always runs the risk of having their needs not met. This is where the essential participation of the sponsor comes in. He or she typically has a politician's nature.
Even though it is up to the project manager to conduct the meeting, it is essential that, soon after the welcome is given, the project manager gives the floor to the sponsor. They can use their position within the organization to "suggest" to those involved to give their support, resources and conditions to the project manager on behalf of the expected results of the project. With the sponsor message given—even if he or she leaves right after they speak—there is a greater chance that everyone else will understand and support the project and that will make the rest of the meeting easier for you.
Leaders exert influence for success
Education and Training,
Human Aspects of PM,
New to Project Management,
PM Think About It,
PMI Pulse of the Profession,
Reflections on the PM Life,
Categories: Agile, Benefits Realization, Best Practices, Career Help, Change Management, Communication, Complexity, Education and Training, Ethics, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, Mentoring, New to Project Management, PM Think About It, PMI, PMI Pulse of the Profession, PMOs, Portfolio Management, Program Management, Project Delivery, Project Failure, Project Planning, Reflections on the PM Life, Roundtable, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
Whenever I’m in a leadership role I try to be sensitive to the level of influence I gain, retain and lose. Influence is a precious commodity for a leader. And it can be disastrous if you lose your team or if tensions arise that reduce one’s effectiveness to achieve a goal.
I recall one of my client assignments where the goal was to ensure a successful integration of a complex merger and acquisition. The team had slipped on dates, missed key meetings and there were no formalized milestones.
I set up casual meetings to discuss with each member what would motivate them to participate. One clear signal was that management had changed the acquisition date several times. This disengaged the team due to false starts that took time away from other priorities.
During the sponsor review, I reported there was a communication breakdown and that no one shared this effort as a priority. At that point, the sponsor could have used his position of power to pressure everyone to do their part. However, the sponsor did not want to come off as autocratic.
Instead, he asked if I would be willing to find an alternative approach to get the team’s buy in.
I realized my influence was low, but I wanted to help improve the outcome for this team. So I talked again with each team member to negotiate a common approach with the goal to be integration-ready without having an exact date.
Ultimately, our goal was to have all milestones met while a smaller core team could later remain to implement the integration when management announced the final date.
A leader uses influence as part of the process to communicate ideas, gain approval and motivate colleagues to implement the concepts through changes to the organization.
In many cases, success increases as a leaders exert influence over others to find a shared purpose.
Tell me, which creates your best outcomes as a leader: influencing others through power or through negotiation?