business requirement

What customer type you are?

One customer type focuses on current requirement, rightly built, with more flexibility towards the business requirements built-in in the database rather than in the code. They believe that if the software meets their current requirements well, the future requirements will be built in at the need of the hour. The reason for this is that nobody at the moment is sure about the future requirements and when the change will be required. The change could be required one day after the current implementation or after five years. The changes required could be insignificant, small or not so much effort consuming.

Another type of customer is who is more worried about tomorrow without focusing more on the current built. The future requirements which are not too clear at the moment, are guessed by the customer and forced to be built in the product without really understanding if these requirements will ever be used, or if the requirements built are correct as per future needs as nobody can define them correctly at the moment.

Probably if requirement handling is managed more at database level than in the code, it gives more flexibility to the product.

Ten facts (or myths) about developers and testers

We all know developers and testers both have a tough job all the time. Developers have a key role in developing the software as per customer requirements embedding customer’s business needs into it. Similarly testers have to put all their efforts in ensuring that the software is matching customer specifications flawlessly and is bugs free. In a nutshell both developers and testers have a common goal of ensuring a superior product delivery at customer end. If that is so why there is a never-ending tussle between testers and developers. Why developers feel testers are unnecessarily trying to poke their nose into their affair. Why testers feel that out all the bugs found out by them, most of the bugs would have been already handled by developers if they had done their job more seriously.
All this leads to certain questions about testers and developers which they only can reply to:
1. Testers are not supreme and so are developers. If developers can build so many bugs while writing the code, testers are also bound to leave certain loopholes in their testing. This is universal and never ending story.
2. Most of the testers around the world who test software do not understand very well the purpose behind the testing. They keep oscillating between their role as policing, controlling quality and excessive reporting.
3. Both developers and testers carry a single goal of ensuring good quality of software at the end of the day but still keep blaming each other for the shortfalls.
4. If developers are kept for writing code, it is well understood that they are being paid for writing good code and not bad code. Then why bugs at all? If a developer has been hired for coding, is it wrong at organization level to expect a 100% bug free coding from developers. If they are permitted to write code with bugs, why not every other function in the organization is allowed to perform their daily tasks with errors. Can’t we have perfect coders?
5. If testers find out the bugs, instead of being thankful to them, why developers start finding out reasons of cornering them. Developers are hurt when testers find out bugs in their code, and instead of going into a thanks mode for testers they start going into another mode where they themselves start losing their respect. In turn they start finding out weaknesses in tester’s capabilities, testing criteria or bug reporting process.
6. It is a well proven fact that while fixing reported bugs developers are bound to generate new bugs. Does it not make them circling them around the same product?
7. Testers sometimes have an understanding that if they report less bugs will mean a question mark on their job, which forces them to report many a times non-quality bugs thereby increasing gap between developer and tester.
8. Developers, once they know that the product has to undergo testing, write code so foolishly that they generate lot of unexpected bugs.
9. If testers are hired for finding out bugs, is it not their lack of depth of knowledge that leads to bug explosions at the later stages? Are testers involved in coding, or business study or implementation?
10. If developer’s after reading so many books on development write codes with bugs, I don’t think a good tester criteria should be if he has read a book on testing or not.

If you don’t change with the ‘Change’ you get [ex][change]d

In my June 15 2009 post – “Do’s (+) and Don’ts (X) in Project Management”  http://itknowledgeexchange.techtarget.co…), I got a query and am posting it here as it is - As mentioned by you in one of your post “Single constant in business is Change”. But often software vendors are too bound by the requirement documents that they fail to gauge the change in the underlying business need that they are trying to cater to. I understand that there are time and cost considerations, but many a times the attitude is not conducive. Could you throw some light on this in your writings…?

First of all let us be clear – we can not just record requirements and seal it. And then stay isolated from customer in building the software. One fine morning communicate to the customer that the product is ready and you are reaching customer site for product launch. If you feel that during the conceptualization, build and test phase customer has no role to play – you are wrong. If the customer thinks just by giving the requirements they will get a good product meeting all their expectations – customer is wrong. Both have to be in tune during the product development. If vendor fails to gauge the change in underlying business need that they are trying to cater to and think if they do so, it will increase their cost and time – again the vendor is wrong. By not doing so – they call for more time and cost. By not doing so – they surely call for more discrepancies, ambiguities, delays and failures. A small investment of time and cost during the build phase to involve customer and take his consent at every step will definitely lead to later on investments, time delays etc.

If attitude is not conducive, it has to be. Customer has to realize that. And customer has to realize the importance of getting involved in each phase of the project rather than assuming that it is vendor’s call and everything will go fine.

The requirements keep changing, as the business. Only thing that varies is the pace of change in requirements. Overlooking changes happening in the business process at customer end after freezing requirements will result only in undesirable product. Both customer and vendor have to understand this and keep overseeing the changes rather than overlooking.

If changes are not recorded and incorporated in time, customer is always going to blame the vendor and may be vendor gets exchanged with another vendor for the same project.

5 reasons of top level customer expectations missing in requirement study document

As stated in previous two blogs, top level expectations gathering is very crucial during the business study and requirement gathering phase. And respectively I mentioned how vendor and customer can be careful (and should be) about that. Although it is rare and unexpected, but there are instances where customer organization top level management may not involve in a new software development project. This could have various reasons but could lead to only a single road – where the end is DISASTER. If this so happens, the chances of project getting hurt are manifold. It will precisely and ultimately lead to project failure. The reasons could be many, but to my mind following come at the top:

1. Customer Top management presumes that their involvement requirement is only for signing agreements, papers, reviews and sign-offs. If that so, they will have almost negligible awareness that how critical it is for them to get their expectations and requirements (top level) during requirement study phase. After all it is an investment of time, resources and money. Instead of getting a jolt at a final stage about getting the unexpected or not getting the expected, it is better to explain right in the beginning their own requirements and expectations from the product in detail.

2. Vendor’s management role is very crucial during this phase. They have to take initiative in explaining the top management about the benefits of the product being proposed. How it is going to enhance the processes in the organization, the change in roles etc.

3. Assume a situation where there is a pressure from user level for a solution or a product at customer end. The management is not sure about the product. Without horizontally analyzing various solutions available, they decide to go for a particular vendor or product just for the sake for fulfilling requirement. Although it will be rare, but even it is there at a very low intensity, it need to be addressed.

4. Customer top level assumes that the solution being invested into is meant only for user level and not organization level. This is a wrong assumption. Any investment – small or large- has to have benefits for the organization and top management on the cards.

5. Customer top management overestimates their users and assume that they will be able to drive the project without top management’s involvement. This does happen but very rarely, in very organized structures.