- TrIpLeZoNe -

Last thursday during the SgDotNet User Group meeting, I mentioned a few things during the "Change Management" discussion which I'd like to share with everyone.

Everyone knows how difficult project management is. Talking to the clients/customers and getting requirements (or simply digging out what they want out) of an application they want requires so much time and effort. Through my experiences doing freelance projects and handling teams and managing project schedules, here's a few steps I try to keep and follow when dealing with clients.

1. Clients never know what they want.
2. Research in the domain of the application that your client wants you to create.
3. Based on this research, put yourself in your clients shoes and decide for the clients what they want.
4. Model your application specifications based on those decisions.
5. Let the client verify, change, and vet.

The keypoint here is that you have to research on the domain of the application you intend to do. You don't need to be the master of that domain, but know what problem you're trying to solve, or what processes you're trying to make simplier. And you DO need to always remember to put yourself in your client's shoes, and try to understand what they actually want, and the rationale in that.

Every feature you add MUST contribute to either solving a problem, or process, or have business value. For every feature, always question yourself "What value does this feature give in terms of business value, solving the problem, or simplifying the process?" If it does not contribute in any way, it's not a feature (need or necessity) but a decorator (want).

Based on experiences, the basic rule to remember is that clients will never be able to know what they want in the application. They roughly know what they need, but they don't really know how to translate that into an application. The less IT savvy they are, the worse they don't know how to translate what they want into an application that helps them.

And you must always remember, an application HELPS with the business processes, or whatever processes it's supposed to do, OR it SOLVES a business problem. It must not be able to make a current process or problem even harder to do.

Let me share with you something I learnt way back in secondary school, by this literature teacher of mine.

• Need
• Want

What are the differences between these 2 words? A "need" is a necessity that you have to have in order for something to function, and a "want" is something you don't really need to have in order to function, but something that is good to have. You must identify your feature sets carefully based on these decisions, as mentioned above.

I hope this helps in making your project/program management easier on all of your developers, hopefully reducing the changes made to the application by actually getting requirements that your client really needs.