Jan 14 2009 10:10AM GMT
Posted by: Jaideep
SDLC,
business management,
Bug Management,
CRD,
Customer Requirements Document,
team management,
customer requirements
Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management
Oct 20 2008 10:30AM GMT
Posted by: Jaideep
Project Management,
SDLC,
Project Lifecycle,
Customer Requirements Document,
software requirement
This is in continuation of my previous blog where I listed the 10 most important must-dos for customer to have clear software requirements in first go. Ten most important must-dos for vendor to have clear software requirements according to me would be:
Vendor End:
1. Understand that an unclear or incomplete software requirement is never going to build good software.
2. Ensure that management selects the right person(s) for the purpose.
3. Ensure that management at back office is continuously involved in the whole process as per plan.
4. Ensure that customer management is clear in their goals to be achieved by this software.
5. Ensure that customer has identified the right people who are actually the process owners and not the subordinates of the process owners.
6. Do not hesitate in analyzing the each sub process station.
7. Ensure that analyst gets process owner’s ample time to document each and every process requirement well.
8. Don’t trust on your mind. Document along with the understanding of the process or soon after it. Keep getting it vetted by the process owners.
9. Keep updating customer management after the finish of each process.
10. Don’t compromise with time and documentation.
Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if! Any!!).
Oct 17 2008 11:22AM GMT
Posted by: Jaideep
Project Management,
SDLC,
Project Lifecycle,
Customer Requirements Document,
software requirement
Having clear software requirements is very important as it is going to be the foundation of the software to-be-built. Having clear software requirements in first go is equally important especially in case of overseas client. Few things are very well known to all:
1. Face to face interaction brings out more clarity as compared to any other mode of communication.
2. Documents collected and prepared are the vital asset of software requirements.
3. Selection of right person for the customer/software requirements study is very crucial (and sometimes it hurts at a very late stage)
4. Travel and time is a cost that is affecting the overall Project Cost, Margins and Profits - irrespective of whether customer or vendor is bearing it in the beginning.
Keeping all this in mind, the 10 must-do to have clear software requirements in first go, which I am listing below. There could be many more (which I would like to be added in the comments section), but these come to my mind as most important:
Customer End:
1. Ensure that management knows the purpose of the project
2. Ensure that management is continuously involved in whole process.
3. Ensure that the vendor representative(s) coming for the purpose is the right person(s). They should not only be the master of their domain but should have fairly good number of years of business exposure too.
4. Ensure that the process owners are the right persons to explain the process.
5. Ensure that the process owners have their process charts ready with them, the document is going to help really.
6. Ensure that the processes are sequenced in proper fashion.
7. Ensure that the time should not be the constraint for process owners. Devoting 6-8 hours for 2 days is always better than devoting 2 hours per day for 10 days. After all more time spent by the vendor representative is equal to more cost to the customer (overall project cost).
8. Ensure that the analysts (vendor representatives) keep updating their documents during the understanding of process or at the finish of a process. Let not a lot remain in the mind and be documented later.
9. Ensure that both the managements (vendor and customer) finally sign the document finally prepared (both have equal ownership on whatever has been documented).
10. Do not get bogged down by the size or volume of the document. Let it is as elaborative and explanatory as possible. Just be sure that it is crisp and to-the-point. Attach hand written papers, reports, formats, legacy manual with specific markings of important features required to be built in the new software.
Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if!). A similar set of guidelines for the vendor end, I would be posting in my next blog.
Oct 15 2008 10:34AM GMT
Posted by: Jaideep
Project Management,
Quality Assurance,
SDLC,
Project Lifecycle,
STLC,
Bug Management,
CRD,
Customer Requirements Document,
software requirement
Broadly there are two main loopholes in case of unclear software requirements – vendor and customer. Unclear Software Requirements could lead to disaster not only for the vendor but for customer also as I stated in my previous blog. To vendor it may cost money, time, reputation, business and at worst the closure of business. To customer it costs time, money, employees trust in its management, management confidence in selecting a vendor and at worst a decision to not to streamline their business in terms of a new software.
The main reasons of unclear software requirements could be:-
(Vendor Part):
The vendor representative deputed for studying software requirements is inexperienced in terms of customer business
The vendor representative’s tenure is too short at customer site to study its business and requirements
The vendor representative is not curious enough to dig down each process at customer site
The vendor representative being poor at documentation
The vendor representative thinks collection of relevant forms and reports is a waste
The vendor representative keeps more in his mind than documenting (the business rules, processes and requirements)
(Customer Part):
No clear cut representative(s) identified
Business clarity is delivered by the person other than actual process owner
Process owners too occupied
Process owners depute their subordinates and perceive they will explain the correct picture
Management before signing the final documents do not vet each process and business rule
Poor management’s involvement
Wrong perception that vendor will build a strong software that will meet all their requirements on its own
Oct 10 2008 10:56AM GMT
Posted by: Jaideep
Project Management,
SDLC,
Project Lifecycle,
CRD,
Customer Requirements Document
In normal scenario when an order is finalized between a vendor and a customer, for building new software by the vendor, the payment terms are set in such a manner that some percentage of the project cost is paid soon after the completion of customer requirements study, generally on finalization and submission of customer requirements document (CRD) by the vendor to the customer. The completion of this phase shows that the vendor has clearly understood the customer and business requirements and is capable enough to build all those requirements in the software product that he is going to build for the customer.
Customer’s ultimate goal is to acquire or purchase the final product that fully meets its functional and business requirements. Then why customer should pay out of his pocket for something at a stage that is of no use to the customer. The requirement study is the need of vendor and not the customer. Customer finally needs a product.
What if the product built is incapable of meeting customer’s requirements. Then why not customer pays to vendor just once at the time of product delivery, User Acceptance and implementation completion?
Do we buy a complete car or pay in parts – for steering, for body, for brakes, for seats, for belts… and so on…
Just a thought…
