Critical Elements for Deploying Simulation Lifecycle ... Troy MI... · Critical Elements for Deploying Simulation Lifecycle Management ... Dassault Systèmes SIMULIA

© Dassault Systèmes, 2007

Critical Elements for Deploying

Simulation Lifecycle ManagementShawn Freeman - Dassault Systèmes SIMULIA

September 2007


What is Simulation Lifecycle Management?


Simulation Lifecycle Management (SLM)

SLM Means:

1. An integral part of a broad PLM strategy

• Bridge the gap in PLM for managing iterative simulation data

• Expose simulation IP outside of the product release structure

2. Leveraging Simulation IP:

• Capturing simulation know-how and related decisions

• Extracting and re-using the built-in value of simulation activity

3. Bringing Order to Simulation:

• Management of Data, Methods, Processes, and Tools

• Collaborative environment throughout the extended enterprise

4. An Open Platform to Manage and Deploy Applications:

• Workflow chaining and job submission

• Open connector architecture for 3rd party integration


SLM Maturity

Data anywhereData anywhereSimulation Data

Management

Simulation Data

Management

Simulation Process

Management

Simulation Process

ManagementDecision SupportDecision Support

FilesFiles

ManagedData in Context

ManagedData in Context

ManagedProcesses

ManagedProcesses

Managed Performance

Attributes

Managed Performance

Attributes

+

+

+

Unmanaged files Traceability Automation Design to target

Program & non program data

Formal & ad-hoc

Simulation driven performance attributes

Islands of unconnected data

Simulation Lifecycle Management (SLM)

System Dashboard

Targetk � ��

Targetl ��

Targetm � � �

SimulationProduct

MarketingRequirements

PerformanceAttributes

Target


Why SIMULIA for SLM?

A Leading Global Provider of Realistic

Simulation Technology

The Leading Global Provider of Enterprise

PLM


SLM Deployment Requirements and

Considerations


SLM Deployment Requirements and

Considerations

1. Select a mature SLM use case (don’t invent and validate simultaneously).

2. Set appropriate (attainable and realistic) goals.

3. Define “success” and how to measure it.

4. Allocate time (effort and staff) up front and separate from normal duties.

5. Select a vendor with PLM and Simulation capabilities.

6. Stage development/deployment into “bite size” chunks.

7. Engage in a “Phase 0” requirements definition effort.

8. Include stakeholders from all relevant organizations (e.g. IT, engineering, design).

9. Utilize Project Management tools and techniques throughout.


Key Elements

Presented within Project Management

Context


What is Project Management?

Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.

� Excerpt from PMBOK (2000 Edition): Project Management Institute (pmi.org)

Project Management is the proactive resolution and mitigation of conflicts that result from people being intelligent, motivated, and individualistic.

� My definition, based on past experience ;-)


Typical SLM Project Phases

Identify Need

Gather Requirements

Plan

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Each phase requires sign-off before the next can begin…


Key Elements

• High level definition of the scope (what you want to accomplish).

• Approximate timeframe to complete high-level milestones.

• ROI and/or other benefit estimates.

• Identify the internal stakeholders (design, engineering, IT, business).

• Identify the executive sponsor.

• Identify the internal project manager.

Create a Project Charter document to capture and communicate this information to the organization. Include in this document:

• Reasons for undertaking the project

• Objectives and constraints of the project

• Directions concerning the solution

• Identities of the main stakeholders

• Assign the authority to undertake this project to the internal PM

Identify Need


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Requirements gathering can be viewed as a small

project in its own right!

Gather Requirements

Plan


Gather Requirements

Requirements tell us what we would like the solution to do.

Example requirements for an SLM solution:•Version controlled documents•Collaboratively share information anywhere in the world•Integrate with 3rd party simulation applications•Support corporate retention policy for simulation items•Provide impact traceability between simulation items•Simplify finding the right data quickly

Requirements are the desired characteristics of the solution being developed. Requirements are NOT application specific.


Key Elements

• Utilize a “Phase 0” effort with the vendor to capture requirements for the SLM pilot.

• As a customer, focus on explaining your use cases.

• Describe what you do, and how you do it (tools, processes, environment).

• Identify any pain points or other opportunities for improvement.

• Define metrics to be used in measuring project success.

• Develop an adoption plan - gain buy-in from stakeholders, and consider training, user support, and management support.

• Have the vendor lead the Software (Solution) Requirements Specification (SRS) generation (make it a Phase 0 deliverable).

• Have the vendor map the use cases to the documented requirements.

• Iterate as needed – sign-off when complete.

• Vendor will generate a proposal for the SLM engagement.

Gather Requirements


Gather Requirements

What the customer wanted.

How the Customer explained it.

Take away:•An SRS, as a Phase 0 deliverable, should be application neutral.•Vendor’s proposal should include a Statement of Work (SOW) describing the “to be” system (iterate on this as needed).•Create and publish adoption plan for SLM.


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Every project should have a kick-off

meeting!

Gather Requirements

Plan


Initiate the project with a kick-off meeting

The kick-off meeting sets the stage for the entire project engagement

and eventual success:

• Introduce the team and their roles.

• Reiterate the objectives of this project.

• Reiterate the project scope.

• Define/agree to document templates.

• Or a timetable to do so.

• Draft a communications plan.

• How to communicate (e-mail, face2face, WebEx, …)

• When to communicate (regular meetings, specific events, …)

• Printed publications (sign-offs, press releases, minutes, …)

• Establish action items to bridge work effort to the project plan.


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Gather Requirements

Plan


• At the start of this phase, a signed-off baseline plan must be completed.

• The plan should be jointly owned by the vendor and the customer.

• Tasks in the plan include both the vendor tasks and deliverables as well as those owned by the customer.

• Create a risk management plan.

• Document the change control process.

Plan (and track)

This phase of the project management process, focuses on defining

clear, discrete activities and the work needed to complete each activity within a project. Planning is an ongoing effort throughout the life of a project.


• Converts the SOW into discrete tasks and assigns responsibility for each.

• Provides a detailed scheduled of when tasks and milestones are expected to be accomplished.

• Provides a means to track the progress of the SLM project.

• Example tasks (and ownership):

• Deliver sample data to team (customer)

• Validate sample data (vendor)

• Establish source management (vendor)

• Documentation review (customer)

• Test plan creation (vendor)

• Test plan review / exercise (customer)

• Provide server hardware/software requirements to IT (vendor)

• Acquire test server and install in datacenter (customer)

• Acquire RDBMS and install on test server (customer)

Plan (and track)

Why is the plan such a critical element for SLM deployment?

Forces the team to think through the tasks and their inter-dependencies.


Change management:

• All proposed changes should include:

• Cost

• Impact to schedule

• Impact to functionality (will something else be dropped?)

• Changes must be agreed to and approved by the stakeholders.

• Even the changes that don’t cost

• Changes that are deferred should be tracked as Request For Enhancement (RFE) for a future project.

Change happens:

• Change itself is not a problem. Uncontrolled change is!

• Scope/feature creep.

• Use change management to document and record such changes when they occur.

Plan (and track)


Risk management:

• Identify risks

• Score them by likelihood of occurrence.

• Score them by cost (estimate if exact cost is not known).

• Rank and categorize them.

• Deal with them, or have a plan to deal with them

• Eliminate – remove risk proactively (duplicate data).

• Mitigate – lessen extent of damage or likelihood of occurrence (backup data).

• Tolerate – also know as “accept” (we will lose data, but the probability of such an event is small).

• Transfer – assign the risk to another entity (hire Iron Mountain to safe guard data).

Plan (and track)


Take away:

• Project Plan (sign off)

• Change control process (and change order templates)

• Risk Management Plan

• Issue tracking (system)

Plan (and track)

How the Project Leader understood it.


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Gather Requirements

Plan


• The Design is what will ultimately be implemented as code and delivered to the customer.

• The Design may not capture all of the solution requirements.

• Document where it deviates.

• Document why it deviates.

• At this time, the customer should provide sample data and tools that will be given consideration during the design process and used for testing later.

Design

Design a system that will satisfy the given requirements to the

extent possible.

Take this opportunity to mock up potential solutions and iterate between the vendor and customer.

Some suggestions may require change management, others may need to be deferred to a future project (log both into the issue tracking system).


Take away:

• Functional Design Document (user facing – sign off)

• Detailed Design Document (developer facing)

• Draft Acceptance Test Plan (based on SOW use cases)

• Draft Documentation

Design

How the Analyst designed it.

Are we there yet!??When do we actually start to implement the SLM solution?


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Gather Requirements

Plan

20%

40%

40%


This is why…

When candy giant Hershey Foods former CEO and Chairman Kenneth L. Wolfe told Wall Street analysts during a conference call in September 1999 that the company was having problems with its new order-taking

and distribution computer system, a $112 million combination of software from ERP maker SAP, CRM provider Siebel and supply chain software from Manugistics, he didn’t offer any details. He did say,

however, that the problems were going to keep Hershey from delivering $100 million worth of Kisses and Jolly Ranchers for Halloween that year.

Here’s what former CEO Wolfe (he retired in 2001) should have said in 1999: Enterprise software is hard. It takes a long time. It’s hard to get people to change the ways they work so that the system will function correctly. But they eventually adapt. And you will have problems in your business at first because enterprise software isn’t just software. It requires changing the way you do business.

�� Excerpts from www.CIO.com article (2002): Supply Chain: Hershey's Bittersweet Lesson


Elements of the Construct phase:

• Setup and configure test environment (if not already done)

• At the vendor and the customer site

• Codify the design

• Customization

• Configuration (roles, lifecycle, security, application integrations).

• Utilize Source Code Management (SCM)

• Track progress against the plan

• Regular reviews

• Vendor – code level

• Customer and Vendor – functionality

• Unit test

Construct


Take away:

• Regular progress demonstrations

• Iterative code review

• Change control documents

• Enhancement requests

• Alpha system

• Acceptance Test Plan & Documentation updated

Construct

How the Programmer wrote it.

How the project was documented.


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Gather Requirements

Plan


Test

System/component testing ongoing through Construct phase and

demonstrated at regular status reviews (e.g. over WebEx if needed).

Alpha

• “Code complete” and ready for early validation.

• First “official” deployment to customer test server.

• Buggy � Log and track issues using the issue tracking system.

Beta N

• Mid-stage Beta suitable for training and documentation finalization.

• Late-stage Beta suitable for Acceptance Testing to determine production readiness.


Test

Take away:

• Open issues log


• Deployment ready system

• Acceptance Test Plan (updated signed off)

• Documentation (updated and signed off)


Project Phases

Identify Need

Design

Construct

Test

Deploy

Maintain

Internal

Phase 0

Implement

M&S

Gather Requirements

Plan


Deploy to production:

• Move/install system to production environment.

• Re-validate.

• Review project history:

• Lessons learned

• Open issues


• Sign-off on closure.

• Maintenance proposal, if not already covered in original proposal

• Possible RFP and Proposal for next phase…

Deploy & Close


Deploy & Close

Take away:

• Open issues (errata)


• Production (pilot) ready system

• Project Closure (sign-off)

• Execute Adoption PlanWhat Operations installed.


Project Phases

Identify Need

Design

Construct

Test

Deploy

Internal

Phase 0

Implement

M&S Maintain

Gather Requirements

Plan


Maintain

M & S:

• Ongoing maintenance to fix errors (deviations from the original design intent).

• Support for migration and upgrades (of the system, 3rd party apps, OS).

• Try to avoid adding new functionality under maintenance agreement.

• Better to establish separate projects for feature additions.

• Establish a parallel validation environment for testing of patches before production deployment.

• Have a data/system migration plan.

• Have a backup plan and schedule.

How it was supported.


Final Thoughts…


Cartoon from:

http://www.umsl.edu/~sauterv/analysis/


Thank you!

Special thanks to:

Dan Turk – Honda R&D N.A.

John Kerins – Kimberly-Clark

Lou Long – Actano

Mike Patterson – General Dynamics Land Systems

Fred Merceron, Bruce Hart, and Mike Ricci of Dassault Systèmes SIMULIA


Additional Material


Simple tools can help – Earned Value Management:

Images taken from Wikipedia.org

Plan (and track)


Simple tools can help - Poor Man’s Hierarchy:

1

0

3

2

4

Score

0

1

1

1

Replication

4th1000Replication

5th000Federation

2nd110Docs

3rd100API

1st111Doc

Mgmt

RankFederationDocsAPIDoc

Mgmt

Gather Requirements


Tools of the TradeInclusion does not mean endorsement!


Tools (software) to help

There is a large and varied collection of project management tools available to help you along.

Commercial tools often include training, support, and easier setup/install. Many offer free trial periods so that you can determine if the tool is right for you.

Free/Open Source Software tools sometimes offer training and support. They are usually harder to install, but are “free” to use and modify.


Tools (Commercial)

ENOVIA MatrixOne Program Central and Specification Central

http://www.matrixone.com/matrixonesolutions/programcentral.html

IBM’s Rational suite

http://www-306.ibm.com/software/rational

Microsoft Project and Project Server

http://office.microsoft.com/en-us/project

Actano RPlan (project planning, resource management, project control, time recording and reporting)

http://www.actano.com


Tools (FOSS)

Requirements/Test planning/Use cases

• OSRTM (http://www.osrmt.com)

Source Code Management (SCM)

• SubVersion (http://subversion.tigris.com)

• Git (http://git.or.cz)

Issues (defects and enhancements)

• Double Choco Latte (http://dcl.sourceforge.net)

• Bugzilla (http://www.bugzilla.org)

Project Planning

• Open Workbench (http://www.openworkbench.org)

All-in-one

• dotProject (http://www.dotproject.net)

• Tutos (http://www.tutos.org)

Check here for more:http://en.wikipedia.orghttp://sourceforge.net


S.M.A.R.T.



Simulation Lifecycle Management

• Establish SMART goals for the pilot

• S = Specific

• M = Measurable

• A = Attainable

• R = Realistic

• T = Timely




• Be specific

• What do wish to accomplish from this effort?

• For example:

• Evaluate candidate vendor’s knowledge of PLM within a Simulation context.

• Plan for a production ready deployment for the product X development team.

• Validate that the product feature set and roadmap is in alignment with specific business and technical requirements.




• Be specific

• Why is this important to the organization?

• For example:

• Need to move from design to final product 6 months quicker.

• Government/legal/other rules and regulations requirements must be met (EAR/ITAR, FMVSS, NCAP, RoHS).

• Lack of cohesion in product development process causing significant added cost of $5/part.




• Be specific

• How are these goals to be accomplished?

• For example:

• Stream-line data transfer to remove 5 days from cycle time.

• Implement access and retention policy to ensure that the right people have access to the right data.

• Improve communication through instant messaging technology.




• Be specific

• Avoid generalizations where possible.

• Reduce cost vs. Reduce part cost by $5.

• Get to market quicker vs. Trim 6 months off of development.

• Improve quality vs. Maintain >99.95 uptime per 24 hour window.




• Select measurable goals

• Lose weight by the holidays vs. Lose 5 pounds by the New Year.

• Set intermediate goals to collect “wins” and build confidence.

• Lose 2 pounds by July 4th.

• Track them over time




• Goals must be attainable and realistic.

• Achieve CAFE of 55 mpg by 2009.

• Attainable (sell only golf carts).

• Realistic?

• Achieve CAFE of 33 mpg by 2009.

• Realistic (hybrid technology, other).

• Attainable (probably not by 2009).




• Timely

• Establish a time frame (schedule) with intermediate milestones.

• Must be attainable and realistic, but should also satisfy business requirements.

• Consider reducing scope or increasing the schedule where needed.

• Track success against schedule.

• Be honest with slippage and communicate appropriately.

Documents

Critical Elements for Deploying Simulation Lifecycle ... Troy MI... · Critical Elements for Deploying Simulation Lifecycle Management ... Dassault Systèmes SIMULIA