Avoiding the Big Bang

No, we're not talking Creation Science here. 

This is the next of a series of Taber Reports that are excerpted from my upcoming Addison-Wesley book on Salesforce.com best practices.

Today's excerpt has been translated into a classic Product Management issue:  defining and prioritizing product requirements.  I'm hoping that you'll find areas in the text that you want to correct or amend: please email me with feedback where you think I'm full of it!  Through vigorous debate, the ideas will get even stronger.  The best argument of the month wins a prize.

Big Bangs and Waterfalls

If you’ve ever done a “knock down” remodel of a house, you can believe the statistic that 38% of these “big bang” projects blows up, causing a divorce.* Why does this occur?

All over IT, Big Bang projects – with major chunks of functionality delivered all at once – are more likely to suffer budget over-runs and schedule slips. While first documented in the 1960s by Fred Brooks' classic The Mythical Man Month, the evidence continues to the present day: 

“Technology projects bare a striking resemblance to home renovations. Both are surrounded by wildly high hopes at the start and often end up causing financial and emotional heartache. Even now 50% of IT projects suffer budget overruns and 62% have experienced delays, according to a new report by Tata Consultancy Services”        – Elizabeth Bennett, in May 2008 Baseline Magazine.

This also happens in product definition:  it's easy to sell The Killer Product concept to executives, setting all kinds of expectations about features, schedules, and profitability.  And almost always, these expectations will be wrong.  As with a home remodel, big bang product development involves solving problems whose scope cannot be truly known until the project is underway. It’s only as you rip away the veneer of patches in presentation logic that you discover the dry-rot of bad data structures underneath. It’s only when you actually try to install the new fixtures of user interface that you understand the incompatible data pipes that were hidden before. With each new problem comes an engineer's recommendation to “fix the architecture,” which can only add to short-term cost and delay.

As a big-bang project starts to slip, it’s common to justify and “re-sell” the project by adding more features. This leads to scope creep, the expansion of project deliverables with little regard for budgetary, schedule, or logistical realities.  Decision makers often miss the logical folly of statements like, “We promised to give you X in 9 months...weren’t able to do that…but now we’ve found a way to give you 1.5x in 12 months!” And the net result is that the project delivers 1.1x in 18 months, if you’re lucky.

Big bangs backfire because of long time-lines, uncertainty, poor project sizing, false expectations, and wandering executive attention. The executives approving the project want fixed price, fixed schedule, and a guaranteed set of features. This would be fine with perfect command-and-control, but even in the defense department project overruns are legendary.

Most big-bang projects use a waterfall model of project management. Symbolized by Gantt charts, the waterfall theory starts with requirements being thoroughly documented at the beginning, and delivered through a linear process of design, coding, testing, and deployment. The three problems with the theory: (1) it doesn’t work in software, (2) it ignores the reality of requirements discovery and competitive change during the project, and (3) it doesn’t work in software.  What really happens is, users give engineers a big spec and a budget…and are told to go away for 11 months.  After the coding work is done, the project is presented in test mode to users, who are often shocked with the developer’s lack of quality control, taste, and ESP.

A clear antidote is to change the constraints and assumptions, to reflect software reality and improve the performance and flexibility of software teams:

• Remove one of the constraints: keep the schedule and budget fixed, but allow variation in the features delivered.
• Focus on the end-state, rather than the delivery style: instead of delivering “everything” as a package at the end, allow the team to deliver functionality in small chunks, over several rapid iterations.

While these choices may seem irrational, when properly managed they deliver with less risk, less trauma, and with a higher likelihood of delivering what actually matters to customers and the business without breaking the bank.

Agility

2001's Agile Manifesto argued that waterfall methods and classic top-down project management could not deliver quality software quickly.  Instead, it proposed an iterative style of thinking and delivery:  peeling off the layers of the onion.  Requirements couldn’t really be set in stone at the beginning – even if they were, during the 12 months of the project competitive and internal changes would invalidate major parts of the “stone tablets.”  Fifty years of software experience showed that customers didn’t really know what they wanted until they saw an example of it.  So, why not set requirements dynamically, as the project went along? Why not start with a prototype (or story-board) and a reality test (is this Zune actually any cooler than that iPod?) rather than an abstract document of features?
Since requirements would be set incrementally, why shouldn’t testing be done at every stage? Instead of keeping everyone in the dark about quality issues until the very end – where it’s most costly to fix – why not expose as many quality problems as possible early? 

An Agile project is like a subway system: everyone knows how much the journey will cost and how long the overall trip will take, but you don’t know (or really care) which specific train you’re going to be on or which transfer station you use.  As the executives get more confident that “the next train” will arrive very soon, they’ll be less upset if their favorite feature didn’t happen to make this particular train.  They’ll resist the temptation to pull political strings to accelerate their pet feature at the expense of others, or push for scope creep.

Like the Japanese auto industry that focuses on flexible manufacturing and repeatable processes to gain speed and profitability, the Agile methodology was trying to “get lean” – changing the rules to improve quality and deliver better value to the customers.  Unlike the Japanese auto industry, software didn’t have the statistical or procedural rigor of the Deming methods.

Agile Planning and other Oxymorons

While Agile methods allow for very rapid productivity, it only really works with developers who are serious wizards and users who are highly motivated and engaged. The engineers will frequently ask the project leader and user representatives detailed questions and tricky priority calls.  Typically, the engineers will need to get their answer in a few hours or they’ll start to lose development time.  Agile demands a lot from the team members, and most projects don’t have the luxury of perfect human resources.

Other issues have come up: Agile methods are highly focused on the needs and behaviors of engineers. Non-technical managers don’t receive the tomes of requirements documents and project plans, so they find it tough to figure out what’s going on or what the real status of the project is.  The pointy-haired bosses (PHBs) want to see project milestones that are fixed, measurable, and with deliverables defined well in advance.  The bean counters get nervous about the chaos and uncertainty about costs.

Agile projects can appear to be very chaotic, with tasks and resources seeming to “jump around” on a weekly basis.  For the participant as well as upper management, the flexibility that is the hallmark of Agile projects can be very stressful.

Further, Agile projects can become defocused when the SCRUM teams work items off the backlog in the order they appear, rather than the order that is needed to satisfy all the dependencies and prerequisites of a complex feature.

Even with these issues, the economic, quality, and productivity advantages of Agile are hard to deny. The technologies of SOA and SaaS (and their hardware counterparts, FPGAs and simulators) cry out for an incremental, prototype-oriented style of development.  So how to impose a bit more structure?

Product Managers and traditional product teams are comfortable with the Product Requirements Document, but these tomes have almost never been a truly effective way of guiding product development.  And in an Agile environment, writing a traditional PRD would be an exercise in irrelevance.  But keeping the "stories" or "cards" of the Agile project teams organized, self-consistent, and prioritized would be extremely valuable.  The teams would be working on complete deliverable features, rather than fragments of what the user needs.  The teams would be working on what's important, rather than what's convenient.  The sprints would have more meaningful deliveries (and more real-world tests), providing better motivation for the business types as well as the engineers. 

The Product Managers' high level document should be presented as a roadmap to management, satisfying their needs, and as a Wiki to team participants.  For those of you into paper, the PRD would become a binder with 1-page sections.  Pages would be ripped out and replaced on a weekly basis.

Include the Customer

As you may know, I'm a big fan of user-centered design, where customers are so involved they effectively become design partners.  I'm also a big proponent of designing the customer before you design the product. 

In the Agile world, this changes a bit:  you need to segment the customer as you build the product.  Since you don't actually know what feature is going to make it on any particular iteration "train" until it's about to leave the station, you have to think about the consequences of whom you're going to market a particular iteration to.  The trick is to focus on customers who are truly representative of the groups you want to be selling to.   It's easy to focus too much on early adopters who are enthusiastic participants, but not in the main stream of where you need to be selling. 

________________
*The American Architects Association is too embarrassed to have ever published these numbers but the Construction, Restoration And Planning organization conducted a survey and published it on its website, www.crap.com (Okay, it’s true, I made this number up.)

  Digg This!  

Secrets of SFDC Success Chapter -- coming in June

Contents copyright 2008 by DOTnet Consulting, Inc., all rights reserved.
All trademarks and graphics are the property of their respective owners.
Feel free to forward or syndicate this report, but you must include this copyright notice.
Somebody Brilliant™ is a trademark of DOTnet Consulting, referring to its principal.
This newsletter was mailed to you because our records show that you asked to receive it.
Click here to opt-out of future newsletters, although that will make us feel very sad.