Specs: We'll write these if we have to

The good news about writing functional specifications is that you’ll most likely have plenty of examples to read for reference and a template to use. The bad news is that you might have to write it. Even if you don’t write it you’ll have to read and understand it. You’ll have to read the business requirements and understand those too. As you read these, you should be thinking about the technical specs, what prototyping will need to be done, and where the holes are. One more thing, make sure the eventual users of the system are engaged and sign off on all functional decisions. If they blow off meetings and are not involved in the process, they’ll be back later and will demand changes.

Large companies with a lot of procedures, lawyers, regulations, and outsourcing will undoubtedly require that technical specs be written before starting development. This is fine for about 80% of the project, however the technical details during the development, testing and deployment will change. The technical specs will need to be reworked to reflect this change at the end of the project. If you start out with this expectation, you won’t get as frustrated writing the specs without all the details. Be sure to write down in the assumptions that you expect to rewrite the specs after the project goes live.

As you solve the technical issues keep the following questions in mind:

• Are the User’s of the system served well by this design?
• Are there too many details written down at this stage?
• Are there features which are training issues vs. customizations?
• How much continuous discovery will this project have?
• Will the development or testing be outsourced?
  
  

Are the User’s of the system served well by this design?
Any reservations should be considered and detailed here. In many cases the writers of the specs don’t really know Documentum well enough to fully understand possible scope creep issues and the technical ramifications of writing something like “this system will support nine languages…”
I don’t know how many times the specs were written in a vacuum. The User’s were too busy to fully detail the business requirements so the spec writer reads the manual and fills the functional specs with existing functionality.

Are there too many details written down at this stage?
I’ve read functional specs that have been bogged down by details which will change. Here’s where the lumpers and the splitters show there true colors. The lumpers will write too little detail, while the splitters will describe too much. It’s my experience that approximately 10 to 20% of what you need to develop a comprehensive application will not be known at the time that the functional spec written. Make this assumption, record it and move on. You can really slow a project down by trying to perfect all the details at this point.

Are there features which are training issues vs. customizations?
This question is usually asked if the initial discovery phase was done by folks who did not know the Documentum application well enough. The business requirements would reflect this lack of knowledge, would cascade to the specs. You have to gage how much continuous discovery this project might have. Was the business unit as engaged in the project as it should be, or will they perk up during the testing phase and really start thinking about how they’re gong to use this?

Will the development or testing be outsourced?
I had to bring this up because in these times of going the cheaper route, the project just may be going over seas. I wouldn’t worry though, because every Documentum project that I’ve done is way too involved to ship the whole thing to a third party vendor. Outsourcing pieces of the project may make sense. If you have to outsource get ready to write a lot more to describe what to do. Also, prepare to hand hold the third party through some of the more complex details of the development or testing.

The bottom line is that there’s a balance between the time you take to write or correct quality specs and the time it takes to develop. In some cases, it may make more sense to prototype and write the specs afterward. You’ll have to make this decision and get buy in up front. Don’t just do it; if it ends up taking longer to prototype, you’ll be on the hook to explain why.