Discovery: do they really know what they want?

As a Developer, depending on the size of your company and how enlightened the management, you’ll most likely get involved with the Discovery phase of the project. If you can try to influence who’s on the Discovery team by suggesting other resources which you trust will “do the right thing” try to do it before the first meeting.

Don’t solve the issues: listen
The first few meetings during this phase are spent listening to the Project Manager(s) go over what they believe are the questions that should be asked and the corresponding answers from the Business Manager(s). Developers: don’t try to solve these complaints in the meeting, just listen and answer questions when asked. Be careful not to ask detailed questions at this point, as the discussion will dive way too deep into the nitty gritty and could get religious. The managers need to hear themselves talk. If you create too many disruptions at this point, they’ll write you off as a pain.

Know OOB functionality cold
I’ve been in situations where I knew the functionality being asked for what hard to implement, but wasn’t 100% sure and couldn’t back up my gut feeling with proof. If I had known WebPublisher OOB functionality better I would have been more effective in arguing my point. One way I dealt with not knowing the answer to a technical question was to suggest that I prototype the functionality and get back to the team with an answer the next day. This allowed me to get proof (or not) of my gut feeling and work through possible solutions without getting shutdown immediately. This also saves lots of time and effort in the long run by exploring the ramifications of a small decision which could balloon out the project (80x20 rule).

Where does the content come from?
The content of the website project was already designed and developed, but was being hosted on a tradition web hosting site. The website content was FTP’d to the site and manually published. The users wanted “everything we have now” and more. The “everything we have now” was a black hole which needed to be dealt with asap. What can you do with a statement like that without going through a huge process of requirements gathering? What we came up with was punch list of what WP does and presented it to the business.

Lumpers and Splitters
On the project team, there will be people who like to drill down on every piece of functionality, not only to understand it but to drive others crazy. They like to split issues into smaller pieces and understand them better that way. Others like to lump issues together and hand off the large understanding to those who understand the software (WP) better. During each meeting the lumpers and splitters will go at it. If you can catch this happening before it gets too heated, call for another meeting to hash out the particulars. It’s important to keep the focus on manageable chunks of the project.

Who’s poking holes in the boat?
During these meetings, at first it was hard to figure out who was aligning with whom in terms of making the hard decisions about what functionality was in and what was out. Over the course of a few meetings, it became clear and it also was obvious who was fully invested in the project and who didn’t care. The folks who didn’t care reacted by saying things like:
- “Let’s cross that bridge when we get there”
- “We don’t have any expertise in that area”
- “We don’t have the time or money to do things the right way”
- “Let’s get a consultant in to look at this, I know someone…”
- “What are the risks involved with this decision?”

Sense of Urgency
Remember that managers like to drive the project to their own schedules. During the discovery phase, if you don’t push back when necessary, you’ll be setting the stage for long hours down the project lifecycle line. Managers want to push the project along no matter what issues arise. Let’s say you’re trying to decide whether to use WP’s import screen the way it is or to customize it. This kind of exercise requires time and attention to detail. If something is missed, you’ll pay for it later.

Your homework
As the high-level, prioritized issues are ironed out you’ll get a better picture of the scope of what’s being asked for. During the priority step, you should fill in a matrix that you make up on your own. Columns that I’ve used in the past are Requirement, Priority, Scope, Effort, Custom/Config, Cost:

- Requirement: This is the specific functional piece of functionality that is being asked for by the business.
- Priority: The weight given to the requirement by the business.
- Scope: All the WebPublisher, technical and project-related ingredients of the requirement.
- Effort: Gut feeling on how much time it will take to accomplish.
- Custom/Config: Are there any customizations? Is it really all configuration? Try to find any holes that are not being discussed
- Cost: Any potential sink holes that will be expensive.

Example:
Requirement: Automate website approval process
Priority: 1
Scope: Design workflow template, notification design, prototype, user testing, rework, application migration from dev, to test, to integrated test, to training, then to production.
Effort: Moderate
Custom/Config: Mostly configuration, possible customization: deal with aborted workflows.
Cost: Developer training, consultants

Cognitive Dissonance
Take note of Business folks and members of your team who do not admit when they are wrong or have made a mistake. These are the people who will sometimes unwittingly take the project of course and will need to be reigned-in when they do so. They are also the people who pull some of the team aside and have “off the record” discussions about the project. They occasionally need ego boost by show boating an experience in the past that they think is important: “the way I did that at was to implement with .

The following are some paths of discovery decisions and where it took WP customizations:

Security
- Implemented RSA Cleartrust
- Had to add 2 servers per environment: 10 in total
- Had to hire an RSA consultant for initial installations
- Spent numerous cycles with basic documentation and endless trial and error troubleshooting.
- Customized the login, denied, and logout pages
- Held up the project as authentication became the critical path during the initial testing phase

Multiple Locales
- Used Categories to manage multiple languages for the website navigation.
- Created 10 sitecache configurations, times 5 for each environment.
- Redesigned the web cabinet structure to accommodate the new content submission groups.
- Trained publishers how to add translations and publish them.
- Created a custom application to integrate with outside translation vendors.
- Dumped huge amounts of money on developing an automated way to process the sitecache target content and metadata.

Automated Navigation
- Designed a simple way to publish navigation changes based on folders and linked content.
- Developed a TBO and customized WP to prototype the functionality.
- After the User Demo, we rewrote the design and developed a much more complex solution.
- This went on for a few more cycles until we had to stop and move on to other aspects of the project to meet our schedule.
- The business said they wouldn’t make any changes to the site folders for a year. After the site went live using WP, within a month they were changing the navigation.

Discovery is a term used for exploring what the business would like to have. What it really means is finding out what is realistic to have now and what is going to be released at a later date. There will always be disappointed members of the team who will never be satisfied and other who will feel over worked. Hopefully you’ll have a balance of these types with the more motivated types who enjoy what they do.