A few years ago, in one of my last freelance roles, I was in a test management role for an international investment bank. My project manager reported to a programme manager one of whose other projects was failing. Three times it had missed its implementation date and the test function had been identified as the part of the process that was letting everything else down.
Since the testing for which I was responsible was proceeding well, I was asked whether I would cast an eye over the test plans for this other project and perhaps “sort things out”. Consequently, I met with the two people who were managing the testing and spent a couple of days with them, learning about their project and the testing that they had planned and attempted to carry out.
They were both clearly competent people and they seemed satisfied with the capabilities of the people working for them. Furthermore, they had a good grasp of their project and I couldn’t find much fault with their testing (and people will approach the same task in slightly different ways, anyway). So, at the end of all their explanation, I asked the simple question: so what’s going wrong?
The explanation was straightforward and will be familiar to anyone who has been involved in testing: some dates on the project plan had slipped but the deadline had not been changed and it was the testing that had seen its time budget diminish to make up for the slippage. The testing had not been completed and the implementation had been aborted. A second run, and then a third had been attempted but each time with only a small amount of time for testing. Defects were raised but there was no time to fix them and thus the project had ended up in its current state.
I had this meeting at the end of May and there were nine weeks of testing to be done, according to the test plan. So, I went back to the programme manager and gave him the good news. There was nothing wrong with his test team, they had a good plan and the testing – including time for bug fixing – would be complete by the end of August. I said a September implementation seemed reasonable but that an October live date would probably be prudent, especially when reporting up to the board, since it was realistic and contained the possibility of early delivery.
A couple of weeks later I bumped into one of the test managers and so I naturally asked how the project was progressing. It transpired that the programme manager had announced an *August* live date and that the test team had, once again, been set up to fail.
The moral of the story is, I think, self-evident, yet you will hear similar stories from IT people everywhere. If people are not given the time to do their jobs properly, then your projects will fail and your staff will become de-motivated. People should certainly be held responsible for the timescales and deadlines they give but there is no excuse for ignoring what they say and then holding them to account for dates that are imposed upon them.
No comments:
Post a Comment