in reply to Idle thoughts on software project-management
With emphasis on the small team (4 of us here) serving the semi-technical group (internal systems for a university IT division)...
Listen carefully...
Customers ask for lots of things, knowing they won't all get done. They don't really understand the effort differential involved... but they do know what's going to save them effort. Your job is to extract that information from them. I recently did a job in a day that a customer told me would save him hundreds of hours of effort per year. He didn't understand that the ROI on what he wanted was so great because he didn't know that it was so easy to implement. Ask questions, figure out where the cost savings are, and target those aggressively.
Be able to say "No..."
Especially when you're salaried and you dont make money per-job, it's easy to just say "Yes" to anything and everything anyone asks for... But that doesn't get you much. You'll start breaking promises and you won't make a good impression. Instead, try to talk to them in their own language about priorities. Explain that they can have X or Y in 4 months, but not both. Usually they understand that they can't have it all and will be able to help you to say "Yes" to the right projects.
Be prepared to pivot...
The XY problem can easily manifest itself in customer-programmer relations. When the above rules fail, you can find yourself implementing a system that just misses what the customer actually wants. By keeping in contact with stakeholders early and often, you can detect when this happens and change your approach accordingly, with a minimum of waste. Some waste may be inevitable... chances are sometimes you and your customers don't speak the same language, and they don't understand that you're solving the wrong problem until you can show them a prototype. So... do the prototype. Do the minimal work that will illustrate your solution, show it off, and be prepared to abandon it if you're off the mark. And do it as early as possible.