By Greg Johnson

If we built houses instead of technology solutions, would your project sound like this?

Dear Mr. Architect,

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion based on what works for other people.

My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or removed.

As you design, also keep in mind that I want to go green as much as possible. This should mean the incorporation of sustainable, earth friendly materials. (If you choose not to use hemp in the insulation, be prepared to explain your decision in detail.)

I’m sure I can trust your expertise and professionalism. Be alerted, however, that the kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To ensure that you are building the correct house for our entire family, make sure that you contact each of our children and also our in-laws. My mother-in-law will have strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house—get the big picture?

Also, do not worry about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans however, I would expect the blueprint delivered within a week.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. Therefore, it should appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features of this house. Oh, and the turret shaped corner on the front is a must have!

I advise you to look at my neighbor’s house constructed last year. We like it a great deal. It has many features that we would like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on an interesting project like this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your complete ideas and plans.

PS: My wife has just told me that she disagrees with many of the instructions I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Maintenance free is the way to go. i.e., why should I have to turn “on” the dishwasher? Shouldn’t it know when it’s full?

————————————————–——————————–——————————–——————————

Yes, Mr. Architect should run; not walk away from this one but we don’t always have that option, do we? Many of us only have the one customer, so we have to find a way to elicit our requirements in a way that makes the project successful.

Elicit isn’t a common word, but it’s important to use because we are talking about going beyond mere requirements “gathering”. If we only gathered the requirements we would take what is given at face value and start building something. In order to elicit, we must go further to reach a common understanding with the customer that sets the expectations in a documented way.

Start with People

Starting with where this project is coming from, you probably know who your customer is. From there you can identify the stakeholders by asking who is it for, who is affected by it, who will use it, who’s in charge of it and who needs to know about it. You will want to set up interviews with those key stakeholders who have information you need, or have authority to make decisions for others. Interviewing also gives you a chance to identify conflicting ideas and set reasonable technical expectations. Another good idea is to get the stakeholders together for a brainstorming session. This process is a science of its own but the goal is to narrow things down so that everyone is more or less on the same page going forward.

Use Cases

Once you have your input from all the stakeholders, it’s a good idea to walk through the process by documenting informal use cases. Make sure you encourage your stakeholders not to get too caught up in the technology at this point, but to write down each case like a story. Getting people to think about a use case helps flesh out other requirements and refines the business process.

Prototyping

Most technology projects are severely lacking in this area and that’s too bad because it really helps nail down requirements. I suppose it’s because customers don’t want to pay for it and developers don’t want to spend time on something that’s just going to get scrapped later. As a developer, I admit I’m not too keen on it either but consider this—when you have a customer that doesn’t know what they want, this helps them get there. They may need to use the new software (with its associated process changes) before they discover additional valuable functionality and features. If the software itself isn’t available, just mocking up some screen shots might be adequate. Prototyping also helps identify those oversights the customer didn’t include so that they don’t turn up in UAT.  You’ve never had that happen, have you?

Assessing Feasibility

This is a two-pronged review process, which involves both customer and developer.  The customer’s task is to review the business process to make sure the requirements will meet the business goals. At this point it may be useful for them to review their business plan, market analysis, and other documents to determine if this project fits within that framework.

The developer looks at the project’s requirements to see if it’s feasible based on the technology available. It may be necessary to pull in other products or people and make the customer aware of this so they can let go of certain requirements if the cost is too high.

Documentation

Once your requirements are all pulled together, it’s time to write them all down for all to review and ponder. The main purpose of requirements documentation is so that everyone knows what to expect going forward. You and the customer will probably find yourselves referring back to them as the project moves along, so take the time to be thorough and clear. From your perspective, you want to minimize scope creep. If you think of anything that you’re not sure needs to be written down, write it down anyway. Sometimes it’s helpful to also include what things are NOT included so that it can be there for reference later.

Now that you have elicited your requirements, take a step back and reflect on what you’ve accomplished. Do you feel good about it? If so you have laid the foundation for a smart and successful project!