Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by sanjay saini
Improving the Testing Process
Categories:
Information Technology
Categories: Information Technology
| I work with an IT software development organization, so most of my posts are specific to software development projects. During the testing phase, we typically experience the following problems: 1. We expend approx 15% to 20% of the development effort in the bug-fixing phase. 2. Our team discovers a lot of missing functionality during the testing phase. 3. Quality assurance (QA) and development teams have different mindsets, so they understand the same feature in different ways. 4. Test cases written by the QA are a conversion of a software requirements specifications document into an excel format. 5. During and after the coding phase, the developer doesn't often test the application himself and instead leaves everything for QA. He tends to believe bug identification is QA's task and that the developer should only be responsible for fixing bugs. I think the software testing cycle works on the 90:10 rule: Ninety percent of the project takes 10% of the allocated time, while the remaining 10% takes 90% of the time. After expending a lot thought on this process, we came up with some solutions that may reduce the testing and bug fixing cycle: 1. Let the QA and development teams both review the requirements and get necessary clarifications from the client. 2. Ask the developer to give a presentation of his project understanding to QA and his module lead. 3. Have QA prepare the test cases. 4. Ensure test cases cover the functionality as well as the user cases and scenarios 5. Have the developer review and log defects, too. 6. After the completion of the coding phase, ask the developer to run high priority test cases prepared by QA. 7. The developer should submit the test log to QA. 8. QA shall start the testing. 9. Each discovered bug should have a corresponding test case ID. If the test case doesn't exist for the bug, then QA should add a new test case for it. This will ensure the test cases have covered all the use cases. 10. In the test log for each failed test case, enter the bug ID. This will ensure all bugs are raised and tracked to closure. 11. Perform the Root Cause Analysis (RCA) for each bug and improve the coding process. 12. Track the bugs raised by QA versus the bugs raised in user acceptance testing or bugs raised in production. 13. Test cases should be data-oriented, and QA should be trained enough to write simple SQL (Structured Query Language) queries. 14. The test log should show the number of rounds executed with the number of test cases that have failed, passed or have not been executed for each round of testing. 15. Track the actual effort spent in the testing and bug fixing phases to better plan for the next module or project. |
A Tough Question
Categories:
Leadership
Categories: Leadership
| Why do we require project managers? For delivering the project on time and within the current budget. But the project manager doesn't do anything on the project--it's the team or team leads who work hard to deliver the project. The project manager is the white elephant that sits on top of the team and does nothing. But, if a project fails, no one in the organization complains (except the project manager) about the team. Instead, everybody runs after the project manager since he or she was responsible for the delivery (without doing anything). But, is there a structure in which someone else capable among the team would be responsible for the delivery? The reason I ask is because in Asia many of the small-to-medium-size IT companies are more inclined to technology rather than project management. Their success or failure depends on the technology competence and project management has little to do with it. So should the technology manager be responsible for the success or failure of the project? It seems to make more sense, to me at least, that the project manager should just help him out on process implementation, preparing the plan, providing resources, etc. |
What Can Be Learned From India
Categories:
Risk Management
Categories: Risk Management
| Everyone has been watching and reading about the recent terror attacks
on India's business capital, Mumbai. The events have passed and
patchwork has just begun. Those who were directly responsible for the security failure have been shown the door either willingly or under pressure from a combination of higher command, media and public anger. I would like to discuss it as a project failure and conduct (with reader participation) the post mortem analysis on what went wrong and how it could have been avoided. The discussion should be based upon information available from news analysis. Let me start with lessons learned that translate to projects: Issue #1: The Indian Intelligence Bureau (IB) is claiming it had informed the government about a possible attack from seaside but no action was taken. There was a risk identified but no mitigation plan was prepared for it. It is important to monitor risk areas and take preventive action before it gets too late. In projects, it is the responsibility of project managers to spread awareness about the risks in their projects and their mitigation plans. Don't take even a minor issue casually. If you don't have time to look into the issue, then assign it to someone else and track it to closure. Issue #2: India had a couple of terror incidents in the past but no measure was taken to prevent them in the future. It is a universal truth that prevention is always better than correction so it's good to have check points and preventive measures in place before you lose money and resource time. Document lessons learned from previous mistakes and ensure everyone is aware of them. It's better to review the learning database periodically and update it if required. Let's keep the conversation going. What other lessons learned can you find in these events? |
Make the Effort
Categories:
Communications Management
Categories: Communications Management
| I often find that communication between project managers and senior
management is very limited or nonexistent. There are several reasons.
One reason is the busy schedule of executives. And other reasons might
be the lack of interest shown by the project managers, as well as the
need to perhaps hide something that project managers feel should not go
up to senior management. But it is an important part of keeping up with project progress. Reviewing progress and profitability should not be something that waits until year's end. Instead there should be some monthly or quarterly checkpoints in between. This regular communication should also include client feedback--both good and bad. In most organizations, senior managers or account managers require project managers to conduct daily/weekly status meetings and publish the minutes of meetings. These meetings are usually kept internal to the team and there is rarely communication with the senior manager or account manager about the discussion. Senior Management Review (SMR) reports--which lists things such as project risks milestones achieved--prepared by project manager for senior management and other support/effected groups also do not promote accountability as they can be manipulated for convenience. How can project leaders and senior management solve this problem? By having someone independent of the project of someone on the client side (e.g. business analyst) prepare a monthly status report. The report should include: 1. Resource Utilization 2. Billing Done for the Month (to be provided by project manager and this should match with the value submitted to accounts) 3. Earned Value generated by the Team (to be provided by project manager and this should match with the value submitted to accounts) 4. Work Projection for Next Month 5. Testing Quality (mainly for IT projects) 6. Highlights/Lessons Learned 7. Operation Decision that need SM/Account Manager's review 8. Items to be taken in company's Interest By doing this, senior management will have an insight to the project and can act accordingly before it gets too late. Project managers should not behave like a stranger in a crisis situation. |