Collective Wisdom from the Experts 21
Not realizing we would have to be miracle workers to make this oversized
content display on a single screen, the end-user customer got very upset. They
blamed our prime contractor, the design shop. In return, the design shop
refused to pay us. According to them, we “did not meet the requirements as
written.”
From that experience, I have learned the danger of poorly constructed, writ-
ten requirements and how they can be used against you. It is important to
always document your assumptions and insist on reviewing and signing off on
requirements with the end-user, not just with a middleman.
Fortunately, agile project management practices have alleviated some of these
issues. By recognizing the importance of nose-to-nose interfaces between the
developer and the real customer, we have evolved to collectively creating User
Stories, and prioritizing features based on the business value they will provide
to the customer, rather than requirements lists. A one- or two-week iteration
process means we have early and frequent feedback, and the opportunity to
clarify customer expectations.
Twelve years later, I have run into almost exactly the same situation with a
client who is highly concerned about vertical scrolling, even though he wants
large amounts of content on the page. Luckily, with the way we run projects
today and the lessons I learned from my past experience, we resolved this issue
quickly and set realistic customer expectations without the chaos of the past.