Waterfall won’t die.

If you work in IT Program Management, undoubtedly you’ve been involved in the countless process framework debates.   With businesses looking for closer alignment of IT projects with broader enterprise goals and strategies, most are now emphasizing agile project management.

And as consultants banter with PMOs as to the ideal process framework, no doubt the terms critical path, Scrum, PMBOK, LEAN Six Sigma, SAFe and other methods have been discussed around the water cooler.

And among these project management terms, you’ve also heard that Waterfall – one of the most widely used framework –  is going to die.

(Humm…)   I think it’s time for some background.


What is Waterfall?

Simply put, “Waterfall” is the sequential alignment of activities in the most expedient order given available resources and a presumed timeline.  Waterfall is based on completing a project in discrete phases.  No phase begins until the prior dependent phase is complete, and the only way to revisit a phase is to start over at phase one. It’s a clear step-by-step process.

If waterfall sounds strict, that’s because the framework’s history has its roots in industries like manufacturing and construction.  In those industries, project phases must happen sequentially, because, well… there’s no good way to un-pour a concrete foundation.  Right?

As you can imagine, precise planning is key whenever using waterfall.  A project’s requirements must be clear upfront, and everyone involved must be well aware of ALL requirements.

Waterfall phases…

The specific waterfall phases may vary, but they generally include:

  1. Requirement gathering and documentation – Gathering a comprehensive set of requirements.
  2. System design – A system topology that outlines the specifics – such as programming languages, hardware and business functionality.
  3. Development – This is where coders create the desired business functionality as well as the supporting infrastructure.
  4. Testing – Testers methodically use the system to determine if the functionality meets the specifications defined in the requirements.
  5. Deployment – This is where the team submits the system for production release.
  6. Maintenance – Once delivered to production, the team may need to create patches and other releases to enhance the application.

And with Waterfall’s focus with upfront planning and documentation, it has three major benefits that cannot be ignored:

  • Training is simple – Thorough requirements phase of waterfall means that documentation is available and complete and therefore adding team members is easier.
  • Shows progress – Since waterfall requires documenting all activities in the best sequence of completion, the project plan naturally illustrates progress and eliminates much of the guesswork in determining the timeline.
  • Is easy to manage – These benefits, combined with the sequential system, means you’ll know where the project is at any given time and if the project is on track.

And these benefits are why the Waterfall development framework has been popular for so long.

Waterfall for software development

For software development, Waterfall can be problematic if the requirements aren’t clear and static before the system design phase begins. Unfortunately, users rarely have the complete details of what they want.

Late-stage revision can be a serious undertaking.  In fact, strict adherents to the waterfall system would argue that a need for revision means the product requirements weren’t accurate, and therefore the project must return to stage one. This can be a serious problem in many industries, particularly the ever-changing world of software.

With software product development, it’s been shown that an agile approach is most often the best fit for a project if the requirements could change or that revision will be necessary.

Realistically, most software development is best done with one of the iterative frameworks that embraces changing requirements and features.

Freshly deadWhen should we use Waterfall?

I ran a Big Data program a few years back at a enterprise software / hardware manufacturer.   This program’s mission was to create a business data lake, recast the business features with newer technology and to decommission a traditional structured data warehouse.

One of the six streams of work in this program was to construct a converged hardware platform… which, I might add, is similar to constructing a building, meaning that there were specific activities that needed to occur in a specific order.   And since we knew what these activities were and that they were unlikely to change.   So the hardware infrastructure project stream was run as waterfall.

However, the software work streams (e.g., creating an ingestion engine or reporting applications) were run using Agile to get the benefits of direct, daily business engagement and to be able to experiment as we were developing an emerging technology with requirements that were not set in stone.

The waterfall development methodology is best for projects that are well defined… from the beginning. And whenever you are certain that the project requirements are static, then waterfall project management provides a straightforward way to push a project along a clearly defined path. It’s simple to manage and easy to track.

And so waterfall will never die.  Nor should it.


Kevin Griggs is a technology program manager who helps organizations establish program management offices and manages complex programs across a variety of industry verticals.   Kevin can be reached at kevin@kevingriggs.net.

Project Portfolio Management; you might be doing it wrong…


Around 10 years ago, companies started ramping up Program Management Offices (PMOs) in an effort to drive greater efficiency through their Innovation Portfolios.   The primary goal was to deliver strategic objectives faster.   Speed – so it was thought – was the key to competitive advantage.

Did it work?    Let’s break it down.

The PMO Mission

PMO’s are chartered to bridge the gap between product strategy and execution – ensuring that programs are aligned to business goals and deliver expected enterprise value on time and within budget.  To do this, PMOs adopted governance frameworks based on a hierarchy of Portfolio, Program and Projects.

  • PORTFOLIOS – the collection of programs that optimize the delivery of strategic enterprise objectives.
  • PROGRAMS – groupings of projects designed to deliver specific business features.
  • PROJECTS – activities that deliver a defined business or technical capability based on an agreed upon schedule and budget.


What’s working well – Project Management

And during the past decade, PMO efficiency gains have been at the PROJECT level where adoption of iterative execution methodologies – the most popular being Scrum – coupled with outsourcing has reduced cost and increased the speed of innovation delivery. This project-level focus was understandable as projects are the source of the greatest expense.  Agile development coupled with the use of offshore resources has increased the velocity of innovation.

So does this mean that project portfolio management has been successful?      Not yet.

Slide1What’s not – Portfolio Management

While PMOs are delivering capabilities more efficiently due to better project management, less has been done to ensure that the programs within the innovation portfolio are optimal.

Steve Jobs described innovation as: “You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.”

Prioritizing the right development initiatives is the focus of project portfolio management. And prioritization is sorting by desirability… making sure that teams work on first things first.

The most common approach to prioritization is ranking programs against a value metric of expected financial return.   This is done by plotting the expected return of a project against the cost to deliver to create a frontier graph as a way to visualize the best ‘bang for the buck.’

In this example, I’ve graphed a single value criteria (NPV) against the cost to deploy each project.   Those projects plotted to the left add significantly more value with less cost with successive projects adding less return to the portfolio at higher cost.


Project prioritization based on a single value criteria is seductively easy.   In fact, it’s too easy.

‘Ranking and Yanking’ projects just won’t build a balanced portfolio, one that meets a set of competing objectives.  Despite the fact that firms often simply chase those programs with the highest expected returns, PMO’s need to balance a larger set of objectives such as when revenues will start to be realized… when they will peak… team resource utilization… market considerations… existing product  cannibalization… and a whole bunch of risk factors.

“There is nothing worse than doing well that which should not be done at all”   – Peter Drucker

Project portfolio management is about correlating projects based on more than a single objective.   The idea is to create a portfolio that meets the best mix of objectives versus a portfolio based on a single value criteria.

Prioritizing programs simply based on the highest expected return might seem like the most rational approach –  but it rarely is.


Kevin Griggs is a technology program manager who helps organizations establish program management offices and manages complex programs across a variety of industry verticals.   Kevin can be reached at kevin@kevingriggs.net.

Becoming Agile – It’s No Longer Optional

Most companies deliver software products by using dozens of teams focused on different stages of the product development lifecycle.  And today’s competitive pressure to deliver products faster means that most firms are experimenting with agile development techniques.  They often they settle on one of the many flavors of agile – Scrum being the default choice.  Typically, they start with a proof of concept using a few Scrum teams, achieve some noticeable measure of success, then start to scale agile across the enterprise.

And that’s when the problems start.

Enterprise agile – versus team-level agile – requires a different organizational mindset along with new roles and practices.  There are several enterprise agile frameworks available (Scrum, SAFe, LeSS and XP) that can provide a blueprint for development activities, but switching to these frameworks isn’t the biggest challenge.  Enterprise agile is a radical change from how most organizations think about their product development work.

As a consultant who helps firms on their agile transformation journey, it’s clear that agile is now vital to long-term product success.

AgileCraft CEO, Steve Elliott, predicts that those Fortune 1000 companies who have resisted agile transformation will now jump on board. Steve writes that every large enterprise will sooner or later realize “…every company is now a software company…” And I’ll add to Steve’s prediction; those firms who are already on the agile transformation path will experience significant competitive advantage over the laggard adopters.

In 2014, Faisal Hoque wrote in Fast Company (“Adapt or Die, Your Business’s Only Option in an Evolving Economy”) companies require four qualities to effectively respond to market change.

1. RESILIENCEAble to bounce back from setbacks.

2. INNOVATIONAble to develop new products that advance beyond the competition.

3. AGILITYAble to act nimbly to seize opportunities faster than the competition.

4. ADAPTABILITYAble to sustain innovation through repeatable processes versus happenstance.

Today’s business economy is fast and dynamic and the principal challenge facing management is the ability to quickly respond to changing market conditions. Companies that are adaptable, agile and resilient will be best equipped to experience sustained success.

Most technology companies won’t survive the next decade. Research shows that those with the highest frequency of new products deployed have a much better chance. Using agile techniques, along with continuous integration / delivery, provide the greatest chance of long-term success as compared to traditional SDLC approaches.

Product innovation excellence can’t be purchased — it’s created from three areas of development focus; 1) an adaptable organizational culture, 2) use of an agile framework and, 3) a product research program that provides higher reward development opportunities.

All three focus areas are needed, and an agile framework is good place to start.

Is the Future of Enterprise Collaboration Now?

People don’t share enough information.  It’s a well-documented behavior. Sometimes they horde because they have been led to believe that “knowledge is power” and centralizing data access will increase their personal value to the firm.  Luckily, the primary reason for lack of sharing is due to legacy information systems which are sub-optimal for sharing and discovery and not bad behavior.

It’s been two years since McKinsey Global Institute published The Social Economy.   In that research, McKinsey concluded that use of social technologies could provide 2x the value in enhanced communications, knowledge sharing and collaboration within companies over traditional methods.

“By adopting these organizational technologies, we estimate that companies could raise the productivity of knowledge workers by 20 to 25 percent. However, realizing such gains will require significant transformations in management practices and organizational behavior. Social technologies can enable organizations to become fully networked enterprises—networked in both a technical and in a behavioral sense.” McKinsey Global Institute

Most businesses understand that enterprise social networking is one component of a solution to improve workplace efficiency.  And despite that these tools have been around for what seems to be a dog’s age, their adoption has been growing slower than what McKinsey predicted in 2012.

Interestingly, the notion of enterprise collaboration is as old as the enterprises themselves;  however, it is only recently that information technology has been able to support the concept.   In the 1980s, companies began using desktop productivity technology such as word processors and spreadsheets.  The early 1990s was the advent of basic messaging tools such as e-mail and and later chat.  In the 2000s, the capability moved to increased team productivity supported by wikis, blogs, and conferencing facilities.   But true enterprise-level productivity achieved through making the right connections at the right time has remained an elusive ‘holy grail.’

For those of us who design information products for use within companies, it was assumed that McKinsey’s research would cause an explosion of firms looking to capture untapped productivity through using Web 2.0 tools inside the firewall.  Even though the pace of companies embracing enterprise social collaboration has been increasing,  it’s not as rapid as every study I’ve read in the past few years predicted.

But I am sensing a sea change in companies both large and small.   The value of enhanced workplace collaboration is now simply too large to ignore.

And the primary driver is coming from how companies are reshaping themselves.

How you say?

Companies are flatting their hierarchies.  That’s a trend that’s been happening for years.  And the effect of this trend is that ‘management’ decisions must be made by a more engaged, informed and autonomous workforce.   The flatter the organization, the greater the need to share information more broadly throughout the firm.

As leadership functions continue to become more distributed, the workforce will need ever greater access to key information to  make the right decisions without access to line manager authority.  In short, the workforce must become more empowered.   And information DOES equate to power… but only when hundreds of people can find the information they need and can put it to use.

Zappos announced an approach where there are embracing a new management called Holacracy which organizes around the work that needs doing versus around people and titles.  There are a number of these new matrixed workforce structures all of which are targeted at reducing organizational inefficiencies.

And the primary technologies that will make these flatter management structures succeed are precisely the social / Web 2.0 collaboration technologies that McKinsey predicted in 2012 will become pervasive within all successful firms.

So maybe, just maybe… the promise of Enterprise 2.0 is soon to be realized.

Innovation of the Boring and Mundane Product

Innovation is defined as the application of solutions that, 1) provide new requirements, 2) address unarticulated needs and, 3) improve existing products in the marketplace. For most innovators it seems easier (read: less confined to previous product decisions) to innovate a concept that is both new and fresh.

But… what about innovating a mundane product that’s been around for 40+ years with few significant changes? And more challenging; what if the consumer considers the product mostly invisible and doesn’t really want to buy it. Now that’s a product challenge!

The Nest Protect (www.nest.com) is an interesting case study. Nest has addressed all three notions of innovation with their new smoke and carbon monoxide detection. The Nest Protect is an intelligent Wi-Fi aware, network and smartphone-app-linked smoke and CO2 detector. This innovation shouldn’t be in the same category as those annoying and dysfunctional hockey pucks now stuck on your ceiling.

In short, this is a not your grandpa’s smoke detector.

The Nest Protect innovates in a number of ways. The first is that it’s “location aware” and will provide feedback through a number of channels as to where a problem is detected. It knows there’s smoke in the basement and tells you that.

In short, it’s smart. Wicked smart. (Yep, I live in Boston.)

Let’s say you are making (ah-hem, more accurately “burning…”) toast in the kitchen. The Nest unit won’t simply blast that annoying emergency alarm, but will instead provide a friendly nudge and flash a yellow light. A voice will say “Heads Up, there’s smoke in the kitchen!” And to acknowledge that your cooking skills are deficient which can’t be solved with the local fire brigade, you simply wave your arm fully within 2-6 feet of the unit until it speaks, “Alarm Hushed…” No more throwing open doors and windows in a January snow storm coaxing the blasted thing to stop blaring and the dog to stop barking. Eventually. (We’ve all been there.)

And in case you aren’t home, you’ll receive a notification of any activity on your smartphone, so that you can take action before an issue becomes a problem.

That intelligence carries forward into monitoring the health of the unit’s sensors and remaining battery life. And how much would we pay to stop that incessant but undiscoverable ping in the middle of the night from a battery slowly dying? (We’ve all been there too…) The Nest Protect sends an alert message to your smartphone whenever the battery is getting low, and will continue to remind you, so that you can change the battery before your midnight ride around the house on the step stool searching for the culprit.

And whenever you are roaming around the house in the dark, the Nest Protect senses your presence as you approach and will turn it’s green “all okay” glow to a white light in order to light your way in the dark.

And if the emergency is more than just burning toast… the Nest Protect will flash red, announce where the fire is located and will provide clear instructions on all attached smartphones as to steps to take as well as place an emergency call with a single button press.

The Nest Protect addresses a number of annoyances with “modern” smoke detectors while responding to a number of unarticulated needs such as the ability to shut down non-emergency situations, identification of WHERE and WHAT issues have been detected, and remote notifications and system health monitoring via a simple smartphone interface.

Nest has taken the boring and mostly annoying home emergency detector and created a much more useful appliance. Don’t think that Nest is marketing a smoke detector, they are selling greater peace of mind.

So who says you can’t build a better mousetrap?