If someone tells you that Business Requirements are not that important to your role as a developer, ask them what happens if you need to make a change to them? Get involved in this phase if you can because BRs set the tone for the whole project, and you need to meet and get to know all the team players. Most developers get pigeon-holed into roles that suggest that they just do what you tell them to do; follow the specs… It might feel comfortable to do this, but you’ll always feel frustrated during the process, especially if you need to push back on the BRs.
Know Webpublisher
As you sit through the Discovery phase (if you get invited) you’ll gather incite into the issues that really matter for the project and who will be looking for what functionality. What happens during the business requirements writing phase is that everyone becomes an “expert” in Webpublisher. The requirements reflect what the business thinks WP can do OOB, not necessarily what it’s potential is. To be fair, the main objective is to use WP OOB as much as possible, but also to find the middle ground in terms of configuration vs. customization.
Consultants Who Know Everything
If there are outside consultants, especially those newly graduated from our fine Ivy League schools, they will commandeer the discussions about requirements and do breakout sessions to fine tune their own understanding of the requirements and their skills in Excel. Business school graduates are fond of Excel and can achieve incredible feats in expanding BRs to new levels of complexity. These are well thought out, but are usually overkill for OOB WP functionality. Make sure the consultants know WP functionality inside and out before they start writing BRs. The more the requirements grow in size and complexity the less likely that the business users will read all the requirements and sign off on a document they can completely grasp.
Think about the whole application
It’s easy to get bogged down by concentrating too much on the details. For example, there were many times when we drilled down on the requirements only to realize that it was close enough to OOB functionality that we didn’t need to write it all up. By “whole application” I mean:
- What’s the end to end flow of content through the system?
- Who will access the content and when?
- What level of support can be sustained?
- How much training will be needed?
- Do you have enough resources to satisfy all the requirements?
Whiteboard the end to end flow
One absolutely necessary step in the requirements process is to draw out the end to end flow of content so that everyone is on the same page. This flow diagram will serve as a milestone of the group’s understanding of the application. It will be altered and republished, but the core flow should not change. This flow should have a combination of technical and visual elements. It should be of use for the business side as well as the IT side. Everyone needs a visual representation of the application and now is the time to create it.
There will be times when an issue can not be resolved by the people within the team. This is the time when you spin off pros and cons of the possible solutions to the problem. This is also the most frustrating time of the project, when egos are flying and a lot of time is wasted. A few types of issues I’m talking about are:
- Configuration vs. customization
- Integration vs. manual data entry
Configuration vs. Customization
It’s easy to get excited about developing new functionality to WP mainly because WP has many foibles that are usually corrected during the first release of the project. However, you have to weigh customizations with wanting a smooth upgrade path. One of the WP projects I was a part of was so heavily customized that management waited until the version was no longer supported and then had to plan the upgrade to which was scheduled to talk over a year to accomplish. This type of customizing indulgence is usually avoidable if the right balance of Configuration and Customization is achieved.
The typical pros and cons of these issues involve:
- Cost
- Length of time to develop
- Testing
- Functional worth
- Priority
- Impact on upgrading
Integrations
There are all sorts of integrations that you can do with Documentum, the one I’d like to talk about is one with Documentum Compliance Manager (I’ll carry this example throughout this series on WP). The pharmaceutical company I worked for wanted to be able to run certain regulated web content to DCM. A content flow diagram was created and a prototype was developed during the requirement writing phase mainly because no one knew for sure if integrating WP with DCM was even possible. By architecting the solution with a TBO we were able to integrate with DCM without disrupting any of DCM’s functionality.
“Nice to have” vs. an absolute must
When you have the business users in the room they will say everything they bring up is necessary. But, when pressed, they’ll start to admit that some functionality is “nice to have”. WP offers many features that can be configured to get close to most requirements around publishing to a website. I’ve migrated from a custom Documentum web application to WP and the biggest complaint was the amount of versioning that goes on in WP. They also had very complex ideas on how to organize the content. These ideas carried over into WP as categories. WP categories are versatile and powerful when used in the right way, but, in our case, we went way overboard. We had over 10k nodes, multiplied by 10 locales. This was and continues to be a nightmare.
Two thorns of WP publishing
There are two issues that plaque WP: Security and Navigation. Customizations gravitate toward these two monsters. Why hasn’t EMC purchased or built a web server / app server yet? Sitecache is nice, it’s decoupled, it scales. However what happens when the content gets to the website? The coupling of the decoupled security and navigation is a sink hole for bad performance and enormous support issues.
1 comment:
Well written article.
Post a Comment