I was at the IRCE in Chicago last month. One of the speakers (don't remember who) put up a slide that said 'the biggest lie in software is phase 2'. I hadn't heard that phrase before, but it rang true. Having spent the last 15 years on the integrator side of the software business I've seen far too many projects that started off great but ended up, for one reason or another, negotiating away critically important business functionality to phase 2. When a phase 1 project launches feature light the business may end up without the necessary tools to produce the ROI that they signed up for during the strategic planning phase of the project. For the purpose of this post, the whys don't really matter. But, some common whys include unforeseen complexity in legacy systems, poorly articulated & documented requirements, bad estimation, management coerced bad estimation, etc. Regardless of why, we may end up in a scenario where the phase 2 functionality is needed to get to the ROI end game, but business justification is difficult to obtain.
“Phase 2 is typically the mythical future world where those ‘things we didn’t get to’ in Phase 1 go to die. Few members of the team are harder hit by this reality than the user experience and design staff. Their holistic visions of product and service experiences are put aside in favor of significantly thinner software.”
In the Harvard Business Review article, 'The Biggest Lie in Corporate America is Phase 2' Jeff Gothelf makes a compelling argument for moving from a traditional waterfall software development model to a more iterative model that includes problem statement focus, agile project model and cross functional team involvement.
Large scale multi-phase waterfall projects are tough to make successful. So much work has to be upstream of development, and the world is moving so fast today, that once we start development our requirements are often already stale. Another key challenge point is that this project methodology does not allow the business to hone their skills consistently over time. They're forced to wait for long periods of time and then are typically delivered a system that they quickly have to become proficient in. It's a tough model.
How do you eat an elephant? One bite at a time.
The organizations that I've worked with that enjoyed the greatest system success treated their complex system bundles as a single program or product -- e.g., a multi-brand, omni-channel eCommerce program. Where that program or product is actually a bundle of WCM, eCommerce, PIM, CRM systems coupled with sometimes dozens of external services. By focusing on the entire system it's easier to align functionality, with strategic objectives and desired outcomes. That's a key requirement for getting to a realistic and actionable feature backlog, release schedule and ultimately, a product roadmap. This also sets the stage for maturing skills and experience within the team that's using the product. It's difficult for a marketer to really understand the nuances of multivariate testing or goal attribution when they don't have the functionality available to work against. The release schedule aligns with strategic priorities and with campaigns that the business executes against.
This is all a windy way of saying that organizations that adopt some version of an agile development methodology will enjoy a more predictable cost and delivery schedule, better engagement between the product team and the business, more flexibility to change, higher quality and, ultimately, a better product.