Developement Project Management stages and details

Project Start-up

Software Development Process Flow – Project Start-up
The Project Start-up step incorporates the following stages:
Entry Criteria
The Development Agreement/Proposal is received.
Tasks
Software estimation
Project Initiation and preparation/update
Project Management Plan (PMP)
Inspection of PMP
Phase-end Review
Validation and Verification
Approved Project Budget Sheet
Reviewed PMP
Project details made available using the Time Sheet System
Exit Criteria
Approval and release of Project Management Plan
Approved Project Budget Sheet
Phase Deliverables
Approval and release of Project Management Plan


Software Development Process Flow – Requirement Analysis
This step incorporates the following stages:
Entry Criteria
The Project Management Plan is made available to the client.
Tasks
Prepare Software Requirements Specifications (SRS).
Define Acceptance Criteria & prepare Acceptance Plan.
Provide the Phase-end Review.
Inspect the Software Requirements Specifications (SRS) Document.
Validation and Verification
In this stage, the SRS is completely reviewed and fine-tuned according to client requirements.
Exit Criteria
In this stage, the agreed SRS is made available to the client along with the Acceptance Plan.
Phase Deliverables
SRS
 
Software Development Process Flow – High-level Design
This step incorporates the following stages:
Entry Criteria
Agreed Software Requirement Specifications are available.
Project Management Plan is available.
Tasks
Prepare High-level Design (HLD).
Examine the HLD.
Initiate the Phase-end Review.
Validation and Verification
Review of High-level Design is validated, verified, and incorporated.
Exit Criteria
High-level Design documentation is made available.
Phase Deliverables
High-level Design document is delivered to the client with all feedbacks effectively incorporated.
Software Development Process Flow – Low-level Design
This step incorporates the following stages:
Entry Criteria
Project Management Plan is available.
HLD document is available.
Tasks
Prepare Program Specifications.
Provide a Structured Walk through.
Prepare the Test Plan and Test Cases.
Provide a Structured Walk through the Phase-end Review.
Validation and Verification
Review Test Plan.
Review Program Specification.
Review Unit Test Cases.
Review Functional Test Cases.
Review Acceptance Test Cases.
Exit Criteria
Program Specifications are released.
Unit Test Cases are released.
Functional Test Cases are released.
Acceptance Test Cases are released.
Phase Deliverables
Program Specifications
Unit Test Cases and Test Data
Functional Test Cases and Test Data
=============================

Software Development Process Flow – Testing
This step incorporates the following stages:
Entry Criteria
Project Management Plan is available.
Successfully Unit Tested Code is available.
High Level Design, Low Level Design, and Unit Test Cases are available.
Tasks
Conduct testing.
Prepare user documents.
Inspection of user documents.
Provide Phase-end Review.
Validation and Verification
Review functional test results.
Review User Documentation.
Exit Criteria
Tested System is released.
User Documentation is completed.
Phase Deliverables
Test results

Upgrade or reimplementation or Implementation initiation

Whatever your Oracle Financials project, be it an R12 Upgrade , an R12 reimplementation, or a fresh greenfield Implementation.  It is important that you select the right partner and this starts with the RFI, RFQ, RFP & RFT documents.

So what are they ?

• RFI - Request for Information
• RFQ - Request for Quotation
• RFP - Request for Proposal
• RFT - Request for Tender

RFI – Request for Information

This document is the starting point in the procurement process.  You have identified a wide list of suppliers that you think can provide the product or services you require and need to qualify them through to the next stage of the procurement process. The purpose is simply to understand and qualify the potential suppliers, not the specific solutions.  As this is the initial document it does not need to be a long one. Aim for 5-6 pages.

 

The RFI should include:

• Company background and overview
• High level explanation of
  • Requirements giving rise to the RFI ( ie. Products or services giving rise to the RFI )
  • Current systems and issues
  • Where you want to be once the project has been completed. 

RFI Should not include

• Details of other suppliers the RFI has been submitted to. 

What the customer wants from RFI Response	What the supplier wants from an RFI
To gain a general understanding of the competition in the market. Provide enough information for pre-qualification by procurement department. Provide the basis of short listed vendors for the next phase. Supplier references.	To Qualify you as a customer. Understanding of your business, its current issues and what you want to achieve from the project. Specifics on what products and technology the customer is interested in. Estimate of project budget.

 A sample RFI Template document for free download can be found here.

What is Difference between E-R Modeling and Dimentional Modeling

1. ER modeling the data is in normalised form. So more number of Joins, which may adversly affect the system performnace.Whereas in Dimensional Modelling the data is denormalised, so less number of joins, by which system performance will improve
2. ER modeling: a view of data from data processing. OLTP
   MD modeling: a view of data from business porcessing.-- OLAP
    

AIM -- Normal practice we do

MD020 - Add on solution

 For each gap, a solution will be found. And each solution is recorded in this MD020 document. This will have a high level view of what the gap is and how it will be addressed in the customizations. Functional consultants will also prepare this.

MD050 - Functional design doc.

For each md020 there will be a MD050 doc..which is a functional design document. Its like an extension of the previous one with details like how the solution will be developed and all. which validations needs to be done and all.

MD070 - Technical design document

This is where you come into picture. you will be converting the functional doc to technical doc, like which API will be used, which tables will be used.. and all...based on this doc a developer will develop the code.

TE070 - Unit testing scripts and results. unit testing will be done by developer. you need to remember these terms and phases. in unit testing you will be testing components individually. like for instance in the interface development we tested the sqlloader scripts, table creation scripts, packages that call API's are tested seperately. the bugs that are found in this phase are fixed immediately then and there. The final results will be preserved and will be useful in future.

TE080 - Link test scripts and results

A separate testing team will do this. They will not look into the code but will be interested in input and out. This is like final testing. Any bugs found are notified to the development team for fixing.
=======================================================
AIM --

Project Deliverables I have used in my Implementation in sequential order

CR010 – Project Management Plan / Project Plan (WM020)

Overview Training

RD010 – Organization Structure

RD020 – Business Requirement Gathering

RD050 / BR030 – MAP Business Requirements

TA040 –Application Architecture Strategy

CRP Session I

BP080 – Future Business Model

BR010 – GAPAnalysis

CRP Session II

MD050 – Functional Design

MD070 –Technical Design

System IntegrationTesting

CV010 – Data conversion Strategy

CV060 – Data ConversionTemplates

PM010 –Transition Strategy

TE040 –Test Scripts

BR110 – Security Profiles (Roles and Responsibility Matrix)

UserAcceptanceTesting (UAT)

Cutover and Production Migration Plan

End UserTraining (End User Manual)

BR100 –Application Set up

useful XML publisher Report Syntaxes

useful XML publisher Report Syntaxes

Sub Templates:

<?template:header?>

This is Last Page

<?end template?>

After that you can type in header or footer section,

<?call:header?>

Last Page:

Take the any one of the insert field type in the following syntax,

Suppose,

Field name : Last page body

Status bar: <?start@last-page-first:body?><?end body?>

                   This is last page

Page Break:

<?split-by-page-break:?>

Section Break:

<?for-each@section:G_CUSTOMER(This is group name)?>

Properties:

<?PASSWORD?>

In XML we have to write in,

<PASSWORD>welcome</PASSWORD>

Bar Code:

<?register-barcode-vendor:'oracle.apps.xdo.template.rtf.util.barcoder.BarcodeUtil';'XMLPBarVendor'?>

<?format-barcode:JOB;'code128a';'XMLPBarVendor'?>

Conditional Formating:

<?if:ACCTD_AMT(This is column name)<1000?><xsl:attribute xdofo:ctx="block" or “incontext” name="font-weight">bold</xsl:attribute><?end if?>

Incontext means: column level

Block means: row level

Multi Layout:

<?choose:?>

<?when:CF_CHOICE=’VENDOR’?>

VENDOR NUMBER	VENDOR NAME	LOOKUP CODE
oplv VENDNUM	VENDNAME	FLAG  eloop

<?end when?>

<?when:CF_CHOICE=’INVOICE’?>

INVOICE NUMBER	DESCRIPTION	VENDOR ID
opli invoicenum	desc	FLAG  eloop

<?end when?>

<?when:CF_CHOICE=’PO’?>

PO NUMBER	POVENDOR	STATUS
oplpo PONUM	POVENDOR	STATUS  eloop

<?end when?>

<?end choose?>

Running Total:

<?xdoxslt:set_variable($_XDOCTX, 'RTotVar', xdoxslt:get_variable($_XDOCTX, 'RTotVar') + ACCTD_AMT(This is column name) )?><?xdoxslt:get_variable($_XDOCTX, 'RTotVar')?>

RTotVar means declare variable=0

Brought forward and carried Forward:

<xdofo: inline-total display-condition="exceptfirst" name="EntAmt"(This is column name)>Brought Forward: <xdofo:show-brought-forward name="EntAmt" (This is column name)format="99G999G999D00"/></xdofo:inline-total>

<xdofo:inline-total display-condition="exceptfirst" name="EntAmt"(This is column name)><xdofo:show-brought-forward name="AcctAmt" (This is column name)format="99G999G999D00"/></xdofo:inline-total>

<xdofo:inline-total display-condition="exceptlast" name="EntAmt"(This is column name)

>Carried Forward:   <xdofo:show-carry-forward name="EntAmt" (This is column name)

format="99G999G999D00"/></xdofo:inline-total>

<xdofo:inline-total display-condition="exceptlast" name="AcctAmt"(This is column name)

><xdofo:show-carry-forward name="AcctAmt" (This is column name)

format="99G999G999D00"/></xdofo:inline-total>

<?show-page-total:EntAmt(This is column name)

;"99G999G999D00"?>

<?show-page-total:AcctAmt(This is column name)

;"99G999G999D00"?>

Page Total:

<?show-page-total:pt(This is parameter);'#,##0.00'?>

Repeating Headre:

for-each@section G_CUSTOMER

CUSTOMER_NAME

for-each G_CURRENCY

Trx Number	Trx Date	Trx Amount	Trx Amount Remaining
for-each G_INVOICESTRX_NUMBER	TRANSACTION_DATE	TRANS_AMOUNT	TRANS_AMOUNT_REMAININGend for-each

end for-each

end for-each

The Three Most Common Mistakes Made in Oracle BI Application projects

The Three Most Common Mistakes Made in Oracle BI Application projects

For a variety of reasons, completing a successful Oracle BI Applications project is not as straightforward as one might think considering that the BI Applications are touted as a pre-built, end-to-end solution out of the box.

Based on our experience with either implementing new Oracle BI Applications projects or following on to failed projects, there are three common mistakes made that can determine the success or failure of the project: 

1.   Failing to follow the installation and configuration guides

This may seem difficult to believe but there are many cases where projects have been implemented without following the specific instructions in the installation guide and/or the configuration guide.  

The installation guide is critical for setting up the infrastructure for Informatica, DAC, and the OBIEE platform.

Oracle Business Intelligence Applications Installation Guide for Informatica PowerCenter Users

Some of the more common steps missed include:

• Setting up the SSE_ROLE for the target data warehouse user
• Configuring the proper Code Page settings for data movement between source and target
• Failing to review and apply the supplied Oracle database parameter settings in the parameter template file (for example the one for Oracle 11g named init11g.ora)
• Not setting PowerCenter Integration Services custom properties - specifically the  overrideMpltVarWithMapVar parameter which enables Informatica to evaluate parameters within mapplets.

The configuration guide provides instructions on how to set up both common Oracle BI Application areas and dimensions as well as functional area configuration steps.

Oracle® Business Intelligence Applications Configuration Guide for Informatica PowerCenter Users

Under common dimensions, it is critical that the exchange rate and calendar configuration is followed correctly and relates to the specific source system environment that will be used.

For the functional areas, there are a series of configuration files that must be reviewed and edited to conform to the source system.   For example, the Human Resources functional area requires that the  
band dimension files for Person Age, Job Requisition Age,  Performance Ratings, and Period of Service are configured before the data is loaded.

Also domain CSV files for Ethnic Group, Sex, Employment, and other HR attributes should be reviewed prior to the data load,  For HR Analytics, the most critical domain file that must be configured is the one that populates the Workforce Event dimension.  This file (named domainValues_Wrkfc_EventType_psft.csv for Peoplesoft implementations) maps each employee assignment event from the PS_JOB table to a standard set of values for Hires, Terminations, and other job related activities.   This file should be reviewed with knowledgeable HR subject matter experts to properly categorize each Action/Reason Code combination into the standard event types.

2.   Developing dashboards without continuous user involvement

The four words that strike fear into the heart of any Oracle BI applications consultant are "I have a spreadsheet".    In many implementations, dashboard development requirements are taken directly from one or more existing spreadsheets that are passed among various business organizations.   This approach more often than not leads to a disappointed user base when a final dashboard is delivered because OBIEE, while quite powerful, cannot always replicate the form and function that is easily built into a spreadsheet.

A far better approach is to take the existing spreadsheets and work through a fit-gap analysis to understand the business requirements and metrics that drive the spreadsheet.  After that is completed, the OBIA data model should be modified to reflect those requirements before any actual dashboard and analysis configuration is started.    Once the data model is ready and available with either actual or test data, workshops should be scheduled with users to demonstrate the capabilities of OBIEE on top of that data model.   Rather than duplicating spreadsheets, focus on the data model and the flow of an analysis.  Many spreadsheets have thousands of rows that are filtered by the user and then pivoted to create other summary analyses.   

Start with a top down approach on the dashboards, focusing on:  

• dashboard prompts to filter reports automatically 
• drilling and navigation 
• conditional highlighting
• ranking reports to identify outliers and top performers
• charts that visually display trends
• multiple view types of the same data using view selectors
• column selectors
• filters and calculations driven by presentation variables 

The key is to get users to think about interactive analysis instead of data dumps and scrolling through long table format reports.   

It is important to push back on users when they ask for features that are not easily achieved in the OBIEE tool or require significant modification to the data model just to meet a very specific reporting requirement.  Balancing the development and maintenance of any OBIEE code with what can be occasionally excessively specific user report requirements should be considered before heading down a path that can lead to project delays. 

Involve users throughout the development process to get their input and feedback.  With the rapid development capabilities of Answers, it is very easy to modify the layout of dashboards and analyses on the fly to get buy-in from the users. 

3.   Implementing the RPD without modification

The delivered metadata repository (RPD) that comes with the Oracle Business Intelligence Applications should not be considered a final product.    On every OBIA project, one of the first tasks that should be performed is an RPD Review with the business users to develop a list of customizations that will make the Presentation Layer of the RPD a more effective representation of the business.    Performing this process early on will greatly reduce the development time later on when reports are developed.   It also is very helpful in improving the user adoption experience if they are new users to the OBIEE Answers tool.

The three R's of the RPD review process are:  Rename, Remove, and Reorder.

Rename any presentation column or table to reflect the business definition.  It is far easier to rename a column than to get user's to convert their known business vocabulary to match that of OBIA.  For example, rename the Out of the Box Employee Organization table and columns to be Department.

Remove any presentation columns and tables that are not required for analysis.  This includes any columns that may be exposed in the Presentation Layer but are not populated by the ETL for the particular source system for the implementation.   Work under the assumption that any column exposed in the Presentation Layer must be populated by ETL, unit tested for accuracy, and useful for creating analyses.    Simplicity yields project success. 

Reorder presentation tables and columns to be more effective for users.   Put most frequently used columns at the top of presentation tables.    Put dimension tables at the top and facts at the bottom of the subject area.    Group similar metrics together either by purpose or by time series.    Make good use of presentation table foldering to minimize the number of attributes and metrics displayed. 

Conclusion:

There are no guarantees of success when implement a BI application.   But there are certainly ways to increase the possibility of attaining the ultimate goal:  satisfied users with a useful business analysis tool delivered on time and on budget.    It can be done.

(ROI) Return on Investment for Business Intelligence

How to justify a business intelligence system has occupied people ever since these were called decision support systems.  Supposedly the numbers are “soft”.  Reductions in IT costs virtually never cover the cost of replacing spreadsheets and Access databases with a proper BI system.  Yet, organizations spend over a billion dollars a year on BI systems, and that’s just in the USA.  In today’s environment, CFO’s will not let capital investments pass without some kind of a business case.  So what do these companies do?

Let’s briefly dissect the formula for return on investment:

ROI =     Expected value (NPV (cash flows from revenue increases or cost savings))                                          
…………Expected value (NPV(cash outlays from spending on hardware, software, labor, and services))

This formula tells us what we have to look for and how we should maximize the value.  We need to estimate:

• Cash flows and their timings
• Likelihood of these benefits occurring
• Cash outlays for the BI system and their timings, including
• Hardware and software costs
• Implementation costs
• Training costs
• Administration, enhancement and upgrade costs
• The likelihood of the cash outlays occurring

The formula also tells us that benefits and costs that occur in the near future are more valuable than those in the distant future because they are discounted less AND because the probability of them occurring is higher.

The classic definition of ROI looks at cash flows.  Non cash accounting items do not count.

Someone who wants to be seen as delivering valuable BI projects, therefore will look for a project that delivers a set of benefits that drive value over a short period of time.  If the scope is too small, the benefits will be minimal.  If the scope is too large, the risk and time to deliver will be unacceptable.

I understand this is not a new finding.  The formula just lays it out in black and white.

In future posts, I will discuss how to estimate these numbers, even when people feel they cannot be quantified.