Project Management

Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Let's flatten five agile fallacies!

Planning for those project disasters that no one wants to think about

What's the link between emotional intelligence and psychological safety?

How do you build your brand as a project manager?

Vigilance is vital to avoid velocity vices!

Let's flatten five agile fallacies!

Categories: Agile, Project Management

In 2015 I wrote an article intending to debunk some common myths about project management. Like many of you, I spent a reasonable amount of time during my first few years participating in online forums correcting agile misconceptions. Unfortunately, just like lopping heads off the Hydra, every time I'd address one myth, a short time later it would re-emerge. Recognizing the futility of trying to permanently suppress fallacies, I stopped responding to such discussions. However, as I would still like to help, writing an article on five of the most common agile myths will give me a reference to provide to folks in the future.

Agile projects and agile methodologies

There's no such thing. You can have projects which get delivered by teams using an adaptive life cycle or in which the team elects to use certain agile tools and techniques but unless the project itself is suddenly going to become sentient, it can't be agile. Agile is not a method (which is what most folks mean when they use the word "methodology"). A team or a company can create a delivery method based on agile values, principles and practices but that is just a single instance of an infinite variety of ways of delivering projects.

We need to do agile

Agile is an adjective, not a noun. Becoming (more) agile should also never be the goal of a team or organization but rather a means to achieving one or more goals. Make it a goal unto itself and the downstream impacts might result in worse outcomes than your current state.

Agile started with the Manifesto

The Manifesto for Agile Software Development is a curation of specific software delivery values and principles. None of these values and principles were revolutionary or novel in 2001 as they had all been identified before in one body of knowledge or another. Concepts, tools and techniques associated with agile have been used for decades and many popular delivery frameworks such as Scrum and XP were published before the Manifesto was written.

To be agile, you must be/have/do "X"

Whether it is sprints, story points, user stories, product owners, servant leadership or any one of a myriad of other roles, tools, techniques and buzz words, the agile community has become really efficient at dividing and conquering itself. Being agile needs to be assessed by outcomes and not merely by how those outcomes were achieved otherwise you risk sliding down the slippery slope to cargo cult.

Agile delivery is better (or worse) than waterfall

Context counts. There is a wide range of possible life cycle choices from fully adaptive to full predictive and very few projects fit cleanly at one end or another of the spectrum. Profiling a project to learn where it falls along this continuum is a critical step for teams to take when tailoring their approach to find better ways of delivering that specific project.

Any others I've missed? Feel free to respond in the comments and I'll add them to the list!

Posted on: September 13, 2020 07:00 AM | Permalink | Comments (12)

Planning for those project disasters that no one wants to think about

Harvard Business Review published an article this week about how boards can prepare for unexpected calamities such as pandemics, natural disasters or cyber-attacks. The authors provided a three-pronged approach for dealing with both true black swan events as well as the more common black elephants (a low probability significant threat which leaders are aware of but don't wish to address proactively). While the strategies provided apply to board members who are looking after the health of their companies, after reading the article I felt they could be adapted to apply to projects as well.

Boards play a key governance role in the successful running of companies. Steering committees play a similar role when it comes to projects. A common mandate for a steering committee is to help guide projects in the right direction by providing ongoing support to the sponsor and project manager. Some steering committees merely play an advisory function whereas others might be more directive. If the sponsor or key risk owners are ignoring looming threats, the steering committee could push them to do more and can encourage these stakeholders to take a more proactive stance. Steering committees can ask these stakeholders the tough questions which project managers or team members might be afraid to ask. To do this, committees need to be staffed with a diverse group of leaders.

Boards are often actively involved in the succession planning process for leadership positions, helping to cue up the best candidates for key leadership roles. Executive teams can play a similar role with projects by identifying who possesses the right risk appetite to be the best sponsor for a project. They can also plan for the future by creating leadership development programs incorporating effective risk management lessons. And, capacity permitting, they can act as mentors for senior stakeholders on critical projects, helping those leaders to plan for the threats they'd rather not think about.

The article also recommends that boards can design or adjust leadership compensation programs to compensate leaders for taking steps which will protect the company from unplanned disruptions. These programs can also be tuned to penalize leaders who prioritize personal short term gains over long term organizational resilience. The same ideas can be used when defining performance plans for sponsors and other key senior project stakeholders. Incorporating project success within the performance plans for these leaders is a good start, but ensuring that the measures also assess how the leaders are going about ensuring success and what they are actively doing to protect against threats is equally important.

The authors close the article by reminding us that building up organizational resilience is a long game. If senior leaders fail to plan for black swans and elephants they will plan to fail when those are realized.

Posted on: September 06, 2020 07:00 AM | Permalink | Comments (5)

What's the link between emotional intelligence and psychological safety?

Following a presentation I gave this week on how project managers can cultivate psychological safety within their teams, an attendee asked me to what the relationship is between psychological safety and emotional intelligence (EI). After answering her I felt it was worth writing about it.

EI is normally considered to be a personal trait although it is possible to claim that one group of people has a higher degree of EI than another. Psychological safety is usually defined in the context of a team as it wouldn't make sense to assess the level of psychological safety of an individual unless they are suffering from multiple split personalities! It would be difficult to assess psychological safety for an overall organization as companies are normally composed of multiple overlapping teams. However, it is possible to assess if the executive team is committed to building a team culture of high psychological safety within the divisions which they lead.

One model for EI uses the following four attributes: self-management, self-awareness, social awareness & relationship management.

How do these traits help a team to become psychologically safe?

Team members who are effective at self-managing and are self-aware will be better equipped to handle actions, comments or behaviors from their team members which they take exception to. They know what their own strengths are but they also understand their weaknesses which means that they are more likely to say when they don't know something, are making an assumption or need assistance from someone else on the team. They have self-confidence which means they are comfortable with experimenting and not feeling that a failed experiment reflects poorly on their abilities.

Social awareness and relationship management relate to how much empathy we demonstrate towards others and to our ability to work well in a team as both a contributor and a leader. Having higher levels of these characteristics means that individuals will be better at picking up on the discomfort of their peers and can help those who are silent to find a voice. It also means that they will be more effective at resolving conflicts which could mean interceding on behalf of a team member if they are being persecuted.

So it seems like a reasonable assumption that on those teams where the members exhibit higher levels of emotional intelligence they are likely to become psychologically safe quicker than others.

But is there an inverse relationship as well?

It is difficult to effectively improve one's emotional intelligence without receiving coaching and support from those whose feedback we trust. In psychologically safe teams, team members feel safer providing feedback with radical candor to their peers. As such, I'd assert that psychological safety can act as an accelerator for increasing the overall emotional intelligence of the members of a team.

A rising tide lifts all boats!

Posted on: August 30, 2020 07:00 AM | Permalink | Comments (12)

How do you build your brand as a project manager?

The restrictions resulting from the COVID-19 pandemic have resulted in more project managers working remotely. While this keeps everyone safe, it also means that there is a larger supply of project managers available to lead a given project since location is less critical. So long as a project manager is temporally close to key stakeholders, in many situations they should be able to get the job done.

While this provides greater opportunity to gain experience outside your locale it also means you are facing much more competition for these roles. Your experience, education and "who you know" can certainly help to differentiate you relative to other candidates, but building a solid brand is equally important.

One of the definitions which Merriam-Webster provides is apropos to our purposes: "A public image, reputation, or identity conceived of as something to be marketed or promoted".

The first thing is to decide what you want your project manager brand to be. Perhaps it is a "Steady Eddie" who can be relied upon to get the job done or maybe you want to be the "Red Adair" of the profession who can always be counted on to extinguish the flames of a project which is on fire.

But once you have decide what your brand is, how do you go about proving that you live up to it?

A simple answer is to deliver expected project outcomes, but that's table stakes. If you don't have a track record for that, you may be in the wrong profession or, at the very least, working for the wrong company.

If successful delivery is the foundation of your brand, you still need some solid walls. These include:

  • How good are you at leading a team? If you are getting the job done but it's at the expense of your team members' growth, engagement or job satisfaction, no one will want to work with you.
  • How good are you at building bridges? When dealing with stakeholders with diverging interests, how successful have you been at creating alignment towards a common goal?
  • How good are you at making tough decisions? Have you made a key decision on a complex project which resulted in its success? Have you been the voice of reason to convince senior leaders to reduce scope or to even cancel a project which you were leading when that was the right thing to do?
  • How good are you at connecting the dots? We don't deliver projects in isolation. Our projects are all part of a larger complex adaptive system. Can you think of instances where your ability to connect the dots and to effectively communicate those relationships to key stakeholders has led to project success?

But these just relate to the projects you've managed.

What do you do to give back to others? Perhaps you mentor some practitioners who are new to project management. Or maybe you volunteer your time and skills to lead initiatives for not-for-profit organizations. Maybe you are a thought leader and have helped to evolve the profession through research or work developing standards or practice guides.

Your brand as a project manager is built across multiple dimensions. Neglecting those might result in you receiving a different type of brand as per Merriam-Webster: "A mark of disgrace"!

Posted on: August 23, 2020 07:00 AM | Permalink | Comments (6)

Vigilance is vital to avoid velocity vices!

After daily coordination events (a.k.a. Scrums, standups or huddles), velocity might be the most misused tool by teams new to agile and the stakeholders supporting them. Used appropriately, it can help a team to understand how much work they can complete in a fixed amount of time and thus could be used to forecast when they might be done with a release. However, being able to do so requires that three critical prerequisites are met. If any of these are not, velocity is irrelevant.

The first requirement is that the team composition and capacity should be relatively stable. You might argue that if capacity has decreased, one could pro-rate velocity based on the decrease. This assumes that we have enough capability (skills and experience-wise) across the remaining team members to complete work items, albeit at a slower pace. In the real world, teams often rely on specialists and if any of those are missing, it might not be possible to complete certain work items.

The second prerequisite is that the team needs to be working on the same product. Change those and there is no guarantee that they can continue to complete work at the same pace unless the two products are very similar.

Finally, the relative uncertainty of upcoming work items should be less than or equal to that of recent previously completed work items. If complexity or uncertainty increases over time, velocity cannot be relied upon.

So assuming these three conditions are met, can we breathe a sigh of relief and freely use velocity?

Unfortunately there are still three ways in which velocity data can be abused by stakeholders.

  1. Comparing velocity between teams. Regardless of whether you use story points, number of work items completed or some other method to calculate it, it is meaningless outside the context of a specific team working on a specific product. Using velocity as a performance measurement could encourage the wrong kind of behaviors such as neglecting quality, working an unsustainable pace or ignoring tangible business value delivered.
  2. Calculating velocity at an individual team member level. Teams complete releases, individuals don't. Measuring velocity at the team member level provides no real value and will just create destructive competitive behaviors within a team.
  3. Assuming that velocity will continue to increase indefinitely. It is reasonable to expect that velocity will increase temporarily as a team evolves their way of working. However, it is unrealistic to expect that they can continue to speed up their pace of completing work unless there is either a significant change in the product, their delivery process or the team composition. Any such change would represent a different context which means that you couldn't compare present to past velocity.

Just as with any tool, there is usually one right way and many wrong ways to use velocity.

Posted on: August 16, 2020 07:00 AM | Permalink | Comments (4)

"Four be the things I am wiser to know: Idleness, sorrow, a friend, and a foe."

- Dorothy Parker