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:
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.
(As is often the case, one of the learners in a course I taught this week provided the inspiration for this article, so thanks Maca!).
The PMBOK® Guide, Sixth Edition defines Earned Value as "The measure of work performed expressed in terms of the budget authorized for that work." Notice that the word "value" does not show up anywhere in that definition.
On projects which are following an agile or adaptive life cycle, the expectation is that work items such as requirements or features will be completed end-to-end. This includes meeting the quality requirements of all key stakeholders so that we can be confident that we can ship the work items to a client. If a framework such as Scrum is followed, these work items are batched into Potentially Shippable Product Increments whereas on those projects which are following a continuous flow based delivery approach, we can hand them over as we go.
On these projects, while final business benefits might not have been realized yet by our customers as those will normally lag delivery by days or even months, we might claim that what we've earned is valuable.
However, when we consider projects which are following a waterfall or predictive life cycle, because of the batch, phased manner of those approaches, the time for the first customer handover of capabilities and the time between subsequent handovers is usually prolonged. As such, until we have delivered a project output which will directly enable our customers to realize business benefits from it, have we actually earned any value?
Writing a Business Requirements Document or creating a design might be necessary by-products of the delivery process but if a project is terminated with just those having been produced, its unlikely that a customer would consider they had received anything of real value.
Please don't misunderstand my point.
I believe that Earned Value Management is a valuable, objective tool for both determining a project's performance and for forecasting where we will end up when it is used appropriately. Appropriate usage includes such elements as using an objective, verifiable method for determining how much progress has been made for each work package and that prerequisites such as work package-level budgeting and financial actuals reporting are easily available.
I'm just questioning why we would use the word "value" when referring to what we have earned in the name. Perhaps, for waterfall projects, we should rename the measure to "Earned Delivery Value".
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.
My article last week discussed the need for team members to act with responsible transparency. Each team member requires discipline and wisdom to judge when an issue preventing them from completing their work items can be resolved quickly without the need for broader communication or escalation.
If a blocker surfaces and no one other than the person who encountered the impediment is aware of it, the delivery of that work item could be critically impacted resulting in a cascading set of delays. The same holds true for the team as a whole. I've occasionally worked with teams whose members are uniformly confident in their ability to resolve any blocker which arises. Such teams can go out of their way to show that they are in control and everything is going well on their delivery work, right up till the moment when it is clear to all that this is not the case.
So assuming that team members are doing a good job of surfacing impediments, how should these be communicated and tracked?
The project manager will likely be accountable for maintaining a project issue log but depending on where that artifact is housed it might not be visible enough to create the right sense of urgency from the stakeholders who can help the team resolve issues. Also, such a log is likely to track higher level issues and not just those affecting individual work items.
If a detailed schedule is being used to plan and track work activities, blockers could be directly linked to the affected activities, and indicator icons or flags can be set to highlight the tasks which are currently blocked. But that still requires stakeholders to regularly review the project schedule.
A better approach is to expose blockers through existing information radiators.
If a work board is used to help the team manage their work flow, blockers can be identified in one of the following three ways:
Blockers can also be tracked separately using a pain snake (sometimes called a "snake on the wall"). Every time a new blocker is identified, a new stickie is added to the snake. The length of the snake will help encourage the team not to allow too many blockers to remain unresolved.
So how bold are your team's blockers?
I finally completed reading Nassim Taleb's book Skin in the Game which I had written about in a recent article.
In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.
In small companies, how a product gets developed and delivered is usually defined by a "Big Brain" (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.
Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.
For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won't themselves have to use the templates and tools which they have developed, they don't have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.
There are a couple of ways to rectify this situation:
Method makers and framework formulators - practice what you preach!