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

Go slow (to go fast later)

Should we hire full-time or contract agile coaches?

The only thing we have to fear on projects is...

Transparency improves customer satisfaction

Handling complexity requires psychological safety

Go slow (to go fast later)

Categories: Agile, Project Management

The January 2020 issue of PM Network provide a case study for one of the 2019 PMI Project of the Year finalists, the Société de transport de Montréal's (STM) eight-year project to modernize the underground Montréal rail system. I have a soft spot in my heart for this system, having spent most of my formative years in Montréal and having been a frequent user of its services while commuting to university and my first job. I always found it to be a clean, safe, efficient and reliable method of getting around the city. As such, it was a bit of a surprise for me to read about the operating challenges faced by the STM in recent years and the anticipated growth projections, both of which were the impetus for this ambitious project.

While this would be considered a small mega-project (CA$2.1 billion), it is still a testament to the team that they delivered it under budget and on schedule utilizing only one percent of their overall contingency budget. The post-project outcomes are also in line with expected benefits.

What impressed me about the case study was the number of practices which were used by the team which we would normally associate with projects following an agile or adaptive life cycle. This includes close collaboration and short feedback loops with customers, building a "whole" team representing all disciplines, performing operator training in parallel with build activities to streamline transition, and encouraging learning from failures rather than hunting for scapegoats.

However, what really resonated with me was the team's commitment to shifting quality left.

During the preliminary qualification phase for the new trains, problems were identified during integrated testing which hadn't been identified in the manufacturer's unit testing of the individual components. Rather than blaming the contractors, STM owned the issue and worked closely with them to fully resolve the issues. While this caused a two year delay to the qualification phase, over the remaining life of the project it resulted in minimal change requests and contributed to acceptance of the trains upon final delivery with no costly late stage rework required.

Complex projects often experience design or other solution-related issues early in their life. While no one likes reporting negative schedule variance, especially at an early stage, if these issues do not get properly resolved, or worse, are ignored to protect schedule performance (and to save executive embarrassment), the cost and schedule impacts will often be much worse later on.

Courage is one of the values of the Scrum framework, but it applies to all delivery approaches. As project managers, we need to have the courage to convince our executives that it is better to slow down now so that we will be able to speed up later.

A stitch in time saves nine!

Posted on: February 16, 2020 07:00 AM | Permalink | Comments (9)

Should we hire full-time or contract agile coaches?

Categories: Agile, Change Management

In 2013 I wrote an article about the advantages and disadvantages of contract project managers.

Competent agile coaches have been in high demand for many years due to the large number of companies across multiple industries who are going through agile transformations.

Scrum asserts that the role of the Scrum Master includes coaching activities and this is fair in small contexts, but in larger organizations early in their journeys to greater agility, a Scrum Master is likely to find they have limited capacity to effectively coach stakeholders beyond members of the development team and Product Owner.

In such situations, a delivery team might try hard to be more agile, but functional managers, executives and other internal and external stakeholders might not be supportive of this transition. Applying Theory of Constraints principles to this situation, a coach would want to identify the primary bottleneck and focus their efforts there.

But should you hire them full-time or on contract?

While all the considerations from my earlier article apply to the role of an agile coach, here are a few more which should be considered before making any decisions.

  • Full-time staff tend to go native. Putting aside those truly Quixotic people who tilt at windmills regardless of how long they have been told by others that this is a futile pursuit, for most, after spending sufficient time within an organization, they find it harder over time to continue to challenge the status quo. Complacency is cancer to coaches, and a fixed duration contract reduces the probability of this evil.
  • Contract coaches can be very pricey. Even for companies with deep pockets, the cost of a role which doesn't directly contribute to value delivery can be hard to swallow. While some companies will establish separate funding at an enterprise level for covering coaching costs, those that don't will need to find some way to justify those costs at the department, value stream or project level. This might encourage these companies to overwhelm the coaches with multiple delivery teams which will keep them busy but won't necessarily achieve desired outcomes. It will also discourage use of the coaches for "non-billable" activities which are often more strategic than their contribution to any one project.
  • Having full-time coaches might prolong the journey to sustainable agility. Coaching as a service is valuable on an ongoing basis, but focusing this on a single role might result in teams using that role as a crutch rather than being truly able to "fish for themselves". A greater sense of urgency emerges when we know that our coach has an expiry date.
  • You may not be able to afford good full-time coaches. A good agile coach is worth their weight in gold. Unfortunately, most companies don't have the Midas touch and the fully loaded costs of a team of competent agile coaches might be more than they can afford. This is especially true in the first few quarters of a transformation where the benefits of increased agility are still insufficient to cover their costs.

While an agile coach is not mandatory, the support a good coach provides can accelerate the journey through an agile transformation. The best choice for many companies might be to staff a combination of full and contract coaches to make the journey as pleasant as possible.

Posted on: February 09, 2020 07:00 AM | Permalink | Comments (9)

Transparency improves customer satisfaction

Categories: Agile

The link between transparency and trust is well known. You are more likely to trust the quality of the food you are served when eating at a restaurant with an open concept kitchen than if the food preparation is done entirely out of sight.

Transparency is a pillar of the Scrum framework and while it is not explicitly spelled out by other frameworks or in the Manifesto for Agile Software Development, it is indirectly referenced. When I teach classes in agile fundamentals, I often say that a virtuous cycle commences when greater transparency builds increased trust in the team by senior stakeholders. This in turn leads to greater support from those stakeholders for team self-organization and empowerment which reinforces the team's willingness to be more transparent.

But will transparency do more than just build trust?

I had a follow-up appointment with a medical specialist this week. It was scheduled for 4 PM and shortly after that time I was escorted to the examination room by a nurse who told me that she'd let the doctor know that I was there. I waited (and waited, and waited). At 5 PM, I got tired of sitting on the examination bed and stood in the doorway looking out. A few nurses saw me, but no one stopped by to ask why I was not waiting patiently in the room. Finally, at 5:15 PM, the doctor came into the room. No apology was offered for her tardiness but she did complain that she has no control over her normal schedule on days when patients needing urgent medical attention show up. 

My demeanor was externally pleasant but internally I was seething.

I have no issues with a delay resulting from a medical triage process. What frustrated me was my complete lack of knowledge of where I was in the queue or any idea as to when I would eventually be examined.

I don't expect that my doctor would have had the time or inclination to stick her head in my room to update me once or twice over the hour and a quarter I was waiting, but the nurse who had brought me there could have set my expectations appropriately. The clinic could have posted a simple information radiator showing the number of consults waiting for each specialist to help manage patient expectations. Better still, they could have implemented a simple online site to make this information available remotely which would have enabled me to show up close to the actual time when I would be examined. 

Increased transparency would have increased customer satisfaction.

I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou

Posted on: January 26, 2020 07:00 AM | Permalink | Comments (10)

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 (8)

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)
ADVERTISEMENTS

"Common sense is the collection of prejudices acquired by age 18."

- Albert Einstein

ADVERTISEMENT

Sponsors