In part.1 we described the situation as building a plane in the air, and mentioned some of the challenges we always face. Here we going to discuss some of these challenges in details:

Requirements are not clear.

Always happening, customer usually has a problem and usually does not know the root cause of it. In best cases customer can has a vision with defined objectives. When you meet customer stakeholders, everyone of them has a different story to tell, everyone has a different expectation. And you are trying hard to listen to all of them to form your own vision, or a common vision that can meet most of stakeholder’s requirements.

Requirements always changing.

Remember when we said in part.1 that:

” The best ever written requirement document represents only 80% of customer vision”

When you form your vision that you think is the most close to everybody’s vision and then start to develop the requirements, customer will continually gives you feedback  and ask for enhancements.

This is normal, Customer can’t judge the system without seeing it at work.

As a development team we have to consider that and accept it as a fact an axiom in software development domain. Resisting it will result in project failure.

Project is out of budget and time.

This is a logical result of requirements being changed all the time. Although the customer himself never stops asking for new requirements, but after a while he gets bored of the project, and sometimes he loses his enthusiasm and motivation and may cancel the contract.

Happened to me many times 🙂

No time for test.

If the project reached that situation, where requirements are not managed anymore, and project is out of schedule and budget, and customer is complaining, Development team usually sacrifices wit the testing time to deliver and get paid…

You can imaging what would happen next.

Time is spent on Junk.

An academic study in 2003 mentioned that

“53% of project requirements usually be cancelled as stakeholders found that these requirements are not of much value for the project, or the situation itself has been changed where they don’t need these requirements anymore”

“64% of requirements built are not used, and in best cases they use once a year”

On the personal level, i once had a project where we were developing a campus management system for a college. we build more than 120 reports according to the customer requirements. After we finished, and while we were monitoring the system at work, we found that only 10 reports are being used periodically, and more than 50 reports have never been used all over 6 years.

So,,, what shall we do ?!

In the next blog, i will follow with you best practices and learned lessons.

follow the blog to get it on time.