PerformancePoint Planning Implementation

Blum Shapiro Consulting > Services > Performance Management Consulting > PerformancePoint Planning Implementation

PerformancePoint Planning Implementation

Blum Shapiro Consulting is a Microsoft Gold Partner with specializations and expertise in PerformancePoint Server, Sharepoint Server, and SQL Server. The project team will comprise product technology specialists, CPAs, IT controls, and compliance experts that will provide the technical, accounting and regulatory expertise a project like yours requires.

Our experience shows that successful PerformancePoint Planning implementation and product usage is most influenced by the initial planning that occurs at the beginning of the implementation cycle. This planning is referred to as Envisioning by Microsoft. Envisioning creates an initial project scope and identifies business processes to be included in the implementation of PerformancePoint Planning. Envisioning is the most vital process in the PerformancePoint Planning implementation cycle.

Microsoft Solutions Framework Process Model Overview

Every PerformancePoint project goes through a lifecycle; in other words, the process includes all of the activities in the project cycle that take place up to completion and transition to an operational status. The main function of a lifecycle model is to establish the order in which a project specifies, plans, implements, tests, and performs its activities. The appropriate lifecycle model can streamline a PerformancePoint project and help ensure that each step moves the project closer to successful completion.

The MSF Process Model combines the concepts of the traditional waterfall model with the spiral model to use the strengths of both. The MSF Process Model provides the benefits of milestone-based planning from the waterfall model, as well as the iterative creative process from the spiral model.

The MSF Process Model is based on milestones. Milestones are review and synchronization points rather than freeze points. They allow the team to adjust the scope of the project to reflect changing customer requirements or to react to risks that may materialize during the course of the project. Additionally, milestones bring closure to each phase. Closure is demonstrated by the delivery of tangible outputs from each phase that the team produces, and by the team reaching a level of consensus around those deliverables. This closure, and the associated outputs, becomes the initiating point for the subsequent phase.

The MSF Process Model allows a team to respond to customer requests and to change product direction mid-course, when necessary. It also allows a team to deliver key portions of software faster than would be possible otherwise. The MSF Process Model is a flexible component of Microsoft implementations that has been used successfully in the software industry to improve project control, minimize risk, improve product quality, and increase development speed.

Blum Shapiro Consulting uses the Microsoft Solution Framework combined with key steps we have developed over many projects implementing Financial, ERP, and Custom solutions. The PerformancePoint implementation phases are:

Envision
Plan
Develop
Stabilize
Deploy

Envisioning Phase

The Envisioning Phase addresses one of the most fundamental requirements for PerformancePoint project success - unification of the project team behind a common vision. The Project and Engagement team must have a clear vision of what it wants to accomplish and clearly define it in terms that motivate the entire PerformancePoint team.

Envisioning, which creates a high-level view of the PerformancePoint project's goals and constraints, can serve as an early form of planning; it sets the stage for the more formal planning process that takes place during the project's Planning phase. The primary activities accomplished during Envisioning are the formation of the core team, and the preparation and delivery of a Vision Scope document. The delineation of the PerformancePoint project vision and the identification of the project scope are distinct activities; both are required for a successful project. Vision is an unbounded view of what a solution may be. Scope identifies the part(s) of the vision that can be accomplished within the project constraints.

Activities:

Collect key information on PerformancePoint project goals, logistics, functionality, users and usage, IT environment, risks and concerns
Discussion of business strategy and how the PerformancePoint solution must support that strategy including metrics
Kick-off meeting to define project structure and current state processes including: Steering committee , Project resources – Finance, IT, etc. , Project management structure
Map PerformancePoint technical requirements to hardware, network, and software requirements for servers and user desktops
Procure and install infrastructure including Server(s), OS/Database, PerformancePoint Planning, Monitoring, Analytics.
Procure user hardware and software where necessary including, Desktop computer, Excel
Schedule PerformancePoint training for client project resources

Deliverables:

Installed PerformancePoint hardware and software infrastructure
User desktops capable of supporting solution
Trained project resources
Initial PerformancePoint project plan

Planning Phase

The Planning phase is when the bulk of the planning for the PerformancePoint project is completed. The main activities of the Planning phase by the project team are:

Preparing the PerformancePoint functional specification

Working through the design process

Preparing work plans, cost estimates, and schedules for the various deliverables

The design process gives the team a systematic way to work fiom abstract concepts down to specific technical detail; it is important to maintain traceability between requirements and features. This begins with a systematic analysis of the user profiles (also called personas) that describe various types of users and their job functions (operations staff are users too). Much of this is often done during the Envisioning phase. These are then broken into a series of usage scenarios; where a particular type of user is attempting to complete a type of activity, such as fiont desk registration in a hotel or administering user passwords for a system administrator. Finally, each usage scenario is broken into a specific sequence of tasks, known as use cases, which the user performs to complete that activity. This is called story-boarding.

The results of the design process are documented in the functional specification(s). The functional specification describes in detail how each feature is to look and behave. It also describes the PerformancePoint architecture and the design for all the features.

The functional specification:

Provides instructions to team members on what to build
Is the basis for estimating work
Is an agreement with the customer on exactly what will be built
Is a point of synchronization for the entire team

Once a baseline for the PerformancePoint functional specification is established, detailed planning can begin. Each team lead prepares a plan or plans for the deliverables that pertain to their role and participates in team planning sessions. As a group, the team reviews and identifies dependencies among the plans. All plans are synchronized and presented together as the Master Project Plan. The number and types of subsidiary plans included in the Master Project Plan vary depending on the scope and type of project.

Team members representing each role generate time estimates and schedules for deliverables. The various schedules are then synchronized and integrated into a Master Project Schedule.

At the culmination of the Planning phase, customers and team members have agreed in detail on what is to be delivered and when. At the project plans approved milestones, the team re-assesses risk, updates priorities, and finalizes estimates for resources and scheduling.

Activities:

Understand current state of processes, tools, data model, challenges
Design meeting to review / document projected processes, reports, interfaces, and business objectives

Process
Reports
Data sources
Dimensions
Model data flow
Business rules

Map operating model requirements to software functional requirements.
Provide desired data source file format
Develop dimension standards where necessary
Update PerformancePoint project plan

Deliverables:

Prototype solution business objectives, processes, metrics, and architecture
PerformancePoint detailed system design
Sign-off on PerformancePoint design
Detailed PerformancePoint project plan
Data source example files
Dimension standards

Developing Phase

During the Developing phase the team accomplishes most of the building of solution components. This includes PerformancePoint documentation and configuration. However, some development work may continue into the Stabilization phase in response to testing.

The Developing phase involves more than configuration and integration. The infrastructure is also developed during this phase, and all roles are active in building and testing deliverables.

Activities:

Install PerformancePoint software / create development environment
Create data marts, models, and dimensions :

Accounts
Entities / Cost Centers
Departments
Companies
Others as defined in plan

Create PerformancePoint rules for each model

Allocations, Translations, Eliminaitons, Depreciation, etc.

Unit testing of rule output and rule sequencing
Create and publish PerformancePoint input forms and output reports
Create and publish PerformancePoint dashboard component
Configure security

Deliverables:

Configured PerformancePoint software
Capability to import data from source systems into PerformancePoint
Initial PerformancePoint reports
Initial PerformancePoint input forms

Stabilizing Phase

During the Stabilizing phase, the team conducts testing on a PerformancePoint solution whose features are complete. Testing during this phase emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and triaging, or prioritizing, bugs and preparing the solution for release.

Early in this phase it is common for testing to report bugs at a rate faster than implementation team members can fix them. It is difficult to tell how many bugs there will be or how long it takes to fix them. Once a build has been deemed stable enough to be a release candidate, the PerformancePoint solution is deployed to a pilot group.

The Stabilizing phase culminates in the release readiness milestone. Once reviewed and approved, the solution is ready for full deployment to the live production environment.

Activities:

Import historical data into PerformancePoint application and run cycles
Compare legacy reports data with PerformancePoint reports data
Test PerformancePoint dashboard results
Test initial set of financial reports for accuracy and completeness
Document submission and reporting procedures
Write remaining PerformancePoint reports
Test remaining PerformancePoint reports
Write remaining PerformancePoint input forms
Test remaining PerformancePoint input forms
Perform end-to-end test of procedures
User Acceptance Testing (UAT)
Initial performance testing
Implement PerformancePoint bug fixes
Migrate to PerformancePoint production environment
Performance testing
Document PerformancePoint application support procedures

Deliverables:

Configured PerformancePoint software
Capability to import data from source systems
PerformancePoint reports
PerformancePoint input forms
UAT Signoff
PerformancePoint application support documentation

Deploying Phase

The deployment complete milestone culminates the Deploying phase. By this time, the deployed PerformancePoint solution should be providing the expected business value to the customer, and the team should have effectively terminated the processes and activities it employed to reach this goal.

The customer must agree that the team has met its objectives before it can declare the solution to be in production and close out the project. This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place.

Activities:

Develop PerformancePoint training for procedures
Deliver PerformancePoint procedures and training to users
Communicate timing to key personnel
Set expectations for Users, Stakeholders, IT
Rollout PerformancePoint to users (pilot or enterprise)
Measure PerformancePoint operation and log issues
Update PerformancePoint procedures, dimensions, etc. to reflect issues
Work with user group to identify additional desired PerformancePoint platform capabilities