End User archives - Quality Assurance and Project Management

Quality Assurance and Project Management:

end user

Aug 7 2009   10:00AM GMT

Ten Mantras for a software developer



Posted by: Jaideep
Software developer, software development, Application development, Software application, software testing, bug-free, Bug, software, application, bug identification, application building, code writing, application performance, business requirements, Business Rules, code validation, business process, process owner, end user, collaboration, tester, application functionality, software functionality, software performance, quality, customer experience, software build, bug fixing

Lot of efforts can be saved in terms of time and money if we reach to a stage of ‘first time right’ in application development. It has been proven largely that no good application can be built and released without extensive testing. Testing is not developers’ ball game – this is also a well proven fact. Reasons are many as far as it is concerned that why developers can’t build a bug-free application, or why can’t they test on their own. We are not going to discuss those reasons here. Focus here would be on what developers should keep in mind while building an application that it requires minimum efforts and time in all testing stages. As we all know the cost of bug fixing goes manifold, depending on how much distance (in terms of time and project stages) it has covered after development for bug identification. The bugs identified at a later stage, say during UAT cost more significantly as compared to the bug identified by the developer himself immediately after writing a code. Few qualities if a developer acquires and keeps in his mind while writing codes would not only benefit him but the organization he is working for and their customer also for whom the product is being built.

1. Commitment to application performance should be kept in mind while writing a code.
2. Clarity of business requirements and rules/ validations that are being translated into the application with real aptitude of business and not a developer. Don’t imagine and build. If there is some lack in clarity – discuss, record and build.
3. Treat yourself as the business process owner and end user – and build the application accordingly as if you have to use it. Don’t think yourself as a bartender, think as if you are preparing the drink for yourself.
4. Collaborate and build – rather than building in isolation- collaborate with other developers working on the application, the end user, and the testers.
5. Optimize your code – don’t just write it. There are n numbers of optimizers almost in all technologies. Use them and build a strong application in terms of functionality and performance. Be quality focused. Don’t do efforts that call for more efforts later.
6. Be focused. Don’t work on various applications development at the same time unless it is too mission critical.
7. Gain customer experience after launch of your application. It will certainly help you in your future builds. Build a customer satisfaction metrics.
8. Don’t take short cuts in fixing bugs – whatever stage they are identified. That way you will build more bugs while fixing identified bugs.
9. Work like a champion. There is a difference between playing a shot and playing an accurate shot.
10. Be loyal to yourself, your organization and your work.

May 27 2009   10:00AM GMT

Post Implementation Review – Why required?



Posted by: Jaideep
post implementation review, Project Management, project implementation, Software Project, implementation team, end user, project training, project knowledge, project lerning, software features, software functionality, software performance

A successful implementation does not ensure the completion of project. The reality starts when the implementation team has gone back and users have started using the project in full swing with the help of training material, learning, knowledge and product. The health of users in respect of using the product is sustained, deteriorated, or improved will depend on many factors. A post implementation review is always important to understand the users understanding, pains and delights during this tenure. This will translate further into management’s pains and delights. The overall delight weightage has to be higher than the pain. In a blow of project implementation phase users might feel quite confident regarding the product features, functionality and ease. When the whole thing falls upon them, it usually drive them in confusion, wrong actions or stoppages. Or a smooth drive.

A post implementation survey will help in a real measurement on two fronts. One front will be users’ understanding, ease and comfort (or vice versa). Second front will be product’s stability, performance and functionality. It also will assess the after effects of a successful project implementation.

The conclusions could be misleading although and will require a deep analysis. A user’s lack of understanding may spell into products inefficiency or the opposite of it.


May 18 2009   10:00AM GMT

Vendor’s role in involving customer top management while requirement gathering phase



Posted by: Jaideep
Software vendor, Project Management, Software Project, Software Project Lifecycle, business study, requirement gathering, customer, customer expectations, software product, top management, project stakeholders, process owner, end user, software development, project completion, user level requirement, top level requirement

The most critical stage in software project lifecycle is business study and requirement gathering. Vendor has to be very cautious and careful in understanding all levels expectations from the product they are going to build for the customer. Skipping top level at this stage could be disastrous for both. As a vendor, if you don’t involve customer top management while gathering requirements – you are inviting a mishap!

Customer top Management involvement is very critical during the business study and requirement gathering phase of a software project. The expectations of top management shall invariably be different as compared to other stakeholders of the software project at customer end. Assuming that the requirements gathering from process owners or end users will be sufficient for developing software will be a misconception. A detailed discussion for capturing requirement and understanding top management perception is critically important to lead to a successful completion of the project.

At the Vendor end – the Project Manager has to ensure that besides capturing user level requirements, it is essential to highlight the benefits to the top management being proposed for them from the product. It is not desirable but mandatory to freeze top level expectations at business study and requirement gathering stage.