Redefining the process

In my previous entry I described, briefly, the situation I was faced on transferring across to a new project. I had inherited a project that had undergone a feeble attempt at requirements gathering. All I had to do was somehow cram six months...

In my previous entry I described, briefly, the situation I was faced on transferring across to a new project. I had inherited a project that had undergone a feeble attempt at requirements gathering. All I had to do was somehow cram six months of business analysis into four weeks and convince a rather jittery business that we had, in the face of the evidence, understood perfectly what they needed. When even we weren’t sure we had.

The first thing I had to do was re-convince my team that they really did know what they were doing, and that they did have useful experience that we could use. The previous project leader had used the team without considering their experience or knowledge. All I did was allow each analyst to focus on their business specialties, in doing so the team could see themselves where we had gaps in our knowledge.

As well as restoring confidence to the team members, it was vital to restore focus on the project. The business had decided on its needs for the new application nine months before. The previous project leader had wanted to play with its boundaries, which is fine when the simple things are done. But the application foundation had not even been defined and the scope was already being expanded beyond the agreement. To get the project back on track the scope was redefined, back to what was agreed with the business last summer. By getting the scope back under control, the team had very clear parameters within which to work, and could understand their objectives very clearly.

Confidence, experience and knowledge tied to clear objectives and within four weeks we had managed to get the first couple of modules re-analysed and corrected; timescales haven’t slipped; budgets are still under control - for now.