My thoughts about Success

My thoughts about Success

1. Each person has their own definition of success.
2. Wanting success is the first step towards attaining it.
3. Self-trust is essential.
4. Goals are stepping stones on your path.
5. Your actions affects you’re out come, so success also depends on what action you performed.
6. There is no doubt there are setbacks, but each setback provides valuables lessons to avoid pitfalls.
7. You should manage your resources and maximize your efforts.
8. Keep in mind, every level of success brings new challenges.
9. Success should be a process that never ends.
10.Opportunity will be presented.

Working on the weekends.

Working on the weekends.

I’m in IT industry for 8+ years. In those years I never be a 9-5 Monday- Friday guy. I get in early, staying late, taking work home and working weekends. It’s not that whole year is like that. There are few pockets in years where you do relax. It’s not me alone, who work so hard, mostly I think every IT professionals work on weekends. That’s my belief that if you want to prove yourself, gets ahead and advanced your IT career, then work longer than the average person. But I think it also depends on project to project.

Being a QA guy on running projects and usually we work both Saturdays & Sundays when there is new deployment or have a big upgrade or something else. We need to work very long hours. And mostly companies do deployments on weekend. The logic behind that is so that your deployment doesn’t affect your production and your business. We need to back up a 24 hour operation and have to do what it takes.

But the worst part, the worst part is coming on Monday. If you work too much on the weekend and you doesn't feel so good come Monday! I think weekend work was part of the IT job. It usually meant 2-3 weekend a month. However my company does pay a weekend overtime, which my Project Manager doesn’t like it. I take 4 weeks of vacation a year.

How the method of thinking can impact the project’s success.

How the method of thinking can impact the project’s success.

I think that any project success is depends on, how the Project Manager and other project team member thinks the method of thinking about the project. We can categorize method of thinking in two parts.

Category one is Binary, or 1 and 0, black and white, good and bad. This kind thinking mainly have low risk frame of mind. Team views newness and routine as opposites and mutually exclusive. They love there routine job. Team feels low risk and is in fact low risk, because the familiar methods are still appropriate. This method of thinking never experiments and continues to do things ‘the way we’ve always done it’ feels safe and comfortable and result will always be same.

Category two is Experimental. The experimental ones see newness as balancing part of the whole project, which need to keep in a dynamic evolving equilibrium. The experimental does not think in binary, this team think in color, they add richness of what might be made to exist, to the background that exists already.

Experimental thinking creates an environment that encourages the maximum subjective risk, and the minimum project objective risk. Bold, speculative, even outrageous thinking is the mainspring of innovation.

Project Managers should promote experimental thinking in their project. Experimental thinking helps in several ways:

1. New possibilities, this thinking identify new possibilities.
2. A multiplicity of small risks is actually safer then big ones.
3. Steps on a learning cure, the new knowledge obtained from each one can be used to minimize the risks.
4. Keep the fresh thinking muscles in trim.

Don't overlap test phases

This post is continual of my previous posts Don't Misjudge test efforts and Why SAP projects fails about why SAP project fails through QA eyes.

Don’t Start the Next Phase of Testing Until the Previous Phase is Done

It is a terrible plan to overlap test phases. Avoid at all costs. If a test phase is not done at the scheduled start of the next test phase, do a hard stop and figure out a new plan and evaluate impact on total project schedule. Regulate one of the priorities as necessary.

Why, it Impact in modify in testing, revise in development – fix a system test problem, caused a problem in something that was previously working, Stress for everyone, long hours for QA, high pressure on developers to turn defects around quickly (sometimes defects weren’t completely fixed). So what is solution. Number one, If testing is not complete at the end of a test phase, especially system testing, escalate immediately with impact to total project schedule and second put a contingency buffer (size based on risk) between test phases.

Don’t Misjudge Test Efforts & Time in SAP CML/BI

In my post titled Why SAP BI projects fail, I reviewed some reasons why SAP projects fails. In this post I like to add more “Don't” kind scenarios, which help project managers to understand SAP project's pitfalls.

Don’t Misjudge Test Efforts & Time

Mostly project team misjudge test efforts and time take by testing. This is a major assumptions in QA. This is found that mostly team members are so "optimists" when testing that they misjudge the time and resources taken in testing. However being naivety in planning for extremely large test initiatives & assumptions on quality of entrance criteria make team very "Optimists". Being so optimists when testing is a major pitfall in SAP project. Whole team should be never-ending pessimists.

What's we lose when we are "Optimists" when testing:
1. It grounds overlapping of test phases – very complicated to manage & caused lots of rework & re-testing.
2. It make test schedule behind.

How to be an pessimists when testing. Being an pessimists is easy job, just ask the following questions. Let's take an example a task is given to QA team to test some 400 scenarios with in 4 week.
Question 1: Is it probable to test 100 scenarios a week?
Question 2: Is it 4 week include defect fix time also?
Question 3: Did all test cases in 400 scenarios pass in system test?

Suggestion:
Pertain the same approximation to QA test estimates as there is for development estimates. Think about complexity of tests, integration complexity, conversion requirements.

Unintelligent IT recruiters

DUFFER IT recruiters

In this blog post I’m giving you folks some advice how to figure out the either IT recruiters is stupid or dam stupid. The reason why I’m posting this blog is one of the stupid IT recruiters, make me mad.

So, here a story- One day I got forward message from IT recruiter, in my LinkedIn account. This forward message was forwarded by one of the unintelligent IT recruiter, her name is Neha. She works with Procom staffing agency. Furthermore the message was the following:

Neha Sachdeva’s note to Atul Kaushik:
Hi Atul,

I noticed your profile in LinkedIn and was hoping to speak with you regarding a position that I'm currently working on.
I was curious if you're currently available to pursue new contract opportunities?
Please don't hesitate to contact me: 647 288 4675 or NehaS@procom.ca

Kind Regards,
Neha

So after getting this forward message, I called her and the call goes to Voice Mail, I left VM with my contact number and why I’m calling her. I don’t get a single return call from this stupid, unprofessional, dull moron IT recruiter. This freaks me out, crap! Why the hell you are sending me email, one. Second in email you are asking me to give you a call. Third being so stupid and unprofessional not returning my VM call. I then send her email and guess what, no email reply till this day (1 month). IT recruiters are such a moron.

So guys don’t get in trap of these IT recruiter morons. They sucks! Never ever send your resume to them until unless you have more then 3 time conversations. Below is the dump questions asked by duffer IT recruiters.

1. This one is my most favorite one, I like this question most. When they cannot pronounce the names or companies listed on your resume and they are constantly saying "what....". Haaaa.. that make me laugh.

2. When Unintelligent IT recruiter asks you if you are still with a job, which is not, listed as your current job, it is time to dispose of the recruiter.

3. When Unintelligent IT recruiter asks you about a position and asks you questions related to the skills required for the position, many times they follow a list of questions but it is obvious that they do not know themselves what they are asking. It is time to kick out them because they will be unable to talk to the client accurately about your skills when they themselves are clueless.

Brief summary of QA

Brief summary of QA

1. Test Phase: Here we can debate on how many test phases are in QA. I just summarized them all and not in sequence .

Test Phases:
System Test
Configuration Testing
Integration Test
Post Prod – Other
Post Prod – Warranty
Unit Test
User Acceptance Test.

Environment/Landscape/Systems: There is no hard and fast rule, it depends on what is current in organization.

Simple: Tier0, 1, 2, 3, X, Production.

SAP: Sandbox (with different clients), Dev (with different clients-300/500/700), QA(100/200), UAT(100) and Prod.

Defect Type:
Data,
Configuration,
Functional,
Gui Defect,
Integration,
Navigation,
Performance,
Security,
Translation,
Usability.

Defect Cause:
Application Configuration,
Data, Deployment,
Dev. Misinterpreted Requirement
Dev. Missed Requirement
Dev. Package Defect
Duplicate
Environment
Missing Test Case
No Test Case Possible
Requirement Deficiency
UI Design Deficiency
Unoptimized Code
User Desktop Configuration

Why SAP BI projects fails

Why SAP BI projects fail?

Is all SAP BI projects fails? Or is it SAP need to do something in BI modules? Or is it Clients/Business management need to change its management cultural practice so that they align with BI?

So is it true all SAP BI projects fail? The answer is No, not that all SAP BI project fails. But that's true that when any SAP projects fail, they fail big. Why? One they are very complex, they are big. Second they cost a lot, that why the exceptions are very high on them, and when they fail, the company's ROI become ZERO, null. Third they take big Time to deploy. No client want, after investing lots of lots of money and time, SAP BI projects fails.

So following are points for SAP to work on SAP BI, so that their projects DO NOT FAIL.

1. Cut the deployment timing. Think in this way Time is money.
2. Make it Simple, take off or hide complex parts.
3. Money: Since now market is down, you should also cut the price tag on SAP BI.

And what Clients/Business management need to do change it's management cultural practice, so that projects don't fails.

1. Lack of communications
2. Lack of, scope change management abilities. SAP BI is alive project, mean it's take inhale and exhale air. It's not dead project, it's not constant projects. So you also have change management abilities, to handle project.
3. be cool, it's take some time to settle dust.
4. Never ever start SAP BI projects with other SAP modules or other big application. Start SAP BI project when every single project is in prod, and all dust rest, and wait for 1 year, then start implementing SAP BI projects.

Quality Management Vs Quality Control

Quality Management Vs Quality Control

In QA world, this is very confusing argument, that what kind of defects come in Quality Management and what's come in Quality Control.

In this post i'm trying to explain what Quality Management and Quality Control is. In QA world there are two QA activities one is Quality Management and second one is Quality Control.

Let’s see what Quality Management is: Quality Management is those activities which are related to documents. Or put in this way, those QA activity's where you do not need to write test cases and test script, but you have to review documents, those activities are like, Design Review, Architecture Review, Data Architecture Review, Deployment Checklist Review, Requirements Review, SQAP review, Support Documentation Review, Test Plan Review. If you found any defects while reviewing these documents, then you have to put those defects in Quality Management- QA activity in your QA software, like Mercury Quality Center.

And Quality Control are those activities which do not fit in Quality Management, Or those which are testable like Data, Configuration, Functional, Gui , Integration, Navigation, Performance, Security, Translation, Usability. Any defects found under these activities are logged under Quality Control QA activities.

SAP Business Warehouse (BW) Control Requirements to Ensure a High Level of Confidence in BW Data

SAP Business Warehouse (BW) Control Requirements to Ensure a High Level of Confidence in BW Data

This post give more details of best practice we are doing to test or provide Quality Assurance for SAP BW/BI in our company. This give more details of the controls required in the BW to ensure there is a that the data is both complete and accurate. These types of controls will ensure that the reports that are developed and distributed throughout the organization are reliable . IT is responsible for the control environment within the new Business Warehouse, and Enterprise Reporting has a significant reliance on this function. This document includes some ideas for effective control procedures for consideration by the IT Enterprise Data group.

Data Transfers
Every time a data source is created or populated the following checks must be done:
* Verify that the number of records in the destination table is correct given the number of records in the source table(s) / view(s).
* Verify that the hash total, (random summation of amounts), for 2 fields in the destination table is accurate versus the source table(s) / view(s). Ideally, fields whose values have a large variation and fields that are frequently used should be chosen.
* BW logging should be reviewed to ensure there were no errors in the transfer. IT should propose an action plan for how each type of error will be addressed with signoff required by business.

Notes:
* The processes should run at the time the data is loaded so that errors can be identified before the data is used.
* The process should be automated to minimize human effort and error.
* If, after following this process, data errors are encountered in BW an investigation should be done to determine what further controls are necessary.

Data Views
Every time a view of the data is created the following minimum testing must be done:
* Verify that the number of records in the destination view is correct given the number of records in the source table(s) / view(s).
* Verify that the hash total for all fields in the destination view is accurate versus the source table(s) / view(s).
* Verify that all fields appear to be populated completely without any obvious errors.

Notes:
* Once the view is in production it will be assumed that it will continue to operate correctly.
* If, after following this process, data errors are encountered in BW an investigation should be done to determine what further controls are necessary.