Oct 9 2009 1:17PM GMT
Posted by: Jaideep
Software Project,
software delivery,
Project Management,
project manager,
Project Development,
project implementation,
project stage,
customer requirement,
quality,
product quality,
software quality
I have seen different type of drivers on road: some drive very fast violating all rules and regulations to reach the destination. Can this attitude work in software development and delivery? I don’t think so, if the project manager is more worried about reaching the implementation stage without bothering about the customer requirements, probably he is calling for a big bunch of troubles.
Another set of drivers are overcautious type. They will take lot of time in building customer requirements and will be uncompromising towards quality of product to such an extent that every deadline will be crossed without meeting it. Can such project managers be liked by customers? Or by the management?
Our next category of drivers is ‘stick to the route’ kind. They will never change the route whatsoever is the hurdle is and whatsoever is the impact on the delivery. Can customer accept a project manager who is damn fussy about the requirements?
Some drivers believe in ‘change with the wind’ style. They start for a destination, get a call on the way from the customer to divert to another destination, and the driver agrees happily. Probably this is the quality that customer wants in the project manager these days.
Aug 14 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
reliability,
quality,
software quality,
testing,
Bug,
project manager
If you, as a project manager, are fond of thunderstorms, volcano eruptions, etc. it is ok howsoever you drive a project. Otherwise look below at six indicators mentioned below. Even if one of the reason prevails in your project’s lifecycle, manage it, get rid of it, immediately, before a small wound becomes a big septic.
Irregular releases – when plan or commitment varies from actual delivery inconsistently. Some plans finish in time, some with small variation and some with huge variation. It means there may be a volcanic surprise.
Drop in quality or inconsistent quality of product built: Testing is happening, bugs are being reported but if the product coverage is incomplete while testing, or volume of low quality bugs reported is higher as compared to some severe bugs skipped in reporting, there is a mishap going to happen for sure.
Wrong cycle time estimations: if your estimations are going haywired, you plan milestones and achieving them itself if becomes a project, and go beyond control for achievement – there is a mess, in a big way.
Unplanned expenditure like overheads, delays: all these estimates going wrong, will call for extra time for team members and extrapolation of deadlines – a clear indication of a thunderstorm coming on the way.
Predictability: if your team members lose their commitment level, your predictability will become a big question mark for your management and for the customer.
Reliability: your team members’ reliability will invariably start decreasing the moment all this starts happening – and so will be yours.
Jul 20 2009 10:00AM GMT
Posted by: Jaideep
tester,
Development,
Software Project,
software product,
Project Management,
customer requirement,
test case,
testing report,
test report,
bugs report,
quality control,
QC,
quality,
product quality,
software quality,
developer,
development team,
code writing,
coding
The responsibility of a tester is to ensure the peace of mind of the end users who are going to use the software product. Another target should be to safeguard customer’s investment in the product. In order to discharge this responsibility, the tester should focus all his skills on understanding customer requirements and measures to map it with product built by writing appropriately comprehensive test cases, performing test and preparing a detailed self-explanatory test report. Complex business requirements will require extraordinary level of understanding. Keep in mind the budget and time constraint for performing testing without compromising with the coverage or quality.
The overall impact of testing should be clearly visible on the product built. The bugs reported should bring a sense of belonging with the developers and customer users. Clarity of bugs in testing report should not only help developer to fix defects properly but guide him not to repeat the same type of issues in future releases. This may happen slowly but gradually should help in increasing developer’s performance and quality of code writing. After all the development team should start taking testers as their best friends and well wishers instead of someone who is trying to find out the weakness in code writing.
Jun 12 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
project manager,
project performance,
software development,
software quality,
quality control
10. When you start getting increased number of bugs as compared to earlier releases
9. When your developers stop thinking about quality in code
8. When bugs pass through QC unnoticed
7. When you stop acknowledging quality efforts and start giving more importance to speed and volume of writing a code
6. When quality and development teams are not in sync
5. When you start feeling QC is a waste of money, efforts and time
4. When quality aspect is given least time in overall project
3. When management starts overlooking then overseeing
2. When customer does not get grossly involved in performing UAT
1. When above mentioned in point numbers 2 to 10 starts spreading in other projects
Jun 8 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
software development,
Project Management,
project organization,
project team,
project delay,
project completion,
on-site development,
testing,
tester,
QC,
quality control,
project implementation,
software implementation,
functional lead,
technical lead,
quality,
software quality,
project quality
Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.
So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:
5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.
4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.
3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.
2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
level.
1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.
All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.
Mar 4 2009 10:03AM GMT
Posted by: Jaideep
software development,
software testing,
Project Management,
Software Project,
Quality Goals,
software quality,
SQA,
SQC,
product development,
project documentation,
organizational goals,
time to test,
development plan,
Project Plan,
Test Plan,
test case,
implementation plan,
project close-out,
top management requirements,
requirements analysis,
business requirements,
change management,
Risk Plan,
Risk Management,
Software Repository,
Code library,
Code repository,
test case repository,
project standards,
project methodologies,
software development standards,
software development methodologies,
test standards
1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.
Feb 27 2009 9:54AM GMT
Posted by: Jaideep
software quality,
project quality,
quality standards,
quality measures,
quality metrics,
software metrics,
Project Management,
Software Project,
customer requirements,
software product,
software design,
business requirements,
functional requirements,
software delivery,
Project Delivery,
project execution,
project initiation,
Project Development,
project implementation,
software strategy,
test strategy,
test case,
Test Plan,
test scenarios,
test results,
fixing of bugs,
project close-out,
post implementation phase of project
The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
Feb 25 2009 10:02AM GMT
Posted by: Jaideep
Software Project,
software business,
software project management,
project objectives,
business survival,
growth,
revenues,
profits,
maturity,
Project Lifecycle,
standards and methodology,
software metrics,
stakeholders,
transparency,
project completion,
project sign-off,
customer satisfaction,
customer delight,
customer requirements,
software requirements,
Team building,
team role,
team responsibility,
team accountability,
software quality,
project quality,
first time right,
project overrun,
continuous learning,
Increase in revenue,
Avoid revenue loss,
Reduce costs,
Avoid cost increases,
Improved service
Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):
1. Control on Project Lifecycle
2. Standards and Methodology
3. Metrics
4. Stakeholders rights
5. Transparency
6. Pro-active approach to avoid post-mortem
7. Universal approach for similar projects
8. Timely completion, sign-offs and payments
9. Customer satisfaction and delight
10. Customer requirements and both end clarity on objectives of the product
11. Team building
12. Roles, responsibilities and accountability
13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall
14. First time right approach
15. Quality right from start – ongoing – every step
16. Increase in revenue
17. Avoid revenue loss
18. Reduce costs
19. Avoid cost increases
20. Improved service
Feb 2 2009 9:51AM GMT
Posted by: Jaideep
tester,
testing,
software,
QA,
QC,
SQC,
SQA,
developer,
quality head,
quality manager,
software quality
The young inexperienced or short experienced budding testers are the one who will determine the future of testing. This is the prime thing that the QA head has to keep in mind while grooming and mentoring them. The testers have to have a firm belief that the future of testing is going to be brighter than today and that is why the QA Manager and the testers have to deliver their best efforts to all their endeavors. They have to exert their utmost efforts, contributing to the building of a software product (built by developers, being tested by QC team thereby delivering the best of it!) that properly reflects your spirit and drive in testing.
The key aspect is not to compromise with your fundamental values of Testing, such as clear Testing Mission, Policy, Plan, Procedure etc.
Testers have undoubtedly a strong affinity towards testing that makes them close to the product, development team with a joint mission to deliver a bug-free product.
