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.

Prototyping and proof of concept: This is fun!

This is fun if project managers get that POCs are crucial to the decision making process:

• When someone on the team says “The way I did it at company X…”, but this way doesn’t feel right, prototyping should be considered to detail the pros and cons of the solution.
  
• Every project has at least a few gray areas where the business users aren’t quite sure what they want and say they’d like to “see” something.
  

The fun part is actually working out some of the pieces of the puzzle. It’s also satisfying to prove to yourself and others that your gut feeling was right, or that it was wrong, but not as wrong as everyone thought. Here are some of the pieces to the puzzle that you may be able to figure out:

• Is the customization possible? What is the level of complexity?
• How many resources are needed and what type to achieve the functionality requested?
• Is the estimated amount of servers of the infrastructure correct?
• Will the application solution perform to the user’s expectations?
• Will the schedule slip because of the functionality required?
  
  

Setting a POC sandbox also allows for installation experience and a preview into some of the issues that you’ll have to solve later. For example, when was the last time an installation of a Documentum product went exactly according to the installation documentation? Is your database administrator new to Documentum databases? This would be a good chance to get through the DBA headaches.

What about storage requirements? After loading up some dummy data, does the total disk space estimate make sense? When the dev, test, and production environments are taken into account including extra room for migrations, is there still enough space?

TBO vs. WDK customizations
I really like TBOs. They are very useful to making changes to attributes during all content operations. There will be times when you look at a customization to a drop down in the UI to achieve some kind of functionality and it occurs to you that it could be done with a TBO. Prototyping will help you work through the reality of that idea.

The bottom line is that you will be dealing with scope creep if you don’t prototype solutions when it makes sense to do so. When someone says “we need to customize” , make sure through a test of the functionality of the application that it’s not just a configuration. The WDK can be very flexible in terms of configuration and TBOs are great to use for customizations.