Having worked as a process manager and tech writer in software development for over 10 years, I ran into the problems covered in Five common errors in requirements analysis.
Problem 1: Customers Don’t Know What They Want
This is often true because much of development has to do with technology that’s beyond the customer’s knowledge. In terms of Web design, understanding the customer’s mission, vision, goals, and other important parts of the project. In software development — especially large and complex software with many interfaces — requirements don’t always affect customers. Requirements often focus on the back-end, processing and system interfaces. This is over marketing’s head.
What works is sending an email (BEFORE requirements discussions begin) to one contact from each major group that has ever been affected by the software. The contacts reply whether or not they need to be involved in the project. If they do, then they should attend the requirements meetings. What about the problem of having too many people in the meetings? That’s where having one contact helps. That contact should be communicating with the group.
Problem 2: Requirements Change During the Project
Always. I don’t think I can recall a project where this didn’t happen. Even for this little Web site. Anyone involved in development should have a change request process in place, even a one-person business. Accept that there will be changes and prepare a change request when this happens. Show the customer how it affects the milestones and get sign off. Another way is to have a phase 1 or soft launch and then add the new requirements for phase 2.
Problem 3: Timeline Trouble
I worked on a project that was supposed to launch in July 2006. Still working on it. The customer accepts responsibility for the delay. Be realistic. Map out the timeline based on an analysis of the requirements. If it’s tight leaving no room for error or impossible — communicate this. Which would you rather have? No client because you said the timeline wasn’t doable or having a client and missing deadlines that could hurt a company’s reputation?
Problem 4: Communication Gaps
This is a simple thing that shouldn’t happen, but it does. A software update impacted a group that was left out of requirements. As a result, it cost more to fix it later in the project. 37signals’ Basecamp or a similar tool is a great way to record all communications between customer and designer. Basecamp is a web-based application that sends emails to affected parties along with a link to the message for replying. At the least, have one assigned point of contact for the customer and for the Web design firm. Ensure that contact is a reliable person and can do the job. No company wants to assign a contact whose answers will mostly be, “I don’t know.” It’s OK not to have all the answers as you have a team to work with. The person should understand what goes on and respond appropriately.
Problem 5: Customer Organization Politics
Making Process Improvement Work: A Concise Action Guide for Software Managers and PractitionersThis is a difficult problem to overcome with diversity of variables that can get in the way. One way is to communicate in terms of what’s in it for the other person rather than your firm or someone else in your client’s company. I haven’t discovered any miracle solutions for overcoming politics.
I wish I could recommend one book for everything process-related, but none stood out for me. Making Process Improvement Work is an easy book to read and not as technical or overwhelming as some others. It references CMM, but is still valuable for organizations not using CMM.
What has worked for you?