Skip to main content

Author: Kiron Bondale

Five Signs That You May Not Want to Become a Project Manager

Sustained demand for skilled project managers continues to attract newcomers to the profession – some are just starting their careers while others are looking to start a new phase of their working life.

Job shadowing, information interviews, online sites and volunteer work are all great ways to learn something about the profession, but these avenues are unlikely to provide you with sufficient insights into the daily life of a project manager to determine if this is the right career path for you.

Given this, you may wish to review the following list to see if you exhibit any of these warning signs.

You are not comfortable with change and ambiguity

Project management is the medium by which strategic changes get realized, so one might reasonably assume that most project managers would be thriving on change.

Unfortunately, change resilience is a continuum and not a binary attribute.

I’ve witnessed project managers who are quite comfortable with the magnitude of the change that will be implemented become defensive and even aggressive when shifts from within or without their organization result in scope changes. A plan is just a model of reality based on a foundation of assumptions and when reality shifts, the plan needs to shift with it.
If you are someone who prefers to have all the information required before making a decision, the uncertainties that are part of the DNA of projects are apt to drive you crazy. Yes, you can try to engage more and more stakeholders and subject matter experts to fill in the gaps for you, but there is a tipping point after which further delays and costs of analysis will outweigh the impacts of a bad decision.

You prefer working with tools than with people

Hard skills are table stakes for project managers.

I realize that creating a perfectly optimized, fully resource-levelled project schedule might be a euphoric experience, but that should just be a means to a greater end.
Your ability to align multiple stakeholders with competing agendas or to cultivate a performing team made up of diverse personalities and egos all with little or no formal authority are orders of magnitude more critical to succeeding as a project manager than your expertise in wielding the multiple tools of the trade.

When working on a project, if you find yourself frequently saying it would be much easier if you were the only person involved with it, project management may not be your thing.

Related Article: 10 Must Have Skills for the Project Manager

You avoid difficult conversations

I’m sure that all of us have wished for the following scenario: fully aligned stakeholders, a team of subject matter experts who all work well together, generous cost and schedule constraints, and a well understood and easy to deliver set of deliverables.

The reality of project management doesn’t quite fit this vision.

Many times over the life of any moderately complex project you will need to have a tough conversation with someone. Perhaps a deadline is in jeopardy, the project will cost more than expected, or a team member is not performing up to expectations.

Your ability to analyze the situation and situationally react to it may be the difference between a customer who is peeved for a few minutes but gets over it quickly or project failure.

Yes, we all want to be liked, but if you shy away from difficult project conversations, you will end up as a likable but ineffective project manager.

You have to be the smartest person in the room

Staff who are suddenly moved into a project management role face a common challenge. They might make excellent subject matter experts but make poor servant-leaders.

Unfortunately, for some SMEs no amount of training or coaching is sufficient for them to put aside their desire to be the center of attention.

There’s nothing wrong with this need, but it is the wrong ingredient for succeeding in project management.

A good project manager finds a way to effectively leverage all the skills on the team, positions the team front and foremost for recognition & reward while shielding them from criticism or negative feedback.

You can’t multitask

Over the life of a project, there are always multiple critical activities needing to be handled by the project manager. The demands and actions of stakeholders and their team members heavily influence a project managers’ days

You might have preferred to have finished publishing the minutes from your last meeting, you need to meet this very moment with two team members who are getting into a heated philosophical argument. Telling them, “Sorry I’m busy” sends the message that you don’t care about them or about the impacts this disagreement are having on the project.

If working on fifteen different activities, but not completing any of them leaves you feeling unfulfilled at the end of the day, stick with the role of an individual contributor.

Project management has become a very popular profession so it’s quite understandable that you’d want to pursue it. As the Rolling Stones sang so well: “You can’t always get what you want”.

Are you the CEO of Your Project?

Project management has been identified as an important competency for those who aspire to a seat at the senior leadership table. But simply having managed projects is rarely enough – have you sufficiently demonstrated the skills required to be a successful C-level executive? If your sole focus has been on delivering your projects within the triple constraint, the answer is probably not.

It is quite common to hear project managers complain about having insufficient formal authority to make decisions on their own without having to seek approval from more senior stakeholders. While it can be frustrating to try to meet deadlines when decision making is prolonged, this also shelters the project manager from the consequences of making the wrong decision. This is not a luxury that most senior executives enjoy – with greater power over decision-making, comes greater responsibility such as the inability to pass the buck if a bad decision is made.

So how can you start to demonstrate this ability when you might not be vested with any formal decision-making authority?

One way is by committing to your recommendations in the face of resistance – be decisive. Yes, you may not have the final say, but demonstrating a track record of standing by what you’ve determined to be the right course of action and being willing to share in the pain if the decision is wrong will usually be viewed positively.

Strategic thinking is another critical competency for an executive leader. The purpose of your project is not to create deliverables but to generate business value. When contemplating a course of action, such as a response to an issue or the analysis for a change request, are you considering the impacts on business value realization? Or are you just considering impacts on your project’s budget and timelines?

Extend your perspective beyond just your project and consider its place in the overall portfolio. A decision which might be in the best interest of your project could end up negatively impacting others within your project portfolio or could end up generating technology or process debt which will cost the organization more in the long run. This requires increasing your business process knowledge as well as extending your gaze by understanding the dependencies between your project and others in the portfolio. It will also affect how you communicate with your stakeholders. Frame your status updates or calls for action in terms of overall business and not just project impact.

How do you manage risk in your projects?

Formal project risk management is insufficient. Yes, that can help to identify and respond to threats and opportunities, but a CEO is responsible for incorporating risk as part of every key decision. Experiment using tools such as expected monetary value to help you determine which is the path which best fits within your organization’s risk appetite. Whether it is deciding on the specific practices or methodologies that best apply to your project, or building support for a change request, demonstrating that you have comfort with risk-based decision-making is critical to transitioning to a more senior role.

How well do you manage expectations?

In publicly traded firms, the persistent inability to meet or exceed shareholder expectations for financial performance usually results in the removal of the CEO and other key senior executives. On projects, it is no different. I’d written an article five years ago that explained why I felt that the elevator pitch for selling the value of project management is predictability. Whether your project is running smoothly or is encountering chronic difficulties, you need to learn to manage stakeholder expectations so that they are not surprised.

Remember that “what have you done for me lately?” applies equally well to project managers as it does to CEOs. Just because you’ve managed a string of projects successfully doesn’t mean that you can get away with one or more project failures. If anything, a consistent track record of success will usually raise expectations for future performance.

Are you an effective leader through both good and bad times?

Some project managers are at their best when things appear to be at their worst whereas others are only good at keeping a project running when all is well. A successful senior executive should be able to inspire commitment and alignment from the organization regardless of how dire things are. This requires developing and communicating a vision compelling enough for team members to embrace and being able to draw out the strengths of the team to make the whole greater than the sum of its parts.

Yishan Wong summarized the responsibility of a CEO with the following quote: “Everything ultimately becomes the CEO’s problem, no matter where it starts.”

Do you manage your projects keeping that in mind?

Let’s Take a Drive to Delphi!

Mention Delphi method to anyone who has passed their PMP certification exam and you will likely be told that it’s an information gathering technique used to gain consensus from a group of experts. Press for more information and you’ll hear that it involves anonymous submission of initial feedback. All true, but that is like saying that a rose is just a flowering plant!

Delphi is one of the few tools which can be used on almost every project and at multiple points over its lifetime. However, because most foundational project management courses rarely provide sufficient explanation of how to apply it, many project managers lack the comfort to use it effectively.

So what are some conditions which should prompt you to consider using Delphi?

  • Differing points of view. When preparing to gather input, Delphi can reduce the likelihood of a philosophical war breaking out if you are already seeing evidence that there is likely to be a difference of opinion. By using Delphi, while there still could be debate, but the focus will be on the problem and not the people.
  • Subject matter experts include a mix of extroverts and introverts. While the level of expertise may be similar, if one team member is more outspoken they might have the tendency to stifle feedback from their quieter peers. A good facilitator can certainly direct questions to the latter group, but they might still lack confidence or desire to challenge their more vocal colleagues. Delphi levels the playing field by ensuring that everyone’s voice gets heard.
  • Significant uncertainty. If there is objective evidence to support a decision, Delphi adds little value. However, when there is a great deal of uncertainty, assumptions are likely to proliferate and Delphi provides a good way to expose and challenge these assumptions.
  • Impact of bias. If everyone is likely to have the same assessment of the scenario, there’s no point in using Delphi. However, if individual bias is likely to affect people’s perceptions, Delphi can reduce the impacts of bias on the final decision.
    Based on these criteria, the following situations could all be opportunities to use Delphi.
  • Qualitative risk assessment. It might be assessing the overall risk profile for a project or trying to define the impact, probability, likelihood of detection or severity of a specific risk event. In the absence of a significant volume of historical data to draw upon, these assessments are subject to individual bias and differences of opinion.
  • A sudden, urgent decision. While clearly defined decision-making criteria or quantitative methods such as expected monetary value or decision trees can help to reduce subjectivity, there are still likely to be some decisions which have to be made by the team on-the-fly. Open voting can be one way to make these decisions, but what will you do if you have a split or close-to-split vote?
  • Effort, cost or duration estimation where there is little historical data and sufficient uncertainty to skew opinions.

So how does one go about using Delphi?

The initial round of input can be gathered in advance of the meeting by sending the question via e-mail and requesting subject matter experts to reply providing their response & rationale via e-mail to the project manager only. The project manager will then consolidate the responses (without including people’s names) and bring that to a meeting where the responses will be shared with the group. Then, the project manager can ask the team to re-vote using some type of ballot box approach. This process can continue till a consensus is reached.

An alternative approach is to use a variant on planning poker. If the scenario is qualitative risk assessment, the project manager could give everyone three cards with the words Low, Medium, and High written on them. As each risk is presented, team members are asked to hold up the card which best represents their assessment of one of the risk event’s dimensions. Until a consensus is reached, the project manager can call on individuals who voted low as well as those who voted high to state why they did so, and a fresh round of voting can be held. This misses out on the anonymous benefits of true Delphi, but can still help overcome the impacts of individual team members monopolizing a conversation.

While it might require some preparation in advance, when working with remote or virtual teams a project manager can still apply Delphi by using anonymous polling capabilities which are often available in online conferencing services.
So the next time your team is faced with coming to a consensus, consider taking them on a detour to Delphi!

Don’t forget to leave your comments below.

A Project Manager Should Always Keep an Eye on Benefits Realization

Managing to the triple constraint is table stakes – it’s time for project managers to go further.

The natural concern which might be raised is that in many cases a project manager has moved on to their next project while the product owner and other stakeholders are still working on the change sustainment required to achieve benefits. The project manager might have had limited direct involvement with the staff who are required to successfully adopt the changes, or might have no influence over the external factors which could impact benefits realization.

This is all true, and yet, if the project fails to deliver the benefits promised, the project manager is likely to receive some of the blame.

This is not to say that project managers don’t attempt to lay the groundwork for success after they have closed out their projects. Sometimes, the fault might lie with protective product owners who may perceive such efforts by the project manager as crossing jurisdictional boundaries. However, this is no reason for a project manager to back off. If they have sufficient evidence to show that benefits realization will be impacted, it is their responsibility to ensure that this information is acted upon.

During the project’s initiation, the project manager should take the time to understand the business case supporting the sponsor’s rationale for investing in the project. This is one of the benefits of a project manager having domain expertise. A project manager who has only a cursory understanding of the impacted business processes may be less likely to understand if some fundamental assumptions are invalid or might miss threats which would impact successful benefits realization.
While a business analyst is usually responsible for requirements elicitation and should be ensuring that the requirements gathered directly tie back to the original business case and expected benefits, the project manager should also take the time to thoroughly review the requirements baseline as that acts as a key input into many downstream decisions which may impact project success. By doing this the project manager is better equipped to support the business analyst in facilitating appropriate decision- making when scope changes are brought forward later in the project’s life.

For projects which are expected to deliver financial benefits, the project manager should not only focus on the definition of the project’s one-time costs, but should also review the incremental ongoing costs and expected revenue projections estimated by the product owner and other stakeholders. If the assumptions underlying those estimates don’t appear to be valid or if the project manager believes that a key constraint might have been missed, they should not hold back on sharing their concerns.

Once work has begun on delivering the project’s approved scope, most project managers tend to focus their efforts on keeping project delivery on track and effective managing changes to baselines. To complement the normal project delivery assurance activities, the project manager should consider taking the time to revisit the business case periodically to identify changes which may impact benefits realization.

The project manager can help to facilitate benefits reviews with the product owner by identifying and engaging the right stakeholders who can provide input into the assessment process. If the project manager and product owner determine that there has been a significant reduction in anticipated benefits, this should trigger a review with the appropriate governance body to decide whether the project should continue to be funded to avoid incurring further sunk costs.

Scope changes provide another opportunity for project managers to go beyond their traditional project delivery role. While understanding the impacts to scope, schedule, cost, and secondary project constraints are important, impacts to benefits realization should also be identified to avoid unintended consequences.

Successful change adoption and sustainment is another critical input into benefits realization. The best project deliverables will generate minimal value if operational staff don’t modify their behaviors to take full advantage of the changes.

Through regular stakeholder interaction, the project manager is in an ideal position to receive feedback from groups impacted by the change.

The project manager can support change owners in stakeholder analysis and action planning and can ensure that priority is placed on securing the necessary change agents from each impacted area. They can review change plans and help to facilitate the risk identification and assessment sessions required to understand what threats may exist to successful adoption.

I am not discounting the effort and challenges required to bring in a project within approved scope, cost and schedule baselines, but that just isn’t enough these days. Like it or not, you will likely be assessed not just on project delivery, but also on whether your projects have achieved their expected benefits.

Don’t forget to leave your comments below.

Increase Team Engagement Through Work Practice Definition

While you might not realize it, you could be exhibiting the symptoms of a project manager who follows McGregor’s Theory X management philosophy from the very start of your projects!

Before you protest too loudly, think back to your last project. If you had to quantify what percentage of project rules of engagement you actively engaged team members in defining, would it be above or below the 50% threshold?

You might argue that as a project manager you are expected to be the subject matter expert on project management practices. After all, a senior software designer is hardly expected to come to you to ask how to design a particular algorithm.

You might feel that your team members would prefer to jump right into their assigned work to reduce the risk of deadlines being missed and should not have to worry about how progress reporting, issue management or team recognition will be performed.

Unfortunately, these are both Theory X views.

A basic tenet of agile project management is that the team should define their work practices and this applies equally well to traditional projects.

I’m not referring to financial or project management policy – that is required to be adhered to. But if your organization’s project management standards focus on what is expected to be done as opposed to prescribing how, have you found yourself defining the standard for your team in many cases instead of actively engaging them in developing those practices?

None of us will want to manage a project in which everyone works however they wish. Self-determination is not an excuse for anarchy! What I’m advocating is the importance of guiding your team through a decision-making process to come up with a common set of practices, then empowering your team members to hold themselves and the rest of the team (including yourself) accountable for following these practices.

Have no illusions – this is not likely to be easy for your team members or for yourself!

For some of your team members, this could be the very first time that anyone has ever asked for their input into such practices and they may lack the confidence to participate fully. For others, they might not understand why you are asking them to participate and might take it the wrong way – “Why are you asking us to do YOUR job?”. Worse yet, others might have had the unfortunate experience of working with project managers who had claimed to support self-management, but then demonstrated through their actions that they really preferred things to be done their way.

Faced with such challenges, a very natural temptation might be to follow the path of least resistance and establish rules. The better approach is to seek to understand – start with asking why and keep probing till you believe you have identified the root cause. Coaching them through their concerns might benefit from the use of analogies or storytelling to help team members understand the importance of self-determination.

For some, a sports analogy might help. For example, a good golf coach doesn’t try to have all of their students execute the golf swing in exactly the same fashion, but rather adapts their teaching methods to the specific strengths and weaknesses of each student.

For those team members for whom all of this is new, provide basic structure by identifying the specific practices which the team will be working on and how the definition process will take place. Once they understand the scope of the exercise and have the opportunity to work with their new team members on defining one or two practices, they will likely be eager to complete the process. Given that most practices have only a finite number of permutations, you could also help to guide the definition process by providing examples for each and letting the team choose which they wish to use.

So when’s the right time to hold such a practice definition exercise? Team working practices should be formed as early in the lifetime of the project as possible to avoid the natural temptation just to impose what you have used in the past. You might want to consider spending a few hours on this during a kickoff session or as a follow-up workshop to a briefer kickoff meeting.

While you won’t be able to entirely avoid the storming phase of Tuckman’s ladder, spending time on norming-type activities very early in the team’s development won’t be wasted effort.

It’s also important to understand that practices will evolve over the lifetime of the project. Whether you run a formal retrospective or not, it’s a good idea to discuss work practices on a periodic basis with the team and have them assess what’s working well and what needs to be tweaked. When new members join the team, it is also a good idea to have them review the current set of practices and provide their thoughts on which might benefit from some fine tuning.

Letting your team members define how work should be done is the first step to unleashing their creativity. Time to ditch the old proverb “A bad workman always blames his tools.”

Don’t forget to leave your comments below.