Designing processes - EMC Community Network

Planning and Designing the Application
Create a Project Plan
Create a Project Plan to outline the basic set of tasks required to implement a solution. This plan can
assume an out-of-the-box solution without any customization. If customization becomes necessary,
add it to the project plan as a separate module. For each customization module, the project manager
can estimate the impact on cost and schedule.
Include a Project Roadmap in the Project Plan that lays out the major phases of the project in the form
of a flow diagram and specifies the inputs and outputs of each phase. The inputs are templates that
define the minimum information that must be gathered to perform the phase. Include information or
participation needed from the client. The outputs are the deliverables produced by the phase. Negotiate
the level of participation by the client with the project sponsor in the planning phase.
Business requirements phase
Request that the client provide the following information for the Business Requirements phase:
• Current technical environment
• High-level business requirements
• Numbers and roles of system users
• Estimated transaction volumes
• Descriptions of ingestion mechanisms (such as email, scanners, and EDI) and equipment used to
capture the data
• Samples of the content that the system will ingest
• Relationships between data and user roles (required to define security roles)
• Existing business process diagrams
The project team can prepare templates for this data so that the client clearly understands, in advance
of the engagement, what is needed and how to gather and format the information. Design these
templates so that the delivery team can use the information to configure the system.
Negotiate the project roadmap with the project sponsor. Consider a solution that takes into account
both the needs of the client and the capabilities of the product. Both views are critical for success.
Interpreting the intentions of the client
An engagement often begins when the client provides functional specifications. Think of the functional
specifications as a starting point for the design discussion. If you follow the requirements too literally,
you run the risk of not being able to use EMC products as they are intended to be used. This can lead
to expensive customization, which can lead to support issues and an unsatisfied client.
Translate the functional requirements into business requirements. Ask questions so that you can
reveal the requirements behind the requirements. For example, a specification might state that the
system should limit a user’s ability to work on multiple cases. If the requirement does not look right,
it probably is not right. A business requirement can often be implemented in different ways. For
example, calculate sales tax is a business requirement. One functional requirement can state that the
system must populate a database lookup table with date, item type, and the tax to be charged. Or,
the business requirement could be met by a second, alternative functional requirement. Articulate to
EMC Documentum xCelerated Composition Platform Version 1.6 Best Practices Guide 19