What the heck are technical requirements and how do I get some?

So, you want to build a website or an application, and some tech/geek is at your door asking for technical requirements. What do you do?

Don’t panic.

A project manager with strong technical skills could help you navigate the task, but just in case you find yourself in a newfound project manager role, here are four tips:

1. Keep an eye on the prize
The key to getting the technical requirements right is to focus on your project goals first.

Clearly identify what your outcomes should be and get feedback from your stakeholders. If you don’t know what your goals or outcomes should be, your project will be all over the place and it will have a hard time getting off the ground.

Identifying your goals upfront — simply and concisely —will help the entire team (techies alike) focus on one prize instead of many small, unclear ones.

Your goal should drive the requirements, not the other way around.

2. It takes a village to build an application
Talk to people, but more importantly, listen to them. Getting input from various sources will only make your project better.

Yes, it is easier to build or design in a vacuum, but the project will probably have issues. If you have experts hanging around, ask them. The folks in the next cubicle can be great resources for generating ideas.

Don’t forget about techies. As you go along, make sure you bounce ideas off those with the skills to build the product— they have great ideas and can help guide you to the best solutions.

Most importantly, talk to the people who will be using the site or tool you are creating. Watch how they currently manage the process and work to identify areas for efficiencies. Don’t forget to take lots of notes!

Keep in mind that you want to make their job easier, not harder. If you don’t communicate with the potential users, you may end up doing just that.

3. Draw pictures
No need to panic if you are not artistic — think stick figures. Using images will help those you are trying to communicate with understanding what you are telling them.

Images tend to be more helpful than words and hand gestures. If you are brainstorming in a meeting room, use the whiteboard. If it is an impromptu chat, scratch it out on a napkin. Keep copies of your sketches for use later.

4. Write up the requirements
That may sound daunting, but it is not. If you have done the previous steps, drafting the requirements is the easy part.

Pore over your notes and sketches, and compile a list of all of the suggestions and ideas you gathered. Some of these ideas will conflict and that’s OK.

Compare each item on your list against the goals you set. Do they align with and support the desired outcome? If your answer is yes, keep them on the list. If the answer is no, toss them.

This process usually takes care of conflicts naturally. When it doesn’t, talk to your users and stakeholders to get more clarity on an item. This additional research will help you make a decision about what should stay and what should go.

Once you have your list, communicate clearly to your stakeholders and to the IT crowd — send them a copy of what you have compiled and let them chew on it a bit.

Inevitably, there will be changes (expect them all along the way), but I guarantee that you have worked through some of the bugs and questions that would have slowed your development down.