About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

Waterfall, Agile, and Death Marches

I’ve grown weary of internet debates about software development methodology, argued by people who don’t really understand the vocabulary they use. Allow me to provide a brief lesson on three of the most commonly misused terms.

The Origins of the Epithet “Waterfall”

A little history: Winston Royce is attributed with defining the methodology now called “waterfall” in his 1970 paper, Managing the Development of Large Software Systems although that term never appears in the paper. Royce was offering his opinion on what worked and what didn’t work after nine years of software project experience. While software for internal use could get by with just analysis and coding, paying customers needed a more rigorous approach. However, Royce argued against using a purely sequential process for developing software. In his paper, he critiqued several diagrams, beginning with the one below.

Royce noted that the lack of feedback between the sequential activities was a fatal flaw, but that the feedback flows had to be managed in order to avoid runaway scope. He explored several other diagrams in his paper, which became progressively more complicated until they resembled a spaghetti-and-meatballs dinner for sixty or so. Plainly, feedback was necessary but it was possible to become paralyzed.

The earliest use of waterfall in referring to a software development model may have been in a 1976 paper on software requirements by Bell and Thayer, which referred to Royce’s paper. During the 1980’s, there were several “structured” software project management methodologies marketed by various consulting firms that looked much like the more complex diagrams in Royce’s paper, but no one has actually used any of those methodologies for decades. None of them called their methodologies waterfall, either.

Time Marches On

Technology has changed dramatically in the last half-century. Where the primary cost constraint in 1970 was computing time, it is now knowledge-worker time. Where the primary technical challenges were data storage and code efficiency (does anyone remember dates with two-digit years?), storage and retrieval technology now provides terabytes for the price of a good dinner, free relational databases, structured and ad hoc queries that return results in milliseconds, and a global network with connections to tens of billions of processors. As a result, the nature of software products has changed from calculations of orbital mechanics and industrial controls, written by and for large corporations and government agencies to (overly) personal communications and videos of cats, paid for with marketing messages.

In Royce’s era, programmers and users submitted Hollerith cards and (maybe) a day later scanned the results on 132-column green-bar paper. Today, users have the expectation of point, click, fill-it-in-for-me, and tell-me-what-to-correct. Where once coders spent most of their time writing code to detect and handle logic breaks and invalid inputs, they now focus on the presentation layer. No one optimizes for memory usage, and execution speed only becomes a concern when responses are returned in more than two seconds. There are standards for virtually everything, reducing the effects of obsolescence, and a global communication network that facilitates collaboration across and between continents and cultures.

Software development today bears as little resemblance to 1970 as modern agriculture does to Mesolithic-era farming in the Fertile Crescent twelve millennia ago. But there are still farmers and there are still programmers, and the micro-economics of production still apply. And the same seven activities identified in Royce’s diagram are still needed, even if we organize and execute them differently.

Agile is Not a Performance Characteristic

Most modern software development organizations will tell you that they use agile methods. The term refers to the Agile Manifesto, composed by seventeen thought leaders at a conference on lightweight software development methods in 2001. While there are several software development methodologies marketed as “agile,” in most organizations “agile” is a synonym for Scrum. Other common “agile” methods include Kanban, XP, and DSDM. Each of them addresses the seven basic activities, although the level of detail varies widely.

Note that “agile” in this context is a label, rather than a performance characteristic. While many organizations use these methods (or combinations of them) effectively to produce reliable, maintainable software that creates real value, many others flounder. An entire industry of consultants and trainers offer their services to those who want to succeed with agile methods. Many of these experts (and their students) disparage what they assert are “non-agile” approaches with the generic epithet “waterfall.” That doesn’t make them so.

Complexity Requires an Even More Rigorous Approach

As noted, the Agile Manifesto arose from a conference on lightweight methods. While that certainly describes much of modern software development, many software projects require compliance with a variety of contractual, legal, and regulatory requirements, in addition to functional and technical requirements. These complex projects tend to include a lot of requirements elicitation, analysis, and design tasks that must be finalized by people who are not coders before decision makers will give their approval to proceed with actual coding. Because of these controls and process requirements, numerous parallel workflows by people who are not coders, critical decisions that often have nothing to do with code or coders, and the higher cost and longer duration of complex projects, they are typically managed using predictive methods—in other words, estimating task duration in advance, in order to schedule activities so that knowledge workers who are not coders can manage their workflows.

Complex projects include most government-funded projects, most projects for heavily-regulated businesses, and nearly all products in the medical devices or aerospace industries. Agile methods are used for some project activities, in parallel or in series with other activities using other approaches, when it makes sense to do so. People who don’t understand (and don’t care to understand) anything about these external controls and processes often dismiss them as command and control or waterfall or some other epithet. The rest of us understand that you have to skin a rabbit before putting it over the fire—see “Payne, Podrick” for an illustrative misuse case.

Death Marches Aren’t About Methodology

A project should be approved based on a specific business case, with parameters such as a scope, delivery schedule, budget, a staffing model, and performance and quality goals that are realistic. Ed Yourdon defined a death march project as, “One whose ‘project parameters’ exceed the norm by at least 50 percent.”

Acme Tornado KitThe business case should be updated whenever the business environment changes or assumptions prove to be invalid. An oversight committee should meet periodically to assess progress and risks, along with the probability of achieving the goals in the business case. This committee should be empowered to adjust any of the aforementioned parameters, and even to cancel the project outright if it seems necessary. Thus, death marches are not a failure of methodology but a failure of project governance.

Although there are still many organizations that will continue death march projects even in the face of evidence that the project will fail to achieve the intended business goals, few of them are profitable and essentially all of them have other bad management habits. In the words of Eric Bogle, “… year after year, their numbers get fewer. Someday no one will march there at all.”

The Project Manager’s Bookshelf: Business Acumen

PMI Talent TriangleI began this series with a few books that I recommend for developing people skills, then followed up with a list of books on technical skills. This week focuses on developing business acumen, closing with books on procurement and basic business law.

Project management is a business function, even if you’re managing software development or moving your internally hosted enterprise applications to the cloud. Business acumen is a bit like Justice Potter Stewart’s comment on pornography—hard to define, but you know it when you see it. There are a few foundational knowledge areas that support development of acumen, and I’ve covered some of them here. But you also need to read business news—I like The Economist for general content on the business environment, but also find a source that focuses on your industry. Read your company’s financial reports and communications to investors, as well as Mary Meeker’s Internet Trends Report. And ask your boss’s boss what she reads.

Finance and Accounting

If you have an undergraduate or graduate business education, you can safely skip this section. For everyone else, this is a vocabulary and an understanding of processes that you need to acquire, even if you don’t completely master it.

Accounting: A Beginner’s Guide to Understanding Financial & Managerial Accounting by John Kent. If you’ve never taken any accounting course, at least get familiar with the vocabulary of financial and management accounting. This is a very basic intro.

Financial Statements: A step-by-Step Guide to Understanding and Creating Financial Reports Third Edition by Thomas Ittelson. You need to be able to understand and ask questions about your company’s finances. This book will introduce you to the income statement, cash flow statement, and balance sheet.

Discounted Cash Flow Modeling for Project Financing: A Step-by-Step Instruction by Monique Young.  Good coverage of a moderately complex topic, although the author needs to be introduced to a good editor. Focus is how to implement a model in Excel. Less than $5.00 in Kindle version.

Strategy and Competition

Project managers are given the responsibility for implementing business strategy. Not every project is strategic, but if you aspire to manage those high-visibility, career-making strategic projects, you need to understand the nature of competition and how business strategy is developed to compete in complex markets.

Competitive Strategy: Techniques for Analyzing Industries and Competitors by Michael E. Porter. Explains the three generic strategies—lowest cost, differentiation, and focus—and shows how competitive advantage links to profitability.

Business Strategy: A Guide to Effective Decision-making by Jeremy Kourdi. This is a bit basic, but it’s well-written, as you’d expect from The Economist. From understanding what strategy is to how strategies are developed, to implementation—where project managers come into the picture. Lots of brief examples, not detailed enough to be called case studies, but still illustrative.

Marketing

Every organization delivers products or services, and most deliver both. The means and channels of marketing has evolved dramatically in the last two decades, and a large part of business acumen is understanding how the relationship between the organization and it’s customers is initiated, developed, and maintained.

Customer Centricity, Second Edition by Peter Fader. The customer is not always right, although the right customer is always right. Fader gave us permission to focus on the customers whose business is profitable for us and send the rest somewhere else. Lots of examples, success stories, and a few horror stories.

Social Media Marketing Mastery 2020: 3 Books in 1 by Robert Miller. These three books cover branding and how to be an influencer through Facebook, Twitter, and YouTube, and how to “Win followers and influence millions” using Instagram. Welcome to the third decade of the 21st century.

Procurement and Business Law

I am not an attorney. But from years of experience in procurement and contract negotiation, I’ve come to appreciate the value of a basic understanding of business law in formulating good questions that attorneys can answer.

How to Write an RFP and Manage an RFP Project by E.B. Diamond. A guide to preparing a request for proposal and managing the competitive bidding process. Note that this presents a commercial point of view; government agencies will have a detailed and usually rigorous process for procuring goods and services. As much about project management as it is about preparing RFP’s.

Business Law by Robert W. Emerson. Part of the Barron’s Business Review series, this covers US law. If you’ve never taken any kind of business law course, this is a decent self-study text. That said, at 974 pages, it isn’t an easy read. The first three chapters introduce a lot of history and vocabulary. Definitely read chapters 4, 5, and 8 on contracts, and after that, you should skip around to the topics that matter to you.

In Closing

I’ve suggested books on a wide range of topics in this series. While I don’t expect anyone to read all of them, I hope this series has led you to think about how these knowledge areas fit into your personal development plan.

The Project Manager’s Bookshelf: Technical Skills

Last week, I listed a few books that I recommend for developing people skills. Next week, I’ll close out the series with a list of books on developing business acumen. But this week’s list is about technical skills.

PMI Talent TriangleThe phrase “technical skills” means different things to different people. A programmer, an industrial welder, an aircraft engine mechanic, and a pharmacist each have their own technical skill sets, and their own courses of study and reference books. I’ve collected a short list of books that I’d recommend to a practicing project manager or someone who aspires to that role, to help develop what I would consider technical skills for our domain.

Business Mathematics

Business math skills as foundational to much of what we do as project managers. From analysis to presentation to decision making, our ability to “do the math” is assumed. I won’t recommend that you aspire to the skill set of an engineer (or an actuary, for that matter), but good project managers are both literate and numerate; an MBA skill set is a good target. These two books cover the basic stuff. Once you realize how much you’ve forgotten, you’ll likely want to go deeper. And you should.

Schaum’s Outline of Basic Business Mathematics by Eugene Don and Joel Lerner. If the mere thought of doing math makes you queasy, start at the beginning. The first two chapters are a review of middle and high school topics, but after that, it becomes about payroll, depreciation, interest and discount, annuities, stocks and bonds, buying and selling, and insurance.

Introductory Statistics by Barbara Illowsky and Susan Dean. This book was designed for a first course in statistics, for students majoring in fields other than math or engineering. I just downloaded the Kindle version for free, and the table of contents maps pretty well to the book I still have from the intro course I took in the 1970’s.

Data Visualization and Presentation

Every complex bit of information you need to explain to an audience, where in person or in print, benefits from thoughtful presentation.

Slide:ology: The Art and Science of Presentation Design by Nancy Duarte. A classic. Her TED talk on the secret structure of great talks, incorporating as-is and to-be into a presentation, is also worth your time.

How Charts Lie: Getting Smarter About Visual Information by Alberto Cairo. A bit lightweight, but a good introduction to visualizing data and presenting information to decision makers.

Excel Dashboards and Reports for Dummies by Michael Alexander. I’m not a fan of the “For Dummies” books, but this one gets the job done. Once you learn to leverage functions into complex formulas in Excel, a thousand ideas will present themselves.

Tools

You don’t need to be a ninth-cloud turban and diaper guru on MS Project, Excel, or Visio to be a successful project manager, but these are the tools I’ve used the most, and I work at mastering them.

Microsoft Project Do’s and Don’ts: The Definitive Guide to Jumpstart Your Project by Sam Huffman. I’ve read over a dozen books on MS Project and I even wrote one. This one is the best I’ve ever read.

Microsoft Excel 2019 Data Analysis and Business Modeling by Wayne Winston. This is the sixth edition; I had the second but left it to a colleague. It’s an excellent reference book. Some of the later topics are a bit “out there,” but you don’t have to read the whole book—just the parts that resonate.

Microsoft Visio Advanced – A Step by Step Visual Guide by Richard Walters and Karim Dastgir. Lots of screen shots with not a lot of text. I use Visio for a lot of chores, from block diagrams to flow charts to hierarchy charts. This book goes much, much deeper into tools and techniques than I normally use, but my interests are not yours.

Design and Development

I was tempted to add several more books to this list, but my goal for this series was brevity.

Hooked: How to Build Habit-Forming Products by Nir Eyal and Ryan Hoover. Designing products that attract repeat customers. You’ve probably seen this book on other lists, for good reason.

The Design of Everyday Things: Revised and Expanded Edition by Don Norman. Not just about how people interact with user interfaces, but how they think about the things they want to do. A true classic—one of the most interesting books I’ve ever read, and I’ve read it at least four times in the last 25 years.