Best practices for project success

Content

Defining successful projects

A successful roadmap helps to balance precarious project elements, such as time and skill against complexity and risk. In order to motivate technology, you need to define an approach that progresses value as you work to bring new technology forward.

Figure 1-1 Project lifecycle

Setting timelines, scope, focus areas, and success criteria are “must-haves”.

 
The best approach for most technology is to funnel the business value through a series of discussions with a balance of business and technical involvement. Technology influences the business decision and ultimately the business decides whether or not to invest. Starting small and building on interest and business value ultimately lead to a successful implementation.

• IBM Demos provide a wonderful set of Videos, product Tours, and Hands-on Labs that greatly simplify and offer the ability to actually exercise technology without levels of investment required for local infrastructure, capital, and operating expenses.
  https://www.ibm.com/demos/search/?products=%22IBM%20Data%20Virtualization%20Manager%20for%20z%2FOS%22&lc=en 
• Deep dive presentations by IBM and Business Partners help to orchestrate a lower-level discussion that details how DVM for z/OS matches well for their environment. This is a perfect time to uncover the primary use cases.
• Deep dive Demos by IBM and Business Partners are well-equipped to demonstrate an array of functionality.
• Proof of Technology – IBM has internal lab environments that can be leveraged to demonstrate capabilities and expose on-Z and off-Z sources via modern APIs like SQL, JSON, HTTP, and REST.
• Proof of Concept – Not every project requires a fully invested project plan, in order to prove out the value to the business. A real concept requires that the business map a project with key milestones, systems, data, infrastructure, and human capital to become realized.

Proof of Concept checklist

Any project is an investment commitment and agreement between groups with a mutual goal in mind. Focus on a simple checklist to drive the concept forward.

Timelines

• Target 90 days maximum for proving your project
• Weekly checkpoints are critical to ensure there are no issues
• Keep the pulse of key stakeholders throughout the project schedule
• Have successful milestones

Setting scope

• Keep the project well defined
• Document of Understanding (DOU) template has carefully identified sections
• Scope creep is the #1 reason why projects fail

Focus

• Focus on the business use case
• Technology is important specific to the configuration
• View the project entirely as a solution, not as a “product”

Success criteria

• KISS (Keep it Super Simple) is a perfect model to follow
• Keeping the project simple in scope and concisely establishes reasonable goals and timely closure
• Success shouldn’t be ONLY performance-based
• Provide an executive summary

Best practices

• Incorporate measures from an alternate or Today’s state of business for comparison with DVM
• Over-communicate the project scope and estimate the required effort
• Avoid poorly documented DoUs, which lengthen and introduce ambiguity into the project

• Maintain regular checkpoints to keep the project on track and heading in the right direction
• Consider monitor performance through SMF, in order to validate “do no harm” impacts on production
• Make sure your data sources are accurate and current by avoiding staging or copying data
• You’re on track if you start with simple access and query results
• Be flexible. If the initial use case fails, it is typically followed by other uses that have positive impacts
• Success can breed scope creep, stay on track and close out the current project. 
• Be sure to really rationalize the use cases because a poorly defined use case can deflate the project

Below is an agreed framework that helps to drive an overall comprehensive approach for a proof of concept. The agreement has specific sections that capture all elements from requirements, use cases, and business drivers, and closing criteria.

Roles and responsibilities

Failure to define roles and responsibilities is the downfall of any project. Without the “who” and the “what” success will be hard-fought.  With this in mind, assign a name to each role on the project team. Identify at least one (1) project manager and ideally two (2) that complement or bridge the technical team to the respective line of business. With this, the scope, project velocity, key milestones, and results are always visible.

Table 1-1 Role and Responsibilities 

Define a detailed timeline and project plan, in order to maintain periodic status calls and checkpoints. The success or failure of your project could depend on this frequency. A weekly call for 30 minutes at a time is recommended to help speed up the resolution of issues.

Installation
Installation for both the DVM SQL engine and administration Studio is simple and straight-forward. DVM for z/OS SMP/E installation is very quick and the DVM Studio is an MS-Windows point-and-click installation that is fast and easy.

Configuration

1. Always perform IVP sample VSAM virtualization using the DVM Studio
2. Upon startup be sure to read the DVM started task SYSOUT carefully
3. Only configure what you need
   • Change or activate only required IN00 sections
   • No need to configure JGATE if there are no external or relational data sources involved with the project
   • No need to configure Db2 for z/OS if it is not part of the project, regardless of benefits derived by IDF or Db2 UDTF

Architectural topology
The architectural topology should be discussed with your project teams and upline business owners to ensure you have a schematic that represents reality. Working with Systems and IT operations team members, you should be able to build out a facsimile of the current environment.  Additionally, the project team should ensure that all endpoint client access is clearly identified with the associated access method and data flow, including all staged and non-staged READ/WRITE activity.

Figure 1-2 Sample Topology

Defining Use Cases
Functional vs performance-driven use cases
When defining use cases for your project put more emphasis on functional aspects than performance-driven characteristics. There are instances where performance metrics are extremely difficult to measure. You want your project to be configured in a non-production environment if at all possible. If the number of zIIP processors is limited, then DVM workloads could be executed by General Processor engines.  If performance testing is unavailable, work to ensure your tests are measurable and well defined.

No. of use cases
Limit the number of use cases to two (2) if possible and allow for up to two (2) separate tests for each use case. For example, using two Db2 for z/OS tables and two VSAM virtual tables. Remember that your project is not a surrogate for production-ready development and testing.

Working with VSAM and Sequential file sets
When working with either of these sources, limit the scope to the number of virtual tables, instead of data segments, as there can be 100s of copybooks associated with a single VSAM file. Application developers must be involved in your project and sample copybooks and data are the first requirement, in order to validate the data set and determine any invalid data or data types.

Client Access - typically, businesses are seen to work immediately with their critical business applications. It may be just as effective and shorten the testing intervals by using common tools and utilities. In these cases, leverage ODBC/JDBC SQL driver. Consider using DVM for z/OS as a data pump to supplement ETL tools.

Data integration – use a maximum of 2 virtual tables for extracting large data sets using the JDBC driver. Consider using DVM for z/OS as a data pump for ETL tools.

Read-Write access - DVM for z/OS can also WRITE back to original data sources. This is a good way to simulate transaction-based activity using the DVM Studio.

IBM Cloud Pak for Data – use the DVM connection service with DV, Watson Knowledge Catalog, or Watson Studio to experience the full power of IBM’s new platform architecture built for the Hybrid Cloud.

DVM as an Application Server - Use DVM as an application server via IDF for DRDA access to Z data

Best practices for defining success criteria

Concluding the POC
Once your project has completed the evaluation phase, the project should result in a clear set of tangible assets that speak to the original problem statement, milestones met metrics, and results that will clearly articulate the value proposition and impact for the business.

Finalizing deliverables
A first step would be to verify acceptance with your stakeholders or project sponsors and determine if any extensions or additional testing during deployment should be amended to the current agreement for the project. We call this the Document of Understanding (DOU) framework.

Create a full disclosure report and present it to key decision-makers that include the following:

• Summary of the project scope
• Clearly re-emphasize the Success Criteria and results obtained
• Visuals – performance charts, metrics, etc.
• Customer User Feedback – quotes

Review the report with the technical sponsors for the project before delivering it to key stakeholders in a larger audience. Work to ensure that all agreement details were met for the overall sentiment of success criteria and results.

Assuming that the goals have been achieved and the success criteria were met, continue with closing the project with clearly defined next steps for deployment.

Sample project timeline

What was evaluated?

Business value (samples)

• Access to combined relational and non-relational data sources on z/OS in real-time for downstream analytics and reporting. React to business demands quickly.
  • Offload VSAM data and merge with Db2 LUW data used to take 2 days end-to-end
  • The daily summary report now occurs in real-time with less than five (5) minutes of transaction latency.
• Leveraging existing infrastructure, processes, and people
  • Eliminated VSAM data movement to x86 environment and save time and personal hours
  • No additional infrastructure cost required to access data in place, while maintaining SQL compatibility
• Provide real-time access for BI solutions instead of working off of out of date, inaccurate non-Z data
  • BI solutions and Z solution can all see real-time data
  • Access is fast and cost-effective
  • Greater than 95% offload to zIIP processors with lowered costs

Business and sponsor quotes
Be sure to capture positive statements by business stakeholders as you progress through your project. The bottom line is often driven by the positive perception and actuals that are captured. TCO and savings are always critical factors in the success of a project. Additionally, performance places a critical factor, but always incorporate the user experience and overall usability of your solution. Below are some possible outtakes from your project that you need to collect and present back to the business:

• Setup is simple and straight-forward for those with TSO access
• Mainframe access was immediate
• User experience was identical regardless of data source
• Benefits derived from zIIP specialty engine offload without having to create special processing