It is almost always a good idea to solicit feedback from others in the organization about their needs before starting down the road of selecting project management software. I'll explain why this is important, how to do it, and add some words of caution.
Why is it important? Three reasons. First, you will not be the only person using the system. Other people in the organization will be using the system as well. What do they need and even like? Two, you have your own objectives, but others in the organization may have a different outlook and may have objectives of their own that are equally important. Three, it will help your implementation. How? They will feel like they were consulted, and may even feel some ownership with the project. You will need their support during the implementation.
There are various methods of soliciting feedback, some formal and others more informal. Formal methods including asking them to formally submit requirements from their group, or conducting a meeting to collect feedback. I find informal methods, in general, to work the best. This is because it is the one-on-one interaction, the trust developed between you and other parties, that makes the biggest difference. Informal methods include going out to lunch with someone, chatting in the office, and asking their opinion informally. For example, I may go out to lunch with another manager and say "Hey, we're looking into selecting project management software to do x, y, and z. What would be some things that you would like to see that would benefit your group?" Or "what problems do you need solved?" This then becomes one of those situations where listening is better than talking.
The scope, size, and complexity of the project will determine how formal you need to get. A large organization will need to employ more formal feedback mechanisms, such as those that are a precursor to a formal RFP process, whereas a small or mid-size organization can be much more informal.
The types of feedback you need are problems that people are experiencing, what tools they are using now, and what they are trying to accomplish. Features are nice, but if you can solve a problem, so much the better. If you can solve a problem and help them accomplish a key objective, that is better still. It is good to understand what tools they are currently using as that will help you ascertain what type of system to employ: one that is more complicated, or one that is more middle-of-the-road.
I promised some words of caution. You need to solicit feedback from the right scope of people. Do not solicit feedback from everyone. Where are you going to implement this? Within your group? Across the department? Across the whole organization? Do not tread much outside of that target group of people. Otherwise you run the risk of diluting your requirements unnecessarily or causing your selection project to get much more complex than it has to because someone else wants to be involved in it. If you are not sure where you are going to implement it, ask yourself where you have buy-in from management. That is probably where you want to target, at least initially.
You also want to be careful what you do with the feedback you receive. You may have to run it through the "strategic objectives and true business value filter". People love to throw out features and wish lists, some which are good, some which have no real business value or necessity. But you will find key nuggets of information that can make a big difference in your selection and implementation.
Finally, you can solicit feedback ad nauseam, and never actually get to selecting anything. Don't take it too far. Get the feedback that you can in a reasonable time frame, then take action.
The bottom line, feedback almost always reveals things you did not consider, develops relationships, and helps your organization in the long-run.
