Defining Lifecycles: Help!

[mdebower]

We are currently on Windchill 10.1 and are running a pretty OOTB configuration. We are also starting a project looking at configuration changes and small customizations that we can do to make life easier.

One of the things we "THINK" we would like to change is our OOTB lifecycle. I know the mechanics of the lifecycles, states, promotes, revising, etc.. But not the WHY part of it.

So for example, in the design process we start with alphabetic revisions and then switch to numeric revisions at release to production.

Most of the engineers want a very simple lifecycle [Design][Released][Canceled].

I am trying to make the arguement that since our business needs are to have a 2 phase revision scheme that we need a 2 phase lifecycle with alpha first and then numeric. [Design][Alpha Released][Numeric Released][Canceled].

I lack the knowledge to give them sufficient reason to accept the more complex lifecycle. Any information or resources I could go look at that will help to answer the question: WHY?

-marc

[MikeLockwood]

We have had this in production for 7+ years (state-based versioning with two-phase lifecycle). Unfortunately, a bit complex to set up, but critical to the business to get right.

I've done multiple PTC/User presenations on this - can send you some files.

Don't know how to do so here yet - easy with the exploder - which is going away. email me direct if you like: mike.lockwood@alcon.com

[mdebower]

Mike,

Thanks for answering, I know it is critical. But the question I am getting is why is it critical?

-marc

[Marco_Tosin]

Mike,

if you want to attach some file, after clic on reply, choose "Use advanced editor" and then you get extra menus.

In the lower left corner you'll get what you want.

Marco

[MikeLockwood]

Wow - Great addtional editing tools - didn't know abou them - thank you for pointing out. I would have attached lots of files in the past if I'd known about this.

One file attached - tip of the iceberg on this concept.

[kpritchard]

I've looked at state based versioning before but not implemented because previous WC versions did not (to my knowledge) bump the Revision when the State changed (i.e. Object was "Promoted"). Another factor was that sometimes you just want to get to the end game (Numeric Rev in your case). That being said, it is attractive in that you can get away from the file based Revision Sequence and the Documentation does show how to do an automatic Revision.

Are you sure you need different States for Alpha and Numeric Revisions? Does State="Released" + Rev="A", and State="Released" + Rev="1" communicate the same thing as State="Alpha Released" + Rev="A" and State="Numeric Released" + Rev="1"?

If the end goal is to differentiate editable - not editable - dead, then the Lifecycle you have probably does the job.

As an adder, I recommend using "In Work" instead of "Design" if you ever get to WTParts because then users, especially casual ones get confused between the Design State and the (Design) View.

[LoriSood]

Hi Mark,

It looks like Mike and Keir gave some pretty useful information here. Was it enough to get you what you needed? If so, it would be great if we could mark this thread as answered with the answer provided.

Thanks!

Lori

[mdebower]

Lorry,

I agree, great information so far and I have a couple of additional questions:

1. What are the benefits of creating a more complicated lifecycle over a more simplified one?
2. Can someone provide some examples of what a complicated lifecycle allows them to do?

-marc

[kpritchard]

Marc - there are many ways of "complicating" Lifecycles. The answer may depend on what you mean.

Advanced Lifecycles allow you to attach a Workflow to a Given Phase (State) and Gate, as opposed to Basic Lifecycles that do not have a Workflow capability. Typically Objects with a Basic Lifecycle (which is different than the Lifecycle named "Basic") have States changed by either or both of Change Management Objects/Workflow or Promotion Request. Benefits of "Advanced Lifecycles from enabling a Document specific Workflow so that a Document can be Reviewed and "Released" outside of a Change notice or building your entire Enterprise product Development Process into the Phases and gates of a Product or project Lifecycle.

If more complicated means adding States... then ultimately the benefit of the additional States would be to communicate the level of believability of something and/or control access permissions for different Users. An example of this would be a Multi-Phase Development Lifecycle where the each State is communicating a level of maturity. If your company does not use a Multi-Phase Development Lifecycle then there is no audience expecting that levels of maturity be communicated, so simpler is probably better.

[mmontgomery]

Keir,

Different Marc here, we've been tweaking our OOTB install of WC Essentials 10.2 and our current life cycle is like this:

-In Work->Under Review->Released->Obsolete

-We revise back to Under Review from Released with the associated bump in rev level.

-Each phase only has the option to jump to the next one (no skipping or going back)

Currently our only promotion process is the Promotion Request Approval Process. This works fine for the In Work->Under Review and Under Review->Released steps but once we reach the released state I'd like to have another option for a "Revise Approval Process" to formalize our revision process. Is there a way to only show the promotion process required at each step? I think this has to do with advanced lifecycles however I can't seem to get it to work. These are the templates I'd like to have associated with each phase:

-In Work->Under Review: Promotion Request Approval Process

-Under Review->Released: Promotion Request Approval Process

-Released->Under Review: Revise Approval Process

-Released->Obsolete: Promotion Request Approval Process

I don't want to have Revise Approval Process shown in any other state than Released, is this possible?

Thanks,

Marc

[mmontgomery]

So in reply to myself, I think I found out one way to accomplish what I want to do and its not by editing the lifecycle. What I've found is that I can define the specific workflow I want to be associated with the specific life cycle by defining it at the Site level via utilities>promotion preference management. From there you can select the state of the lifecycle you will be moving to and select what workflow you want associated with it. This may be newbie knowledge however as I'm basically self-teaching myself windchill administration as I can't find any good resources on the subject. Here are pictures of the lifecycle I'm working with and the promotion preference management screen: