We are on a large project for a client (>100 developers) and one of the issues that keeps coming up is how can we reduce the cycle time.

At one point in the project we were using a waterfall model, all the requirements had to be done and approved before the requirements could be handed off to the development team (3rd party company). The development team would then look at the requirements and write functional specifications and design documents. Sometimes we would need to make changes to the requirements, but they were locked so we weren’t allowed to. Unfortunately we were also not allowed to attend the functional spec reviews because we were directed to begin on the requirements for the next phase. One of the impacts of this process was that even if the requirements were effectively done, we weren’t allowed to give them to the development team. If stakeholders took any time at all, we could lose a week or more on every document. Another impact is that the requirements process was at least 3 releases ahead of the developers. By the time development got to the requirements almost everything had changed based upon the outcomes of the prior release. Frankly it was a bit crazy.

Fast forward a year and now we have a much better process in place. Each topic area has it’s own parallel development path. Once the requirements are complete for the topic the topic can move to the next phase. Now delays in one topic don’t impact any other topics. This has helped to reduce our cycle time significantly. We would like to push the lifecycle to be more agile to reduce planning time and to improve the end user satisfaction of the software. One of the things we are contemplating changing now is how much overlap we can have with the functional specifications and the requirements efforts. If we can get the developers involved earlier we think we can get much higher fidelity on the requirements as the developers have a lot of good input plus we can reduce the elapsed time by overlapping requirements and functional spec phases.

There are a number challenges to doing this though, first, the 3rd party development team has around 100 developers, but not enough senior designers (I would call them architects) – it seems like there are around 5. What this means is that they are maxed out and they simply cannot afford to be in meetings unless the requirements are very firmed up. They also aren’t willing to invest any time into functional specs that may be based on changing requirements. Second, the project is so big that the 5 designers can’t keep every topic in their head. This means they must have requirements documents that describe the decisions that we all agreed to in a lot of detail with a lot of pictures (low-english speaking developers). Third, everytime we get developers into a meeting with users all they want to talk about is messaging between system layers and feasiblity of various designs. The users frankly are completely baffled and tend to tune out. Our job has been to keep them on track, but you know how developers are sometimes. Fourth, the developers sometimes badger the users into accepting less functionality by constantly focusing on what is possible instead of what the users need. Finally, there is a bit of an antagonistic relationship between the vendor and the client. This is expressed as the requirements being viewed as a contract. Therefore the vendor is not willing to work on anything unless it is in writing and approved by the client.

Despite these challenges the project is moving along quite well. We are probably on our 6th release in 1.5 years and we have come a long way since we started with a very immature development lifecycle. The client and vendor teams are both not software companies but really want to define the process themselves. We have been working diligently with them and things get better every release. This release we are going to experiment with giving the developers draft copies of the requirements documents and having the developers participate in some of the later requirements sessions. I’ll let you know how it goes as we get more agile on this relatively large development project.