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

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)

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)

I, for one, welcome our new PM AI overlords

A frequently asked question in the main ProjectManagement.com community discussion group is about the perceived impacts of machine learning on project delivery.

Some contributors worry that sufficient advances in AI will render the role of a project manager obsolete whereas others remain bullish about the prospects for the profession.

A recent Harvard Business Review article by Stephen M. Kosslyn titled "Are You Developing Skills That Won’t Be Automated?" would support a positive outlook on this topic. In the article, the author asserts that roles in which emotion and context play a strong influence will still need to be performed by human beings. We have enough challenges with human leaders struggling to inspire team members or effectively align stakeholders to expect that machines will have an easier time doing so.

I'm expecting that enhancements in current machine learning technology will free us from rote administrative activities which even the most senior project manager finds themselves having to perform from time to time. While such advances might reduce a full-time requirement for project administrators on large, complex projects, it might enable such roles to support a larger number of projects at the same time.

What might projec managers do with all of this extra time?

Being assigned to more projects concurrently is not the answer! If we believe that project management is a strategic role then we should be encouraging greater focus, not less.

Freed up capacity could be better utilized on frequently neglected practice areas such as stakeholder engagement, risk management and knowledge creation. Envision the potential benefits to your projects if you had even 10% more time to devote to such practices.

We could also invest more in our own personal development or giving back to the profession or the community.

Is it possible that at some point in the future, AI will have the ability to independently manage a project staffed with humans?

This seems realistic if we agree with Gene Roddenberry's vision of intelligent sentient machines such as Commander Data, but I'm equally optimistic that the next one or two generations of project managers will have little to fear so long as they continue to invest in developing their soft skills.

Posted on: September 29, 2019 07:00 AM | Permalink | Comments (13)

What are some of the underlying causes of ineffective project risk management?

Since I first started to learn about project management, risk management has always fascinated me.

That characteristic of uniqueness which separates operations from project work introduces uncertainties which, in turn, generate risks. Most mega-project case studies give credit to an effective risk management approach as a key contributor towards their success. But in spite of this, risk management continues to be one of the weakest practiced knowledge areas in the PMBOK.

If eternal optimism is the prevailing mindset within a company, it can be difficult for risk owners to envision things not going according to plan. What has always intrigued me is how the same leadership teams which can be moderately effective at implementing operations or business risk capabilities will be so much weaker when it comes to project risk management.  A risk averse culture will take a long time to change for an overall organization, but a project manager should be able to influence it within the ecosystem of their projects.

Unhealthy levels of multitasking by project teams and stakeholders result in those practices perceived as unnecessary being jettisoned or being given lip service only. If a team barely has time to deliver the scope of their project, how can they or equally busy risk owners be expected to expend any real efforts on considering or responding to potentialities which may never be realized? And, if we combine this limited availability with "one size fits all" approaches to project risk management, it is no wonder that many teams will do the absolute bare minimum required to meet onerous governance requirements.

If team members and other stakeholders don't know what effective project risk management looks like, how can they be expected to improve? If there are no coaches to help teams improve their capabilities, improvements in risk management will rarely happen organically. Competent risk management requires exceptional interpersonal skills in addition to some basic technical skills, so hands-on practice with feedback from seasoned practitioners is needed to improve.

Finally, there might not be a realization of the positive correlation between effective risk management and successful project outcomes. In the absence of supporting internal empirical data or strong pressure from the outside to create a valid sense of urgency, senior leaders and project teams will be unwilling to sustainably invest in the required behavior and practice changes.

Providing practitioners with risk management training or evolving project delivery standards might help in some small way, but real improvements will only come when these root causes are addressed.

Posted on: September 15, 2019 10:50 AM | Permalink | Comments (5)

How open are YOU to changing your launch plans?

During the last week PMI announced that, based on the feedback they had received from stakeholders, they would be delaying the significant changes to the Project Management Professional (PMP)® certification exam which had originally planned to be launched in mid-December 2019 to July 1, 2020.

When I first read this, I felt a burst of vicarious relief for those exam candidates who were likely experiencing a lot of stress with the original date.

I have no doubt that this was the right decision for PMI to take.

The proposed changes to the exam are likely to be more significant than others made over the past decade. With the last batch of changes to the exam having been implemented in March 2018, a significant update within two years will not only cause candidates angst but will also reduce the return on investment for the study materials which training companies would have so recently updated.

After further reflection I realized there are some good lessons in change management with this decision:

  • As a not-for-profit association, stakeholder satisfaction may be more crucial to PMI than if they were a for profit entity, but regardless, they have been very proactive at communicating both the rationale and the scope of proposed changes even though these announcements were likely to upset certain the stakeholders. Often, while considering a disruptive change, our temptation might be to avoid communicating anything until there is a full understanding about the impacts but that usually won't give stakeholders sufficient time to react to the information.
  • They were open to hearing negative feedback about the changes. It's easy for leaders to say that they are willing to hear criticism about a change they have championed but much harder to take it when it happens.
  • PMI decision makers were willing to make a change late in the game for the right reasons. I'm used to seeing leaders' appetite for change drop drastically as a proposed implementation date draws near. This makes sense as change deliverables need to be sufficiently stable before a launch date, but if there is evidence that the benefits of sticking to a date will be outweighed by the impacts of a premature launch, leaders should be willing to accept some near term embarrassment in order to realize a more sustainable outcome.

I have no idea who was the decision maker at PMI who pushed for this delay to the launch date, but this demonstrates the sort of good judgment which we should demand from change leaders.

Posted on: September 01, 2019 11:38 AM | Permalink | Comments (9)
ADVERTISEMENTS

"Don't play the saxophone. Let it play you."

- Charlie Parker

ADVERTISEMENT

Sponsors