By Ramiro Rodrigues
Among consultancies it’s common to reward project teams for good results with financial incentives.
The question is: Does this practice lead to better results? There’s a clear difference in position depending on which side the respondents are on. The dilemma is easy to understand.
When you’re in the position to be rewarded for the results achieved, it’s natural to see the positive side of this approach. But when you are responsible for delivering the bonus, some doubt will naturally exist. After all, what guarantees that this strategy will lead to projects with better results (regarding time, cost or quality)?
Many feel these rewards act as great incentives for project teams, thus leading to better performance. But one should also consider the concerns of those who fear that, in the name of this search for metrics, some values—such as professional ethics, transparency and lawfulness—may be compromised.
To find out if the bonus strategy should be implemented at your organization, have a look at the following four steps:
Step 1: Evaluate your organization's values.
More aggressive companies that encourage internal competition tend to favor this strategy. Knowing your organizational environment well will help you determine whether to adopt the financial incentive strategy or not.
Step 2: Define quality metrics.
Interpreting success only by the results related to project time or costs may lead to short-sightedness regarding customer satisfaction. Therefore, develop templates for satisfaction surveys that can help measure the quality of the delivered product and the opinion of the customer who receives the final result.
Step 3: Encourage mutual collaboration.
Dividing the bonus between specific members or projects creates a great risk of dissatisfaction among those who have been excluded. Thus, sharing the bonus between all team members, depending on the results of the overall project portfolio of the organization, is an interesting idea to consider.
Step 4: Start slowly and measure results.
Treat the implementation of this assessment as a project and aim to progress gradually, so that you can evaluate any impacts of this strategy on the culture and value perception of your company.
Good luck and much success!
By Ramiro Rodrigues
Is risk management just an exercise in paranoia?
That’s the question I’m often asked. I like to respond by saying there are both negative and positive risks.
A risk is a situation in which it cannot be certain whether a specific result will happen. That potential cannot be discounted. Thus, any risk hypothesis—whether for small or large risks—is subject to some sort of management strategy. While we often think of negative risks, positive risks present opportunities for organizational or project gains.
Risk management strategies can be applied to our daily lives. Take, for example, my own experience.
A few years ago, I was invited to hold a workshop on project management best practices for a service company. Concerned about the event, I decided to invite a colleague whom I trust to share the work (strategy: share) and increase the chances of the workshop being successful (strategy: improve). When checking his schedule, my colleague realized that he would be returning from a trip at 6 a.m. on the day of the workshop, which was scheduled to start at 9 a.m. Even knowing that flight delays are more common than we would like, we decided to take the risk (strategy: accept).
In the weeks leading up to the event the preparation flowed well. We met with the client and tested the presentation dozens of times (strategy: explore), but the possible flight delay did not leave my mind. For this reason, I studied not only my part of the presentation, but also that of my colleague (strategy: eliminate).
When the day arrived, I woke at 6 a.m. to find two messages from my colleague on my phone. The first one said, "I've landed?” This gave me a sigh of relief. The second said, "I'm really ill. I'm going to a hospital.” I called my colleague and verified the illness.
What a great irony! All my fears arising from my colleague's risk of a delayed flight were realized, but not because of that event.
Some changes were necessary. First, I had to substitute the car journey with a taxi (strategy: transfer). Second, I had to remove specific parts from the presentation to reduce the impact of my colleague’s absence (strategy: mitigate). Even without doing so through a documented plan, I had used all of the recognized risk response strategies.
For me, it became clear that the great gain from risk management is in the exercise of thinking beforehand and being able to choose the best options available.
The outcome of the workshop? I imagine it would have been better if my colleague had been able to attend. But judging from the applause and words of praise, I believe that it was a success.
by Christian Bisson, PMP
Project success is typically defined as being completed within budget, schedule, and scope, and that has been imprinted so much in project managers’ mind that it blinds them to other important aspects that defines a project’s success.
This aspect of project success seem to be more and more popular, and with reason, if clients are not happy, they will shutdown the projects, or proceed with another organization. If your project is on budget, delivered on time, and does exactly what it should be doing, but the client is so unhappy that they ceases to work with the organization, can you consider the project a success?
For example, if you focus so much on being on budget/schedule/scope, that you decline everything the client asks for without a second thought, chances are the client will not want to work with you long term. On the opposite side, giving everything the client wants and ending up late or 200% above budget is not an acceptable alternative. You or the team will often need to be creative to find ways to balance things out, and properly managing the client’s expectations is also key top this.
Another very important aspect of project success is the value it’s adding. A project that is doing what was planned, but ends up being useless, is not a success.
For example, if you create a great website, the client loves the design, the development phase had only few minor issues that were fixed rapidly so the team is happy, the project is delivered on time, on budget, and does what it’s supposed to do, however, users that go on the website are completely incapable of finding the information they need, and they end up always calling customer service instead, then is that really a success?
It’s important to identify right from the start what metrics will be used to calculate the project’s success, and tie those metrics to features of the website as you go to make sure a feature is not useless or solves an issue that has nothing to do with the project’s objectives..
The organization that has provided the services needed to make the project happen is also a key aspect to look at to define the project success, and unfortunately often due to lack of transparency from management, can be a challenge.
For example, there are projects that the organization’s management know they will lose money on, but for them it is considered a long-term investment to bring more business. If that’s not communicated, the project manager will see the project as a failure because it’s over budget.
It’s important to have visibility on the organization’s goals and expectations around the project in question.
What are your thoughts on the matter? Do you use other aspects to define project success?
by Kevin Korterud
I always enjoy hearing about the early careers of the project managers I meet. In almost every conversation, the subject turns to when they were team members being led by a highly capable senior project manager who provided guidance in starting up, executing and sometimes turning around projects.
It’s also not uncommon to hear stories of the worst project manager they ever worked for. These stories, while not as glowing, also influenced their careers around what not to do. By probing a bit deeper, they offered up observations of certain behaviors that created havoc, dissatisfaction and quite often failed projects.
From these observations of the worst-ever project manager, I started to put together my own thoughts on who I would select for this inglorious label. After careful consideration, I arrived at the only logical choice: me. In my early years as a project manager I managed to consistently demonstrate all of the behaviors of poor project managers.
Here are my votes for the most significant behaviors that led to consistently poor performance as a project manager early in my career:
When I was a project team member I relished the thought of one day having a business card with an impressive title of project manager. My thought being once I received that lofty title, it would allow me to be successful at whatever project I was assigned to lead. In addition, the acquisition of that title would instantly garner respect from other project managers.
I failed to realize that most project managers are already quite proficient at leading teams and producing results. The title comes with a heavy burden of responsibility that was exponentially greater than what I had as a project team member. As a team member, I didn’t realize how much my project manager shielded me from the sometimes unpleasant realities of projects.
The satisfaction of acquiring the title of project manager can be very short-lived if you’re not adequately prepared. My goal became to perform at the level at or above what the title that project manager reflected.
2. I Talked Too Much
Perhaps I was wrongly influenced by theater or movies where great leaders are often portrayed in time of need as delivering impressive speeches that motivate people to outstanding results. I remember quite clearly some of the meetings I led as a new project manager that quite honestly should have won me an award for impersonating a project manager.
Meetings were dominated by my overconfident and ill-formed views on what was going right and wrong. In addition, I also had the false notion that I had the best approach to all of the risks and issues on the project. No surprise that this mode of interaction greatly limited the size of projects I could effectively lead. Essentially, it was a project team of one.
After a while, I started to observe that senior project managers spent a fair portion of the time in their meetings practicing active listening. In addition, they would pause, ponder the dialogue and pose simple but effective probing questions. When I started to emulate some of these practices, it resulted in better performance that created opportunities to lead larger projects. “Less is more” became a theme that allowed me to understand the true problems and work with the team to arrive at effective mitigations.
One of the most critical components of any project is the people that comprise the team members and stakeholders. As a new project manager, I tended to over-engage with stakeholders and team members by attempting to instantly resolve every issue, whether real or perceived. My logic was that if I removed any opportunity for dissatisfaction then project success would be assured.
I failed to realize this desire to completely please everyone quite often resulted in pleasing nobody. In addition, I also managed to pay insufficient attention to the key operational facets of a project: estimates, forecasts, metrics and other essentials needed to keep a project on track. Furthermore, the business case for the project gathered almost no consideration as I was busy trying to make everyone happy as a path to results.
Over time I began to adopt a more balanced approach that allowed me to spend the proper level of engagement with people, processes and the project business case. This balanced approach allowed me to have a broader span of control for factors that could adversely affect a project.
For all the things we have learned over the years as project managers, it sometimes causes me to wish for a time machine to go back and avoid all of the mistakes we made. But then, we would not have had the benefit of the sometimes-traumatic learning experiences that have made us the project managers that we are today.
Did you ever consider yourself to be the worst project manager you ever worked for? I think we all were at one point in our careers.
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?