Planning a successful iLogic project

Suffice to say, when it comes to implementing iLogic, the benefit of upfront planning can be the difference between a successful implementation that meets well-defined objectives and a failed project, where objectives are missed and time is wasted.

In this post we will give some indicators and guidance on how you can put together a plan for an iLogic configurator project.

Define the domain

Our first stage is to identify the goal and set specific, measurable objectives that need to be achieved to realize that goal. We can start with a clear statement of the current problems and ‘as is’ scenario.

It’s important to recognise at this stage the amount of time and resource available and the complexity of the tasks in hand. If necessary, for understanding and simplification, break your objectives down to manageable tasks that can be implemented as distinct iterations, “Eat your elephant in bite-size chunks”. Prioritize what areas will give the best return on the investment of your time and identify the time required to achieve a minimum viable product at each iteration.

Also, remember the 80 20 rule that 20% of our activities will result in 80% of our results. It may be that the effort required to achieve that final 20% for a perfect result doesn’t give a valid return for the effort required.

Our objectives and measures form our first step in defining the domain of our project, and what success will look like.

We should also identify who the stakeholders are for this project – not only who will use it but who does it impact.

It is beneficial to identify the constraints that exist on our project, which is typically the time available, expenditure limits, and resource availability.

Also, important, is to identify what external factors could impact our project; the risks posed by what might change, and what negative impact our project could have.

If others are involved in the project will they understand the terminology used in this domain definition? If necessary, keep a glossary for any acronyms and terms that may not be universally known or could be potentially ambiguous.

During the project, there may need to be assumptions made. It is important to record these assumptions and verify them with others if possible.

Functional and non-Functional Requirements

With our objectives set we can identify our project requirements. These requirements break down to two types, functional and non-functional requirements.

Functional requirements define how our configurator must behave and are used to define our model rules. More on those later. Non-Functional requirements are all the elements that are additional to the behavior requirements:

• Look-and-feel requirements that determine the product’s appearance.
• Usability and humanity requirements relating to the product’s ease of use and any special usability considerations such as user expertise.
• Performance requirements will determine how fast, how safe, how accurate, how reliable and how available the functionality must be.
• Any operational and environmental requirements, which Inventor version must it be compatible with for example.
• The maintainability and support requirements – what could be expected to change in the future, and the time criteria to apply changes to the product.
• Cultural requirements - special requirements that come about because of the people involved in the product’s development and operation. Is there a requirement for a multi-lingual interface for example?
• Legal and/or Standards requirements – any impact to conform with any appropriate laws or standards that are in appliance.
• Security requirements - the security and confidentiality of the product.

For each of our requirements, we should identify priorities for which need to be implemented at each iteration. Here we can apply the MoSCoW principle to help clarify what each iteration needs to achieve:

• Must – What must be achieved for minimum delivery of the iteration.
• Should – What is expected to be included for this iteration.
• Could – Given any resource still available what could be additionally achieved.
• Won’t – What will definitely not be included at this iteration.

From Requirements to Implementation

Once we know our requirements, we can take the next step to plan our design. Specifically, we need to distinguish:

• Inputs - the changeable values that will drive our models and their value options. These identify our key parameters.
• Outputs – any required deliverables that are needed to be produced.
• Models and other files required – existing or new models.
• Rules – Design rules and process rules.
• Interface – How users will interact with the configurator.
• Tests – what testing is required and valid to confirm correct operation.

Rules

There isn’t a limit to the number of rules we can add, so we would recommend that a rule is established for controlling one specific function of the configuration and named appropriately. This will help maintainability in the future.

When determining the rules required, we can break down our rules to specific types:

Design Rules

• Size Limits – rules that ensure models are within minimum and maximum allowable sizes.
• Feature functions – rules that affect the features active in our components.
• Component functions – rules that affect the components included in the configuration and their positions and constraints.
• Information functions – rules that affect properties such as materials and appearances.
• Conformance rules – rules that ensure the combination of inputs entered produce a valid model design or provide feedback and/or actions if they don’t.

Process Rules

• Output rules – rules that automatically produce the valid export formats required.
• Drawing rules – rules that determine sheets, views, annotation and any other information displayed correctly on the drawings.
• Import rules – rules that import information from any other source that will determine the design configuration.
• File rules – rules related to the saving, copying and managing of the configuration models being generated.

It is also important to determine the location of the rules themselves. Rules should be located in the same file as the feature or component they are driving where possible. Parameters can be passed down from levels above to trigger the appropriate rules.

Test

Once we have implemented our iLogic model our final stage is to test before we use it in a production environment. We can create a test plan before implementation to give us the criteria we need to test and confirm against to determine if we have a valid product that meets our iteration requirements.

Typically, with iLogic this will involve parameter value tests. It is not often that every possible parameter combination can be tested so we determine to test at the limits of, and just outside of parameter limits, and with known conformance combinations. Our test record will detail each combination of parameter values tested, along with the pass/failure criteria based on the expected result.

Testing though must also include other tests to ensure the non-functional requirements are met – for example user interface testing and performance testing. It is important to ensure the tests are measured against and within the measures set in the objectives, not based on subjective factors.

Summary

So, in summary, our iLogic project needs to go through analysis, followed by design planning before we begin to try to implement within Inventor. Once implemented we then need to ensure our test criteria are met before moving on to the next iteration of requirements.

There are equally other considerations to consider through all iterations. The future maintenance of what we are implementing should be a consideration in how we implement our rules. A project that once implemented will not change or will only be required over a short lifespan will not require the same maintenance considerations as a product that will have more regular updates.

Equally quality management should be implemented to ensure consistency across the project. This is for example setting standards on any naming conventions for files, rules, parameters, features etc. Conforming to standards ensures a common approach on a multi-user project but also the consistency shortens development and maintenance times.

The other aspect, and typically the most neglected on internal developed projects, is managing the project ensuring key milestones are met and the project stays within time and scope constraints. Often pressures of day-to-day production override the project task requirements so our project slips. We’re all too familiar with being too busy cutting down trees to sharpen the axe, but at some stage, the lack of automation affects our resource availability to develop new products or lose competitiveness in our marketplace. At the point where it becomes impossible not to prioritize the automation, it may already be too late.

“The time to repair the roof is when the sun is shining.” – John F. Kennedy

Applying good project management practices to an ilogic project and ensuring that timelines are kept is as important as the technical detail of the project implementation. It should be considered as per any other project being implemented within the business be that internal or external. In our experience trying to ‘fit in’ with existing day-to-day work is rare to come to fruition unless the project or iterations are small.

Within this blog, we have provided a number of recommendations regarding planning for an inventor iLogic project. Not all aspects though will be applicable to all projects. It is important that the level of planning is appropriate to the project and that our plans are just sufficient for us to implement and meet the objectives.

“A good plan today is better than a perfect plan tomorrow.” – George S. Patton

How Symetri can help

Often when following this process, it can become clear that other limitations can impact on the ability to deliver iLogic configurators through internal development. It can be clear that the time investment required could not be met without impacting other critical activities or that the level of expertise in iLogic isn’t sufficient to identify and/or implement the required rule model.

If the ilogic project is important to complete, then Symetri can offer training and consultancy services at a number of levels to assist. I recommend these two services to assist you:

- Product configurator creation to support sales engagements with customers
- Product configurator creation to support automated design documentation production

We also have our new agile development service where we can work with you to fast-track development:
Inventor iLogic agile development