One of the services VIA can provide is to serve as a bridge between marketing and technology groups, two parties with a history of not really understanding each other.
Though that is getting better, in our experience, there remains a gulf between the worlds. As an engineer I once worked with put it, for one group (traditional marketers), scurrying to finish can result in embarrassing mistakes like typos in advertisements. For the other (technologists), it can mean flipping the “on” switch for a new project and not having it come on — at all.
This gulf has received rare public notice with the healthcare.gov Web site debacle. Clay Shirky, who writes and teaches about the cultural impact of the Internet, has an interesting take on healthcare.gov, and calls out the “waterfall” approach to project management as a particular problem:
“This is a management problem, and a cultural problem. The preferred method for implementing large technology projects in Washington is to write the plans up front, break them into increasingly detailed specifications, then build what the specifications call for. It’s often called the waterfall method, because on a timeline the project cascades from planning, at the top left of the chart, down to implementation, on the bottom right.
“Like all organizational models, waterfall is mainly a theory of collaboration. By putting the most serious planning at the beginning, with subsequent work derived from the plan, the waterfall method amounts to a pledge by all parties not to learn anything while doing the actual work. Instead, waterfall insists that the participants will understand best how things should work before accumulating any real-world experience, and that planners will always know more than workers.
“This is a perfect fit for a culture that communicates in the deontic language of legislation. It is also a dreadful way to make new technology. If there is no room for learning by doing, early mistakes will resist correction. If the people with real technical knowledge can’t deliver bad news up the chain, potential failures get embedded rather than uprooted as the work goes on.”
There are many reasons to like the “waterfall” method: It provides the illusion of control for non-technical managers, and it provides CYA to technologists who are skeptical about the managers’ decisions. When things go wrong, the technologists can say, “But you signed off on it.”
Beyond the technology problems that are bound to show up (and require plan changes) in any project, there are user experience reasons to reject a waterfall approach: User Interface guidelines don’t generalize well*, and it is only through interaction with a product that we can determine what really works and what doesn’t.
This calls for prototyping and measured release schedules. The healthcare.gov project calls to mind some large Internet projects we worked on in the early 2000s, when companies tried to solve all their problems at once.
(The idea of completely revamping an information architecture, coming up with a new design and implementing a content management system that solved all the publishing problems was common then and still a dream for marketers now. This is referred to here as a “Technology Death March”. That’s a topic for another post.)
You can read Shirky’s entire piece on the Obamacare site on his blog: Healthcare.gov and the Gulf Between Planning and Reality.
* For background on why user interface guidelines don’t guarantee success of a user interface, see Thomas K. Landauer’s “Let’s Get Real: A Position Paper on the Role of Cognitive Psychology in the Design of Humanly Useful and Useable Systems” in Designing Interaction, J.M. Carroll, Cambridge University Press, 1991, pages 60-74.