Project Management

Easy in theory, difficult in practice

by
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

RSS

Recent Posts

Handling complexity requires psychological safety

How do you handle unresponsive key project stakeholders?

Thriving at the Edge of Chaos - a review

The perils of myopic metrics and insular improvements

What would I want to receive from my team members this holiday season?

Handling complexity requires psychological safety

I wrote two weeks back about Complex Adaptive Systems (CAS) and the benefit of models such as Cynefin and the Theory of Constraints for being able to understand them. What I didn't focus on in that article was how important the people element is when dealing with CAS. Two HBR articles published this week reminded me of that critical ingredient.

Amy C. Edmondson, who has literally written the book on psychological safety (The Fearless Organization), wrote about the culture at Boeing which enabled the 737 Max issues to fester for a long time before they tragically became mainstream news. In her article, Amy lists three contributing factors including:

  • A visible obsession with speed to market or cost control discouraging staff from speaking up about potential quality or safety concerns
  • Subject matter experts (SMEs) who remain silent during key meetings rather than raising concerns
  • A culture of "yes-men/women"

In the same week, Ryan Gottfredson and Chris Reina, wrote about the importance of leaders having the right mindset. Going beyond the well known Growth vs. Fixed mindset model, they covered three other mindset pairs:

  • Learning vs. Performance
  • Deliberative vs. Implemental
  • Promotion vs. Prevention

Out of these three, the middle one is apropos. According to Ryan and Chris: "Leaders with a deliberative mindset have a heightened receptiveness to all kinds of information as a way to ensure that they think and act as optimally as possible... Comparing the two, leaders with deliberative mindsets tend to make better decisions because they are more impartial, more accurate, and less biased in their processing and decision making."

This aligns well with two of the leadership actions which Amy recommends in her article. Leaders need to insist on input by explicitly soliciting feedback and by responding productively to concerns raised by staff.

So what does this have to do with CAS?

Most of you would probably agree that a modern jetliner is complex system given the large number of interdependent software and hardware components which all need to work effectively together under a wide range of physical operating conditions. While it is possible to build solutions in which complexity won't increase non-linearly as the size increases, this requires significant, sustained commitment to good architectural principles with an appropriate balance between quality and other delivery constraints.

When faced with a CAS, psychological safety within a delivery team is more important than with simple or complicated systems as there is a higher likelihood of things not going as expected which drives a greater need for legitimate transparency and candor.

Posted on: January 19, 2020 07:00 AM | Permalink | Comments (7)

How do you handle unresponsive key project stakeholders?

It is a common challenge for anyone who has managed projects for a meaningful amount of time. One or more of your key stakeholders who are integral to the successful completion of the project appears unwilling to engage as expected. It could be the project sponsor who ignores your pleas for assistance with a project issue, the functional manager who turns a blind eye to your requests for staffing support or the executive who never seems to have the time to review and sign off on a key deliverable.

How should we handle this situation? As usual, "It depends!" is the correct, yet, most unhelpful answer!

While the response varies depending on the scenario, we need to understand the root cause for the behavior and then assess the range of options available to us within the specific context we are facing.

Four causes for unresponsiveness are:

  1. The stakeholder has insufficient capacity to do what we are asking of them
  2. The stakeholder doesn't appreciate the importance or urgency of the request
  3. The stakeholder has a hidden or visible agenda which is counter to the request
  4. The stakeholder is being influenced or compelled by something else within the system in which they are working to not meet our needs

If the stakeholder isn't being responsive to an urgent request they are rarely going to tell you the real reason why. You will have to do some digging to determine the truth. It is fairly easy for someone to say they are too busy or they don't see why your request is important when their real reason is they actually don't want your project to succeed. Or, they might take the easy route and pass the buck ("I don't have the authority") when it could be one of the other reasons.

Even still, once you've identified the root cause, it may not be easy or even possible to implement an effective countermeasure. For example, if you are delayed on the sign off from a key stakeholder, there is no way to proceed without that key stakeholder's approval and they are unable or unwilling to appoint a proxy, your project will be delayed. You might have done a great job of informing all other stakeholders in a timely manner about the cause and impact of the issue, but if schedule performance is one of your project's success criteria, it won't be met.

This is why the scope of risk management is so critical. Identifying critical dependencies, failure points in decision processes and stakeholder unresponsiveness issues from past projects can help us to be better prepared. It can also be helpful to identify common decisions over the life of a project and define the decision processes and exception paths up front before we find ourselves in trouble.

You can't control other people. But you can proactively plan your reactions to them.

Posted on: January 12, 2020 07:00 AM | Permalink | Comments (15)

Thriving at the Edge of Chaos - a review

Over the past couple of years I have regularly heard companies, their portfolios and even individual projects referred to as Complex Adaptive Systems (CAS). With a CAS, understanding of the individual components does not convey an understanding of the whole, and reductionist thinking which can work so well with simple or even complicated systems is of limited use.

Given this, I felt it was somewhat timely when I was invited to review Jonathan Sapir's new book, Thriving at the Edge of Chaos - Managing Projects as Complex Adaptive Systems.

In the first half of the book, Jonathan does a good job of covering the challenges we face when trying to apply traditional planning approaches to complex projects. His differentiation between complicated and complex contexts, the importance of systems thinking and his walk through of the Cynefin framework make these sections a good primer on the subject.

Whether it is Ian Malcolm's quote about non-linearity from Jurassic Park, the old joke about the drunk looking for his keys around a lamp post, or the analogy of a fence and treats for a dog as examples of boundaries and attractors, Jonathan provides many quotes, analogies and examples which all help to make a complex (no pun intended) topic approachable for most readers.

A number of the principles he covers in the first half of the book will resonate with both agilists and anti-fragilists including:

  • Self-organization
  • Simple rules
  • Encouraging emergence of solutions
  • Preserving optionality
  • Distributed control
  • Rapid feedback

I liked his guidance that operating at the edge of chaos is where modern organizations should strive to be as excessive control leads to paralysis and eventual obsolescence whereas a lack of any guardrails will often result in chaos. Uber is frequently referenced in the book as almost a "poster child" for living on the edge, but I found the inclusion of Cemex and how they overcame the challenges they were facing in a traditional industry more appealing to me given that the majority of organizations are not founded to disrupt an existing business model.

The second half of the book covers Dr. Eli Goldratt's Theory of Constraints (ToC) and focuses heavily on its application in Critical Chain Project Management (CCPM).

While CCPM provides good solutions for dealing with common scheduling issues, I did feel that the book could have delved deeper in terms of applying ToC and other models to addressing some of the non-scheduling concerns caused by CAS. There could have also been some guidance provided for leaders who face the challenge where there are multiple resources who are all equally constrained. ToC works well when there is a single bottleneck but with multiple equivalent bottlenecks what should we do?

The following qualifier from the Introduction also raised some concerns: "This book applies primarily to repetitive, as opposed to one-off, never-to-be-done-again projects. It does not apply to software development projects that use agile methodology." I would argue that some of the most complex projects we have to deliver are highly unique. Also, while many of the ideas shared by Jonathan are already incorporated in agile methods, these approaches haven't fully solved CAS challenges and the book could have addressed those.

If we accept that complexity is going to continue to increase in delivery, Jonathan's book provides a solid grounding on the subject and I hope that a future revision will address some of the opportunities I've raised.

Posted on: January 05, 2020 06:59 AM | Permalink | Comments (13)

The perils of myopic metrics and insular improvements

Categories: Agile, Project Management

This Dilbert cartoon from December 23, 2019 illustrates a couple of anti-patterns which I've sometimes witnessed in companies who are going through an agile transformation.

While it is often true that 80% today is better than 100% tomorrow when we consider benefits such as being first to market, an increased return on investment or accelerating validated learning, that rule of thumb refers to the depth and breadth of product features and not to basic needs.

Successful agility implies improving across three dimensions - speed to value realization, product quality and stakeholder satisfaction. Shipping a product prematurely may (temporarily) address the first dimension, but not the other two, and any financial benefits achieved by rushing delivery would be negated by increased costs of poor quality. To add insult to injury, forcing professionals to do shoddy work to meet an artificial deadline will most likely demotivate them.

What might have caused this?

Perhaps the Pointy Haired Boss (by the way, I realize that Scott Adams wanted readers to be able to easily compare him to managers within their own companies, but I think naming him is well past due) has an isolated, near term performance objective such as achieving a specific product delivery date rather than looking at customer satisfaction or the volume of customer complaints.

But there might be more at play here.

A second anti-pattern might be localized optimization causing systemic sub-optimization. If the product build team had improved their ability to deliver without the user documentation team having been brought along for the ride, the overall product enhancement value stream won't have been improved.

Product enhancement value streams are Complex Adaptive Systems (CAS).

Improving a component of a CAS without understanding the upstream and downstream implications might generate more problems than the benefits achieved. When dealing with a CAS, a holistic, system-level approach is needed to understand and address root causes if the goal is faster delivery.

This extrapolates the mindset of agile beyond the team level to addressing the needs of an overall CAS. Just as we wouldn't want individual team members making improvement decisions which benefit them but hurt the team as a whole, we wouldn't want individual teams optimizing their work processes at the detriment of other players in the CAS.

This is why the seventh principle of Disciplined Agile is so important - Enterprise Awareness is a critical ingredient for successfully scaling agile.

 

Posted on: December 29, 2019 06:59 AM | Permalink | Comments (7)

What would I want to receive from my team members this holiday season?

With under a week till Christmas 2019, Mike Cohn wrote a good article about what wishes team members might want to have granted this holiday season from their Agile Leads, Product Owners and People Managers.

But even if each of these roles were to grant all the wishes which Mike listed, there is one more role which needs to be considered, namely their fellow team members.

Give me a hand

One of the differences between a group of individuals and a real team is that with the latter we will see team members helping each other out without an explicit request for assistance being made. While it is desirable for team members to ask for assistance during events such as a daily standup, many times the need for help might emerge suddenly and if someone else on the team sees that their teammate is struggling they can provide assistance in a timely manner.

This behavior is often seen in professional sport teams. When an ice hockey goaltender is caught far out of their net while clearing the puck, one of their other team members who has much less protective equipment might put themselves in the line of shots until the goalie is able to get back in the crease. You'll almost never hear the goalie verbally request this assistance, but the teammate sees the need and helps out regardless.

Help me improve

While there are always a few people who don't like hearing the truth, most of us prefer to find out when we could have done something better.

Retrospectives are one forum in which teams can share what's working well or poorly, but these events might not be the best setting for providing one-to-one feedback as they are a group ceremony and the feedback will usually have been delayed by a few days.

I've written previously about the importance of radical candor - most team members would want their peers to provide constructive feedback directly while still demonstrating that they care about them. This is especially critical when the behavior violates the working agreements defined by the team. If the offending team member does not receive direct and caring feedback, their behavior is likely to recur and they could find themselves isolated and ostracized by the rest of the team without knowing what they did to deserve this.

One way to turn these wishes into a self-fulfilling prophecy is to model the behaviors which we would like to see from our team members. When you perceive that a team mate needs help, ask if they would like it before they ask you for it. When you see them doing something wrong, ask for permission to provide them with feedback.

Let's be the change we wish to see within our teams!

 

 

Posted on: December 22, 2019 06:59 AM | Permalink | Comments (14)
ADVERTISEMENTS

"The man who does not read books has no advantage over the man that can not read them."

- Mark Twain

ADVERTISEMENT

Sponsors