Recommended Read: Consequences of the Easy Way Out

One issue in project management that I encounter is this: There's no time for requirements gathering meetings. Lately, there's a project where the customer was complaining about my persistence to do "proper" requirement gathering. We were spending too much time to discuss requirements, working from high level workflow, drilling into details like screen design, exception handling, validations etc. Each meeting, there were issues, disagreements. Indeed, it was tedious.

Sometimes, I also wonder if I am just wasting everyone's time. Should I just take the easy way out and go ahead with development, without satisfying myself that requirments gathering is complete?

Reading this article, I am reminded that taking the easy way out is not the best way out. Great results does not come about by taking the path of least resistance. It is achieved by taking the efforts to getting our fundamentals right. I am reminded of all the things that can go wrong in a software project with incomplete requirements, with all too much assumptions; these translates into error discovered late, costly rework, and frustrations.

Is it worth the effort? All these tedious work? I believe so. But only time will tell. The road is still long... long...

Listening to Your Clients

This article talks about the importance of sales people listening to their clients, so that they can value-add by playing a consultative role to their clients' issues.

I say that this is does not only applies to sales people, but also to IT people as well. Being in software project management, I was very surprise when some project managers say that they don't want to face clients. How can we understand what clients want when you don't interact with them? And if you don't understand what the client's want, then how do you satisify their needs?

I believe in the importance of understanding clients' needs. Understanding requirements does not only mean writing down the requirements as spoken by clients. It also means reading between their lines and understanding the underlying business objectives that they are trying to achieve. So very often, I see clients mandating certain ways of implementation, thinking that its the cheapest/best way to get things done; not understanding the potential repercussion in the longer term. That's when PMs must also put on their consultant caps and advise their clients.

I am not saying this is easy. In fact, this is a great challenge and takes strong communication skills. It takes patience and time. Next complain I often hear is this: we have no time, we must get this system up and running fast! It's an oxymoron; How can you get a running system when you don't even have time to communicate what the system is suppose to achieve? It takes moral courage and good communication skills again to make clients understand that by slowing down first to think and communicate, we are in fact speeding things up.

Research shows that 50% of software rework comes for wrong requirements. Things that can be corrected early in the SDLC, with good requirements gathering and management. I hope more PMs see what I saying here; or I really have to pity the development teams struggling with unneccessary pressures caused by poor listening skills.