IT Project Planning and QA
Think back to your days in middle school. Do you remember your Gym class where the gym teacher would pull out the extraordinarily long rope and lay it out in the middle of the field? He would then split the class up into two groups. One group was assigned to the left side of this rope and the second group was assigned to the right side of the rope.
Direction was given to the class to pick up the rope and hold it in their hands. The instructions were that each side was going to pull as hard as they possibly could until the flag tied in the middle of the rope crossed into the other side’s territory.
And then the pulling began! Both sides dug in with their feet into the ground. Kids were screaming and yelling. One side would knock the other side of their feet and gain a step or two. Then, the other side would put forth some extra force and knock the other side of their feet and gain a step or two. It would go on like this for what seemed to be an eternity, until finally…the side with biggest kid would drag the entire other side across the line and victory would be declared!
Tug of War was such a blast back then!
Jump forward twenty years and replace the people on the two sides of the rope with a project manager who is all about IT Project Planning and a Quality Assurance Manager who is all about making sure the project is done right. Replace the rope with a project plan and you have the makings of a great contest of tug of war.
IT Project Planning and QA may not necessarily see eye-to-eye all the time and this can feel like a knock-down, drag out bout of tug of war. The following article will highlight some of the causes of this conflict and what can be done so everyone is pulling in the same direction.
IT Project Planning and QA – a Certain Recipe for Disaster?
IT Project Managers and Quality Assurance people are cut from a different cloth. Each respects what the other does, but they definitely look at the world through different lenses. Below are some of these differences that could be a cause for contention from time to time:
- The Pursuit (or Not) of Perfection – Any QA person that is worth their salt seesthings in a very black and white point of view…as they should. The functionality that is called for in the IT project planning process either works or it doesn’t. The numbers that resulted are either right or they are wrong. The integration from one system to the next is either connected or it’s not.There is no room for ambiguity, grey areas, or even “close enough” when it comes to doing a good job in QA. Test plans and scripts are designed for a reason and the answer after running those tests is either Pass or Fail.A project manager, on the other hand, works in a very different type of environment. The IT project planning process is one that is full of different shades of grey. Requirements and priorities are constantly shifting. Resources come and go based upon what is important to management at that moment in time.Depending upon the circumstances and downstream impact, there is room for ‘close enough’ if there is a greater good accomplished by moving parts of the project forward.
It is this different view of the world in the IT Project Planning process that may cause these two people to stand toe to toe and start tugging on the rope.
- Higher Stakes for QA – Sure, when everyone is involved in IT Project Planning it looks good on paper about who is going to be responsible for what: The Engineering team is responsible for building the product, the Documentation team is responsible for putting together great instruction and training manuals, Business Analysts are responsible for making sure the proper scope is captured, and Project Managers is focused on coordinating and orchestrating everyone’s efforts. But, QA ultimately has to sign off on the deliverables produced from each of these departments either passing or failing.Let’s face it…when something goes wrong on an IT Project one of the first questions asked is “how did this make it out of QA?” A close tie for the second question, of course, is “who was the project manager?” But, ultimately it is the responsibility of QA to approve something as ready to go.It goes back to the old question about who is more committed for breakfast….the chicken or the pig? The chicken provides eggs and lives to see another day. The pig provides the bacon, and, well…you get the point. QA feels a great deal of pressure and responsibility on them before they feel comfortable enough to put their stamp of approval on something.
- Dates – One final point of contention between IT project planning and QA has to do with dates. Project managers are obsessed with dates. They always want to know exactly when something will be done, how much of something will be done, and if just one minute slips on the schedule they are demanding an explanation of why and asking what can be done to gain the minute back.QA, on the other hand, is focusing more on the job getting done right. They understand there are deadlines to meet, but they also understand that whatever it is they are testing needs to be 100% correct. They are comfortable with the fact that you can’t rush perfection nor assign a cold, hard, fast date to anything as complicated as the IT projects they are responsible for approving.This leaves a project manager with a quizzical look on his face as he tries to figure out how he can assign dates around this type of non-committal ambiguity.
The above three areas certainly lend themselves to turning into a recipe for disaster. But, take heart. There are ways IT Project planning and QA can work together to accomplish the same objective.
Can’t We All Just Get Along?
Yes…it is possible for project managers and QA resources to get along with each other. It will require effort from both sides, but here are some suggestions you can start to apply as a project manager.
- Get QAs Input – Never, ever, ever move forward with the IT project planning process without getting their input. This cannot be stressed enough. If you want to guarantee that you’ll be on opposite sides of the rope then just fill in the blanks for them on the project management plan and see what happens.
- Establish a Good Relationship – QA resources are people too. And, they are people just like project managers. They have kids, they play sports, they do stuff on the weekends. Yes, sometimes you may not feel this way in the heat of battle but, it never hurts to establish some sort of common ground with these valuable resources.
- Plan on Things Taking Longer – Even if you do have a good relationship with QA and get their input up front…plan on things taking even longer than they anticipated. Until things are down to a science, it’s not too far-fetched to think that some things will take 2 to 3 times as long as what was originally estimated. Plan for this and you’ll be able to navigate through the surprises quickly.
- Defend their Position – Do you really want to make allies with your QA team? Do you want to maybe even get them to the point someday where they could utter the words “close enough” out of their mouth every now and then? Then stand up for them. They have an important job to do. If they are not given the proper time necessary to do their job then everyone ultimately suffers.
Project Management and QA will never see eye-to-eye and that’s OK. It makes the work environment interesting and it takes a certain amount of tension to crank out good products. Do all you can to bridge the gap and find yourself on the same side of the rope. You can then focus on beating the competition!
Want to make friends with your QA department? Let them try ProjectManager.com FREE for 30 days to track their issues. Any type of issue can be tracked from technical problems and software bugs to equipment and supplier issues. They can record the impact and priority of these issues and assign actions to resolve them. Plus, our ingenious dashboard and reports take Issue Tracking to a whole new level. This is one area where they will never have to say “close enough”!