Project Plan for Portal project

Portal project follow general Dynamics project plans but include [1], interface and process definitions not just for administrators and user roles of the native Dynamics application but also for administrators and user roles of the portal application and [2], greater interface detail is required to be defined of the portal interface components. In other words, processes and interfaces are more complicated and require greater attention to detailing and successfully building their behavior.

General Dynamics based project plans work well with Agile based or hybrid Waterfall and Agile based methodologies . A mid-sized ($50-100 k) project plan would follow a series of stages:
1. Define (business and technical requirements)
2. Design (architecture. solution design, and prototype)
3. Build (build and test)
4. Deploy (deploy, train, and monitor)
5. Support (support; change management)

What is also a proven strategy for projects that are more risk adverse (large and larger mid-sized projects) is organizing project activity by workstreams to manage resources and discussions along appropriate role types such as:
1. Infrastructure (system and network administrators; technology architecture)
2. Functional (business subject matter experts, business analysts, functional business consultants)
3. Development (developers, functional technical consultants)
4. Reporting (business intelligence; data summary)
5. Data (migration)
6. Training (deployment and ongoing)
7. Integration (data integration; 3rd party application integration; data bus / warehouse)

Where Dynamic 365 portal projects vary with the more traditional Dynamic 365 projects is the need to manage the portal aspects into the existing project topics such as:
1. Business roles need to include non-CRM users which are more stringent than CRM users (the general public is more finicky then corporate users)
2. Infrastructure deployment and technology discussions including how the client application behaves in a personal infrstructure environment
3. Privacy considerations are likely more extensive
4. Portal interface components - forms, web page widgets - need to be more precisely defined as there are both limited 'in-the-box' tools and greater 'outside-the-box tools available for providing how user roles will interfact with the portal. This will necessitate a greater need and reliance on wireframing the interface instead of relying on customizing a prototype solution.
5. Business processes increase in complexity to include the portal interface. This means that instead of working with just the Dynamics 365 application (and to a limited extend the Outlook for CRM application), processes need to include portal user roles, behaviors, and interface requirements.
6. Portal interface styling likely needs changing to meet corporate web site styling definitions
Post a comment