I am working in a large telecom project, the release has been postponed twice due to various reasons(bad planning, customer giving new requirements all the time). Now the release is in another 3 months and the actual testing is starting now!. My manager has asked me what could and should be done to improve testing in this situation. Please give your valuable comments.
Re: Testing improvements
One idea would be to improve what went wrong (planning, requirements management,relation with customer,...)
For this you should determine exactly what went wrong, identify the causes and try to adress them.
For example requirements. What's mean new requirements- new functionalities, changes of existing requirements, ... ? Anyway you should establish and agree with the customer a process to manage the requirements. Starting with new requirements requests, analysis of the requirements, assigning to releases, tracking of requirements, approval of proposed solution by the customer... and even an escalation procedure for cases were you could not reach an agreement.
For the planning part what exactly went wrong? You have underestimated the effort needed, you had no enough resources,not trained staff, you have estimated only the most optimistic path, you have ommited some activities, you should consider more test phases,... to point some planning mistake I saw.
Re: Testing improvements
If your company has been around for a while I'd wager that this is not the first time this has happened. A thorough root cause analysis should be run with an autopsy of what happened exactly to the project after the project is closed. Finger pointing should be discouraged and a focus on what can be done in the future to mitigate the causes should be worked out. Wether it's training, more involvement by QA verification of requirements, or some other means of fixing the problems, something should be done to insure that it will not happen again. You might suggest following a proven process guideline like Microsoft Solutions Framework. It's what we use in place of the more expensive methodologies like CMM, CMMI and others.
Best of luck.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~
Re: Testing improvements
I will go out on a limb on this one. You cannot control the project from a QA perspective, so why your manager would ask you what you could do to improve the situation is a little dubious. Maybe you can shave a few weeks off the test duration if you are really smooth, but that does not make much of a dent in the overall problem, does it?
I suspect that the original deal was signed under optimistic assumptions as to when the project was to be completed. This happens all the time, when marketing has an opportunity to land a client but has to agree to deliver by a given deadline. That puts pressure on the PM to try to arrange as much parallel work effort as possible, to fit the SDLC into the time available. This is all a house of cards, of course, but it is also part of a game.
The game is that 99% of the initial requirements are incomplete. It is virtually expected that the client comes back with "onforeseen" revisions and the vendor response is always that the impact on the plans will be a complete disaster. Things are in disarray, costs escalate as time expands, and before you know it you have a reasonably normal project duration for a more reasonable scope that could have been predicted from the word go, but if you would have said anything the client would have gone to another vendor to try their luck.
Be reasonable, you cannot very well tell clients that the resulting project is much more sensible than what you started out on, because then you do admit you were cheating. So, you appear to do all you can to shave a few days here and a few days there to ostensibly minimize the impact on costs and duration. Ultimately this is all smoke and mirrors, the client gets their product late, they bitch and badmouth the vendor, but in the end the work is paid for, and the vendor can always claim that they would have delivered as originally in the contract if only the client would not have changed their minds. Get it?
Well, now you know how the game is played and you will experience the very same thing in the next contract. For anyone on the other side of this game, the counter game is to make the vendor get the work done under the original contract before you ask for revisions and upgrades. When they do run late (they most likely will because they were counting on change requests) you can express your concern about how the late delivery will impact on getting started on the upgraded version, ergo you can strong-arm them into a sweet deal to add more functionality for a much lower cost than the forementioned option would come out to.
Isn't this fun? It is not even covered in the PMI materials for training new project managers, thus you guys have a headstart!