The real work on a project begins before you lay down the first stitch of code—with analyzing the current system, sketching out what the new systems should look like, and capturing business requirements. In short, it all starts with analysis and design.

Depending on the specific methodology you are using (you are using a methodology, aren’t you?), analysis and design tasks will occur at various points in the development life cycle. However, regardless of the approach, your efforts will eventually bring you face-to-face with business issues and the people who own them (in programmer talk, that would be the users). Furthermore, depending on the size of the project, getting the information you need can be a big challenge.

Throughout my professional career, I‘ve spent a tremendous amount of time with users, capturing business requirements, generally trying to understand their needs, and trying to effect a solution. From this experience—and one project in particular—I’ve defined my approach and compiled tips for facilitating design sessions between developers and users. While the project I refer to was fairly large (over two years and several million dollars), the pointers presented here will help you in any size project, including those that involve just you and a single user.

Before you begin
Before you ever get in front of the user, you’re responsible for a few basic things:

  • Preparation: Everyone’s time is valuable (including yours), so don’t waste it.
  • Do your homework: Do as much research about the system as possible before meeting the user. This will allow you to ask better questions, save time, and look more professional.
  • Prepare material: Invest the time to prepare handouts, drawings, flipcharts, and whatever else is necessary to present your information.
  • Know your objective: It’s hard to get somewhere if you don’t know where you’re going. Determine the goal of the overall project and decide what you hope to get out of each session with your user. Objectives may change over time, but you have to start with something.
  • Have the right parties present: Have you identified the right users or subject matter experts (SMEs)? Should other developers be invited because of their knowledge of key systems?

The process
For the large project I was involved in, the meetings were held with members of the development team representing the three main functional aspects of the project, the project manager, several consultants, the SMEs, and a couple of managers. The meetings were scheduled to last all day (8:00 A.M. to about 4:30 P.M.) and ran from Monday through Friday. (Friday ended earlier so the out-of-town users could catch flights home).

Other than some introductory activities, the events followed a simple format:

  1. Present the current system.
  2. Present the proposed system.
  3. Capture feedback and requirements.

The process was applied to each reasonably sized component of the system.

This is vastly oversimplified, but designs were shown, tested, and challenged in the presence of the user representatives. Many times, the users corrected our understanding of the current system and found problems in our future designs.

The developer’s job is never done
Did I say something about the day ending at 4:30 P.M.? I meant the meeting ended then. That’s when the real analysis and design work began. We incorporated the various bits of knowledge captured during the meeting into the presentations. We corrected designs of the current system and changed new system designs. We also began the detective work necessary to find answers to any questions that may have arisen during the meeting.

The following day, we followed the same process: Evaluate where we think we are; decide what we’d like to do; capture the user feedback. Again, we repeated this for each part of the system. After a week of this process, the development team had a huge amount of exactly the type of information it needed.

The rest of the ingredients
Here are some additional pointers for conducting a successful analysis and design session. Again, the beauty of this recipe is that it can be applied to the largest of projects or to the simplest.

  • Control the time. If it is a scheduled meeting, start on time and end on time. It shows you are professional and serious about the meeting.
  • Use pictures. Pictures truly are worth a thousand words. Use flowcharts, diagrams, or whatever it takes to help users understand whatever you’re trying to convey.
  • Use flipcharts. Draw schematics in advance. Make changes, corrections, and enhancements right on the flipchart. Save the charts for later transcription and reference.
  • Post the flipcharts around the room. Masking tape is a great invention; use it. Plaster the charts around the room wherever there’s space. Everyone should be able to reference them as the ideas unfold.
  • Have a parking lot. Before the session starts, post sheets of flipchart paper on the wall to capture ideas that are off the track for the current topic. Label each sheet “parking lot.”
  • Float ideas in real time. As suggestions come up, reflect them on the flipcharts. This will test your understanding of what was meant and enable those offering ideas to better visualize their thoughts and correct them on the spot.
  • Come prepared. Don’t waste people’s time. Have diagrams ready; have your ideas and questions ready.
  • Bring toys. Yes, toys. Nerf balls, squirt guns—anything to relieve stress. People can’t be creative when they want to wring your neck.
  • Designate a scribe. It’s difficult, if not impossible, to present information about a design, critically listen to another’s ideas, and take notes at the same time. Designate someone to take notes, preferably on a laptop to avoid later transcription.
  • Keep the group together. If they leave for lunch, you may never see them again, or least not in a timely fashion. Have lunch brought in so you don’t have to wait for people to return.
Tell about your experience

What have you done to make your analysis and design sessions a success? Have you found anything that should be avoided during these meetings? Send us an e-mail with your ideas and experiences.