Previous month:
July 2020

The Perfect Storm for The Project Economy

Perfect StormThe winds of change were strong before the COVID-19 pandemic. Driven by three macroeconomic trends, the need for projects and project managers was increasing. These three trends are:

1) Accelerating rates of technology adoption

2) The switch to alternative energy sources to maintain GDP and meet emissions targets

3) Infrastructure projects for population growth.

These movements occurring together were spawning an explosion of projects to turn ideas into reality. This increase in project demand was christened The Project Economy by PMI in 2019.

To be fair, these trends and strategies for handling them had already existed for more than a decade. Globalization and business transformation have been discussed extensively. Eric Ries documented his lean startup methodology in 2008 as a way for organizations to adapt and experiment with new ideas and perform market tests. It provided a framework for rapid adaptation and customer-centric design that is baked into many of today’s strategies.

 

COVID-19 Hits
Then COVID-19 changed how the world works, learns and communicates. The digital migration became a stampede as organizations were forced to work online or curtail collaborating and communicating. Digital transformation, an already hot market segment that moves traditional products and services online, was suddenly set on fire.

Organizations had to transform and go online or face losing market share to those that could. Online, non-contact shopping and direct business-to-consumer increased dramatically. Previously niche services such as universal home delivery providers became mainstream.

However, more importantly, digital consumerism became normal. No longer were just millennials using third-party services to arrange home delivery from traditional brick-and-mortar providers; now, Gen X and boomers are, too—the flood gates have opened.

 

A Brighter Future
Lockdown provided a glimpse of a clearer, brighter future. With commuting reduced, air quality in cities improved drastically. People in the state of Punjab saw the snow-covered peaks of the Himalayas for the first time in 40 years. Compared to the past five years, March air pollution figures were down 29% in Los Angeles, 38% in Sydney and 46% in Paris. According to Environmental Protection Agency data for March, carbon monoxide emissions were down by 50% in New York.

Now people have seen what it would be like if there is less pollution; the transition to clean energy may accelerate also. It could already be happening. All the major auto manufacturers reported far fewer sales in Q1 and Q2 due to factory shutdowns and a lack of customers. However, the figures show a green skew. General Motors deliveries were down 34%, Toyota down 35% and Fiat Chrysler down 39% while Tesla sales dropped by only 4.8%.

The transition to alternative energies will likely speed up as nations use the COVID recovery as an opportunity to also reset and refocus for the future. Illuminated by a bolt of clarity, projects aimed at transitioning to renewable energy sources are also set to increase.

 

Population Growth and Technology Uptake
While extremely taxing on hospitals and medical practitioners, hopefully COVID-19 will do little to overall population counts. The population growth in Africa is expanding three times faster than other continents. The current population of 1.3 billion is expected to nearly double to 2.5 billion by 2050.

These additional 1.2 billion people work out at over 100,000 extra people each day for the next 30 years that will need homes, food and water. The housing may happen organically, but the infrastructure for transportation, power, water and hospitals all need projects to make them happen. This buildout to accommodate 40 million extra people every year represents a tsunami of infrastructure projects.

An increasing proportion of power for all these homes and facilities may well be solar and wind that, due to innovation, is now 90% cheaper to install than 10 years ago. Access to power and less expensive technology also brings connectivity. While 82% of the developed world has internet access, only half that figure (41%) of people in developing nations have access to the internet.

Expanding connectivity to those currently without internet access would bring an extra 3.2 billion people online. If visionary innovators and exceptional entrepreneurs are one in a million, we get an additional 3,200 of them today just by providing connectivity. As more people get connected and information becomes more freely available, innovation accelerates in a virtuous cycle.

 

The Perfect Storm of Disruption
The term “perfect storm” was coined by author and journalist Sebastian Junger in 1991 to describe the convergence of several weather systems that led to the creation of a hurricane off the coast of Atlantic Canada. It’s now a phrase often used to describe how converging trends—such as tech, population growth and alternative energy—can combine to create a powerful disruptive force.

COVID-19 caused digital transformation to surge. It also highlighted the potential for alternative energy that, as it becomes more popular and cheaper, helps connect an ever-growing population. Then, as more people come online, technical innovation will accelerate, and the forces magnify.

The Project Economy was christened to describe the demand for more projects and, therefore, project managers. Throwing the consequences of COVID-19 into the mix is akin to adding a powerful accelerant to a firestorm.

 

Impacts on Project Management
There will undoubtedly be a huge demand for projects, but technology and market evolution are changing the skill set needed to be successful:

  1. Less of the old —When I studied project management many years ago, I learned how to create work breakdown structures, plot network diagrams, and calculate slack and lag between tasks. With all the planning, estimation, risk management, and earned value tracking, there was a fair amount of math and admin involved.

These days, on the high-change digital projects I work on, applying math to shaky input data is rightly criticized. There are many fields where these techniques still apply, but when validating digital products, customer feedback on early prototypes is more helpful than precedence diagrams. Also, today’s project management tools calculate all of the familiar stats and tracking metrics automatically.

AI tools in project software can help suggest risk categories to evaluate and report emerging trends in data such as small delays before a project manager might have noticed them. The classic science and math-based project management skills are reducing (in digital products, at least) to free up more PM time for stakeholder collaboration and stewardship.

  1. More power skills In describing The Project Economy, PMI President and CEO Sunil Prashara talks about renaming “soft skills” to “power skills” since the term better describes their importance. With tools doing a lot of the calculating work, soft skills become more critical. Also, in a digital market, customers can choose their products from suppliers all over the world, so organizations must take a customer-centric view of building products or risk losing market share.

The new in-demand skills emerging include emotional intelligence, empathy, conflict resolution and consensus-building. While always valuable, they are now critical to retain a more mobile workforce and customer base.

  1. Technology Quotient (TQ) —Being tech-savvy and able to adopt new tools is vital to keep up with new ways to engage team members. An increased amount of remote work is here to stay, and graduates entering the workforce today grew up digital. They have little experience of paper-based communication or documentation. Collaboration and communication for them are primarily digital and phone-based.

Project managers must embrace these developments or risk becoming irrelevant and disconnected from a growing percentage of team contributors. Online tools and remote work just received a five year fast-forward thanks to lockdowns and work from home.

  1. Different LifecyclesDigital products such as websites and services are less “build then sustain” and more “ongoing evolution” in their nature. Handoffs from one team to the next risk too much information loss in the knowledge worker domain.

Digital-first organizations such as Amazon, Google and Tangerine use long-lived product management lifecycles with stable teams and incremental funding to deliver outcomes. These techniques are in contrast to projects with their temporary nature, upfront budgets, and team ramp-up then handover to support staffing models.  

As organizations undergo digital transformations, many are transitioning to product management lifecycles to fit the characteristics of digital products better. Project managers can still play a variety of crucial roles—but need to adapt to building stable teams and using incremental review and funding.

 

Summary
The Project Economy outlined in 2019 was driven from the convergence of tech, energy and infrastructure. COVID-19 forced a digital upskilling and appreciation for alternative energy that has accelerated the transition.

There will be many opportunities for project managers willing and able to adapt to the new roles offered. Likely, our tools will be smarter—and more of our time spent on stakeholder engagement. The lifecycles and titles used may change, but turning ideas into actions and then actions into results will be very much in demand.

 

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]


Estimating Agile Projects...Or Not

Estimate Features or FlowProject managers generally like plans and estimates so we can forecast when things should be done and how much they may cost. It helps manage client expectations and answer the type of questions they ask, such as "When will it be done?" and "How much will it cost?"

So, when project managers hear about ideas such as "let's stop estimating," it can trigger a knee-jerk reaction. It sounds lazy and avoiding the hard work of having to estimate. It can seem like people want to shirk their responsibility and accountability. First, those lazy agilists wanted to stop doing documentation; now they want to stop estimating too!

There has been a debate raging since 2012 about the use and value of estimates on agile projects. It has spawned the #NoEstimates hashtag, a website, a book and countless blog posts and conference presentations.

Like many radical ideas, when we dig into “no estimates” thinking, there are some good ideas, sound logic—and a whole heap of misunderstanding around it. This article sets out to unravel some of it.

My Exposure to NoEstimates
I should start by declaring which side of the debate I am on. Initially, I thought I was firmly on the side of estimates—but not the wasteful kind of detailed estimates that other people make when there is only limited information available. Instead, I aim to create reasonable predictions of the likely effort bounded by the uncertainty of the input data. Then communicate the estimates as a range to reflect the uncertainty and refine them as more information becomes available.

Then I discovered this is closely aligned with what the more reasonable NoEstimates advocates suggest doing anyway. It is just that they call them forecasts, not estimates. I can live with that; names are only labels that matter less than the meaning behind them. So then I felt conflicted.

NoEstimates Gets Started
In 2012, Woody Zuill wrote a blog post asking if getting better at estimating was the only way forward. He wondered if creating forecasts based on observations of completed work rates could be an alternative. The movement started, then more radical people got involved. They triggered more extreme counter-arguments against NoEstimates. However, let's de-escalate and look at some of the ideas that started the discussion. Then people can make up their minds based on their unique environment.

For software projects following an agile approach, the team is often asked to estimate the development effort for stories in the backlog. As the team starts work on these stories, they may discover some are more complex than initially anticipated and need splitting into multiple stories.  Others go as planned, and others get replaced by higher-priority changes and never get developed at all.

Throughput-Based Forecasts as an Alternative to Estimates
The effort and rigor of the estimation approach should be proportional to the quality of the input data. It would not be a good use of funds or people to apply time-consuming Monte Carlo analysis to a collection of guessed durations. So some NoEstimate enthusiasts classify over-analysis and more structure than the input data deserves as a form of waste.

We can argue even the act of estimating with imperfect input data is still valuable and gets the team discussing work that can uncover insights. Also, when spending other people's money, it is the responsible thing to do. However, let's follow the NoEstimates logic before making a judgment.

As an alternative to estimating all the stories for an upcoming iteration, NoEstimates supporters suggest a throughput-based forecasting approach. So, if the team completed 20 user stories last iteration, let's assume they will complete 20 this iteration also—and use the time that would have been spent on estimation work toward building new functionality.

It is easy to spot the flaw in this logic. What happens if these next 20 stories are much bigger or more complex than the 20 just completed? The answer is the team will not get through 20 of them, and the forecast will be wrong. However, before we dismiss this approach as unworkable, let's examine some of the things that can go wrong with traditional estimates on a software project.

We can spend a bunch of time estimating tasks, and they still turn out bigger than we expected or more complicated when we get into them. We can also spend time estimating work that gets deprioritized or swapped out with new work.

"The Same Poor Results, But with Much Less Effort"
Around 2006 at the agile conferences, I recall a presentation by Motorola on the effectiveness of using planning poker estimation compared to its previous, high-rigor approach. Motorola contained some CMMI Level 5 departments that conducted very detailed analysis and structured estimation sessions.

Part of being CMMI Level 5 is continuous improvement. So, in addition to rigorous estimation, teams investigated the root cause of any estimation errors to improve the process for the future. As an experiment, three teams substituted planning poker for their in-house estimation process. An additional three teams continued estimating as usual, producing detailed estimates with reviews, root cause analysis and ever more detailed estimating guidelines afterward.

The results showed that even the teams that followed the detailed in-house process were quite weak at estimation. Some items were overestimated, and many more were underestimated. Root cause analysis served to create ever longer checklists but did little to remove the variability of estimating work with human variation, uncertainty, complexity and risk.

The planning poker teams faired no better; they too were—at best—mediocre at estimating, often missing issues that created delays. The significant difference was that planning poker was much quicker than their existing estimation approach, and the team members enjoyed it much more. I still recall the presenter's summary that comparatively, planning poker provided "The same poor results, but with much less effort." Motorola was sold, and that department switched to planning poker.

Throughput-Based Forecasts
The NoEstimates camp takes this lesson one step further. They assert measuring throughput is as good (or more accurately, just as poor) a way of forecasting as estimating via hours or points—but crucially requires much less effort. When spending other people's money, should we focus on building valuable deliverables or creating estimates that, even with a costly rigorous process, are—at best—mediocre?

Of course, there are shades of grey. Some software is knowable and can be estimated reliably. Perhaps we should use estimation there. Some clients expect due diligence and evidence of planning rigor, and may want to know work is being estimated and not just started without due consideration.

I have worked with both types of forecasting. Each time throughput-based forecasting was used, the team had started forecasting with points. Then as the team became stable and trust was developed with the client, we found throughput metrics were reliable indicators of delivery dates and capacity.

Modern agile project management tools track when stories change state from, say, Ready for Development through Coding, Testing and Done. If this process is averaging five days per story and the product owner asks how long it would take to add some new high-priority feature, then—providing it is not too complex—probably about five days.

Likewise, if it took two months to complete the last 50 stories and there are 100 left in the backlog, then it will probably take four months to complete the project. No developers were interrupted to create those estimates.

Hybrid Options
Where I have used cycle time and throughput analysis to create forecasts, we have also tried to be smart about it. The team knows the process will only work if stories are sized appropriately. So they spend some time looking for anything that may be architecturally significant to investigate early via a spike. They also spend time splitting large stories—and sometimes tag stories with t-shirt sizes such as small, medium and large.

It can be argued that this is a form of estimation, and I would agree. But rapidly attributing small, medium or large to a story is quick and can be done by a senior developer not requiring (or gaining the wisdom) of the whole team.

Now we need to do some basic math with our forecasts. Small, medium and large should be relative, so a medium is two smalls, and a large is three smalls. Now the team can deliver 60 small stories or 30 medium stories or 20 large stories per iteration—or more likely, some combination such as five large, 10 medium and 35 small.

We have freed the team from estimating work (which even the best are not very good at), so it can focus on building products that hopefully it is better at. We can use throughput data that is provided free by our tracking software to forecast completion dates. Using these estimates multiplied by the team burn-rate (plus other costs), we can also generate cost estimates.

Downsides
I have only experienced throughput-driven forecasting working well with stable teams in high-trust environments. These teams had previously estimated their work and were very aware of their burn rate compared to budget and remaining work.

I fear teams not so aware of the need to deliver might work slower than if they had been through that experience first. Some environments and cultures find not estimating irresponsible. Also, some types of development can be estimated quite accurately, and so individual estimates could provide superior forecasts than tracking average throughput.

This article has described throughput-based alternatives to traditional task-based estimates. Some NoEstimates zealots deem that to be waste also, and believe teams should just work until done. However, I have yet to meet a sponsor not interested in evidence-based progress and completion forecasts.


Summary

Reducing or eliminating estimation can save considerable effort. When the last team I worked with made the switch, we saw the number of stories complete each week increase by 8% as more time was dedicated to development.

I teased the team members that this increase was because they were now making the stories smaller, and to determine if productivity had really gone up, could they please estimate the points of the recently complete stories so I could compare it to their old velocity figures. They saw the irony—but did not comply.

The NoEstimates debate could be recast as a discussion between bottom-up parametric estimating (team estimation via counting points) versus the heuristic estimation of throughput per iteration. Both approaches have their benefits and shortcomings. I realize this kind of simplification will anger members of both camps, but probably not the majority who are not vested.

Some organizations value the process and information brought about by bottom-up estimating. Others would rather redirect that effort toward development and use a different (even if inferior) heuristic estimation. Sponsors should always be asking, “How long will it take?” and “How much will it cost?” We have options to help answer those questions; ultimately, it should be the sponsoring group's decision about how it wants to see it happen.

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]


PMI-ACP Supported Self-Study Group with Mike Griffiths - September Start

Study Group 3
Following the great success of the pilot program, I will be launching another Supported Self-Study Group in September.

For more details and schedule of Zoom calls email me at SeptemberACP@gmail.com

Part book-club, part study-group, these sessions feature weekly live Zoom calls with me, Mike Griffiths and exclusive study materials. This small group, seven-week program, is a cost-effective alternative to full-blown training courses for people able to work through my book independently.

The program works as follows:

  1. Read a chapter of my PMI-ACP Exam Prep book each week and work through the exercises
  2. Join me for a 1-hour weekly Zoom call where we review the chapter and answer any questions
  3. Access a private LinkedIn Group to discuss topics and exam preparation tips with peers
  4. Gain access to exclusive domain mind-maps, extra sample exam questions and exam tips

Benefits

  • Keep your studying on track by committing to a group with a schedule of one chapter a week
  • Much more cost-effective than in-person training (online or face-to-face)
  • Process the chapter during the week at your own pace, not the speed of a common group. (This Inverted-Classroom model allows for people to independently learn at their own pace and come together for discussions and questions.)

New for this series

  • More sample exam questions
  • Exclusive study plan and exercise schedule
  • Additional LinkedIn group exercises and engagements
  • The first 25 people to signup will receive a free Kindle version of my book “Agile Illustrated: A Visual Learners Guide to Agility” that explains each of the PMI-ACP exam content outline domains and tasks.

PMI-ACP Supported Self-Study Group with Mike Griffiths

If you have considered getting your PMI-ACP or need a boost committing to an exam date, this is a great opportunity.

Email SeptemberACP@gmail.com for more details.