Taking on the Load

I am currently being torn between the desire to take on as much of the Condor project work as I can get (I love a challenge), and the opposing need to limit our involvement to what can be achieved within the current budget and resource capability.

You see, ever since this project somehow acquired the target of a mid-2007 delivery date (I am still unsure how that happened), the focus has been on 'how can we deliver this quickly?'. It is no longer 'my' project, and I will be managing only a portion of it. Disappointing. It is also clear that, since our business area has the requirements, and our development team have the expertise, the key to rapid design and build is probably to utilise what has gone before as far as possible. I am therefore tempted to take on as much work as I can get away with, but I am under strict instructions to preserve the other projects on the portfolio. In other words, I can utilise only those people not already allocated to higher-priority projects.

You see my problem. To be fair, when I asked if I could expand my present scope and the number of resources assigned, provided it did not affect other projects, I was told that was fine, as long as TPC pay for it.

We must, however, be seen to make the maximum effort to meet this (frankly unrealistic) target. To that end, we need to come up with ways to make most efficient use of the standard project methodology, modifying things where necessary, and re-use as much of the current intellectual and software capital already in place. The current method - sorry, framework - assumes a waterfall approach to managing the phases of a project. A set of requirements is delivered by the Business, an application design is created, followed by an Infrastructure design, followed by build.... you get the picture.

We are going to have to adopt a more overlapping approach to things, specifying dependencies at a much lower level. I have already suggested that we adopt a JAD approach to the requirements definition phase. I envisage defining requirements categories, each being specified in parallel, but not wholly in isolation, with significant IT involvement, since the so-called business analysts don't actually have any analysis training.

We will also need to combine the design phases, producing application and infrastructure designs in parallel.

Any of you managers used to delivering software projects will recognise the challenges inherent in meeting a mid-2007 deadline with an estimated spend of £6m. We need to get a quite phenomenal 'burn-rate' to obtain that sort of productivity.