Our clients need an ability to respond to market demands and optimize reuse to deliver product lines of products. As products and systems become more complex, engineering effort multiplies.

• THINGS are getting Intelligent, Instrumented and Interconnected
• 6.4 billion connected THINGS in use by 2016 30% rise from previous year
• On-board devices runs 100 million lines of code in a premium car
• Layers of Products and Services, connecting as System of Systems, are delivers exponential value to a Smarter Planet

How can IBM Watson IoT make our clients successful?
Let me describe what we offer to our IoT clients.

Our clients need additional tool capabilities for managing artifacts and change in and across configurations of products across product lines

The Continuous Engineering solution provides tools that manage Requirements, Design models, Tests, Change Requests and Plans
Product line engineering adds configuration management to enable System Engineering teams to create platforms of reusable components and let product engineers work on changes for a given product variant

That all sounds a bit complex. In reality it’s even worse.
The challenge for design is to make this easy. Let me tell you how …

My 10+ years and deep engagement with clients in the Systems market have given deep insights into solution requirements and organizational pain points

My research by using Design Thinking methods and 1-1 interviews has provided key requirements to the design

PLE client needs

• Consistent baselines across all artefacts
• Define a complex product as a set of hierarchical components
• Scalable to 1000’s of configurations
• Non-intrusive to current engineering workflows
• Integrated into Continuous Engineering platform
• Links must work with versioned artifacts

Top ranked pain points

1. Keep configurations consistent across product line management and system engineering
2. Tracking and merging changes across product variants
3. Configuring a new product (today using copy)

Read more about the sessions we run at Innovate 2014 to validate PLE roles and personas and user experience maps.

Ream more about the PLE design validation and playback at Innovate 2014.

What PLE Hills and Personas did we state from this research?

My research and analysis led our design to two key System Engineering personas and three PLE hills

Susan the System Engineer

Charles the Chief Engineer and Configuration Lead

“With minimal impact to current usage, team members can select a configuration related to their plan and be confident that they are using the right artifacts and links.”

“Configuration Leads can define configurations of a product under development consisting of requirements, tests, designs and implementation.”

“Teams work in a scalable environment with 1000s of configurations consisting of artifacts managed in multiple tools and links within and across those tools.”

Lets decompose and digest those hills a bit…

Development of the hills needs to get into the product backlogs.

I worked with Program Management using the Scaled Agile Framework (SAF) to structure and track release plan artifacts, and their relation to the design artefacts.

• Offerings are tracked by Business Requirements
• Hills are decomposed to Epics and Features.
• Features are elaborated using design scenario acts and scenes • Features link to Stories in product backlogs

Using this framework solution team can go to plan with a set of Business Requirements tractable to product plans. And report bottom up on execution, state and risks. We can track completion of product stories and play back scenarios completed in a solution milestone

Learn more about how we are Adopting IBM Design Thinking for Solution Development on DeveloperWorks.

Now that we understand the planning of hills,
lets return to the PLE scenarios.

PLE scenarios derived from the research I performed with sponsors in Automotive, Aerospace & Defence and Electronics Industries.

• Act: Create a new product variant
• Act: Fix a defect and release a product fix pack

The scenario act outlines the following scenes:

• Scene 1: Request new product variant
• Scene 2: Create new product configuration
• Scene 3: Update product requirements
• Scene 4: Allocate product requirements
• Scene 5: Analyze impact on requirements
• Scene 6: Plan and run tests
• Scene 7: Report on product status

This scenario was chosen based on its business importance to our sponsors and to the overall design of the PLE solution.

The PLE design scenarios tells a story of a fictitious company JK Meters Corp, aspiring leaders of Smarter Flow Products. The Automated Meter Reader product line consist of manual, mobile and grid products delivered with regional variants to a global market.

The Automated Meter Reader products have been delivered to utility customers in US and EU. The variants are configured with regional requirements on power voltage, dimensions on pipe mounting, regional units of flow and volume, language configuration for the handheld meter readers and regional city maps for GPS routing. The ALM product team is, as the start of the scenario, kicking off the development of a new Mobile AMR product variant for the UK market.

How is this related to PLE and Configuration Management?
Let me tell you more.

Sample artifacts for the Automated Meter Reader product line was proven as a success factor for playing back the design and testing with running code.

• AMR product line with Manual, Mobile and Grid products
• Product variants for US, EU and UK
• Reusable components for subsystems
• Requirements, tests, design models and code

Weekly sandboxes integrated with latest build and configured sample data.

This design was proven to be a key enabler for all of the design practices; design scenarios, internal and sponsor user playbacks using live code, integration sandboxes for testing, beta programs, external marketing and user education material.

This all sounds theoretical. Can we be more concrete with acual IoT devices?

To validate our design and implementation I developed a demonstrator for the AMR sample using a Arduino Meter Interface unit and a Mobile AMR product.

The work gave benefits to the design

• Made our scenario more credible using IoT devices
• Provide artifacts for SCM use-cases
• Relate to artifacts for Tests and Test Environments

The User Experience Design created by the PLE designers was driven off and validated @scale using my PLE Scenarios

Our team based UX / UI design follows an established design driven workflow agreed by me, Jin Li and the product leaders.

• Scenarios define planned solution features and product stories
• Scenarios state the user experience
• UX design is documented in the PLE Release Blueprint
• Early low fidelity scenario sketches and high resolution UI specifications
• UX design is reviewed and approved by the PLE design workgroup
• UX consistency ensured by UI design
• Implementation of the UX design validated at milestone playbacks

Read more on the Configuration Management User Experience Blog on Jazz.net.

How are the design ensuring the success of the personas? Let me show the details

My research and early playbacks validated our hypothesis that we need to design for two types of Software Engineering.

• A software engineers may transparently be given a configuration context to work in for a given change request. Such an engineer will simply browse from the change request to the artifact to be modified, make the changes and deliver to integration.
• A system engineer will work with changing requirements. Understand the need to branch requirement baseline to create a product specific version and use configuration management actions to perform this action.

The PLE design teams created a configuration management menu to matches the required actions by role and permissions. We simplified the design on how to browse across plan items and lifecycle artifacts in the context of a planned global configuration

What about the other persona, Charles?

My research and early playbacks identified several usability concerns for Charles in his role as configuration lead. We designed an application targeting his needs. Separating this application from Susan’s workflows was a key design decision that I strongly enforced.

• Need to view and work with the configuration at any level, i.e. product, subsystem or component level
• Need to view and work with component variability, i.e. the component streams and baselines
• Need to view and navigate configurations on a per artifact type level, i.e. Local configurations
• Need to search, select and replace Local configurations when aggregating a Global configuration
• Need automation and let the tools do the heavy lifting at scale

How did we validate this design with our sponsors?

I continuously played back the PLE design. From Playback 0 to milestone playbacks. Closing up to the 2015 release we completed our 27th internal PLE playback.

Across these playbacks we presented to more than 250 participants.

The PLE project instituted a monthly playback schedule based on the development millstones and led by Design and Program Management. The playbacks presented market summary, release hills, scenario walkthrough using running code, sponsor feedback, and project risks and issues.

• Each Millstone Playback was delivered to
• Design, Product management and Development
• Sponsor Users
• CLM 6.0 Managed Beta

How did we act the feedback?

My user research and milestone playbacks highlighted the importance our sponsors put on UX consistency across the applications in the PLE solution

Based on sponsor priorities we planned the following areas for UX Consistency

• Consistency across icons, menus, commands and pickers
• Consistency in stream and baseline creation in CfgM pickers
• Consistency in Work Item link navigation to/from plan/configuration context
• Consistency in link creation, navigation and error handling
• We did not prioritize UX Consistency in the following areas • Use of private streams and change sets
• UI consistency improvements across Diff and Merge views • UI consistency in version tree viewer

Other ways we acted on the feedback?

During the delivery end-game I organized together with Program Management a complete final playback of every act and scene using running code. In total > 10h of playbacks.

• Played back to design, product management, development leads and to our sponsors
• Ranked the priority of identified issues
• Instituted a ‘UX cleanup’ process across teams
• Tracked UX design work plan in RTC

But design is never ‘done’.

What did we plan for the next release?

Our PLE playbacks early uncovered that some use-cases can be automated to improve user experience and productivity. We planned these improvements as a hill for the second PLE release in 6.0.1

• Susan needs tool automation when working with change sets in a in a personal configuration
• Charles needs tool automation when branching a global stream, or when creating a global baseline

Both workflows required initially > 20 manual steps across multiple applications in CLM 6.0 to be completed. The new design in CLM 6.0.1 simplifies these to one single step. A major user experience design improvement.