Re: Idle thoughts on software project-management

[bellaire]

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.

[cavac]

Write technical documentation as well as some for the managment and customer
This can't be empasized enough: You will have to deal with (at least) three different groups:


• The technical group needs specific instructions. What is required, how is the software required to do it, the exact message-by-message, byte-by-byte specification of any required communication with other systems
• Your own managment needs an overview of how long it will take, how much it will cost in man-hours, any required external resource (servers, services, ...). Managers do not want to wade through technical specs. They do want to know however if they will be able to afford a new car or get sued by $other_company.
• Your (internal or external) customer wants one document from you: The ability to RTFM. This manual should have nice pictures, easy-to-understand "if you want to x enter y in there and click z" paragraphs. Please avoid technical explanations like "The driver hooks into the kernel by patching the system call table"...
If possible, write as much of the documentation as possible before starting to code. Let the customer and managment review it. While your software may still fall short of the customers expectations in the end, this will minimize the risk.

[sundialsvc4]

With regard to the above, one thing that I am seeing more and more is ... the fundamental value of classical project management practices.   People who are not experts in a particular field of expertise (be it computer-programming or plumbing) might know what they want to achieve but not how to say it; nor how to judge it.   They have money to spend but don’t know the prudent way to spend it.   They are always accountable to someone else (ad infinitum, right on up the line...) for the money and for the trust that they have vested in you and in your project plan.   We all have a natural aversion to “paperwork,” until we witness for ourselves the extreme value of it.   And, I think that we all like to think that our particular endeavors play by a different set of rules.   (We are constantly inventing a new set of industry-specific buzzwords and silver bullets.)   More often than not, though the practices that have been applied for a very long time in many other, seemingly unrelated disciplines, do apply very well to what we are doing for our daily bread.   It has been said, “if you want to find something new, look to the old.”   And I am finding that to be truth.