Best method to differentiate between AS-IS and TO-BE

[wivel]

I've encountered organisations using that Catalog/Projects aproach a few times.

They always had the same theory, and told me they where going to do that.

What I haven't seen is a working example of such an approach in practice. "Promoting" or merging the "project" stuff into the "catalog" stuff is almost impossible and definitely costs massive amounts of time.
Quite often there was this; "yeah we still have to merge that stuff" response.

Another major flaw of this approach is that you loose sight of your dependencies.
If Project A plans to replace a componentA, and project B plans to change some stuff on componentA. How and when will project B get notified?
All these types of inter-project dependencies are very difficult to manage if each project lives and works on it's own island.

That's what Ian is trying to solve with his add-in. So if you insist on this type of approach, I would definitely look into the Portfolio manager to get some automated support for this process.
If not I'm afraid this will only work in theory.

Geert

Maintaining relationships was the main issue we had with the 'make a TO-BE copy' of our processes. We also looked into time aware models, baselining and compare with the baseline, and none of the solutions was easily maintainable.

Still have not found a solution that fits and is easy to maintain.

Henrik

[wivel]

Still have found a solution that fits and is easy to maintain.

Henrik

I suppose you mean "have not found"?

q.

Yep. Have edited my post.

Henrik

[adamPL]

I manage a model of a system for our main client. Throughout the years, I managed only the "TO-BE" model, as the system is heavily changing. Modeling the "AS-IS" model seems impossible for now because it would generate a copious amount of work that would be thrown away as new projects are completed.

Once, we had a project that required to describe temporary state and then going back to the previous model. I managed to do it with Package Control and branching directly in SVN. Since the model is quite big (>150 MB in .qea file) and has numerous version-controlled packages, it required a lot of work to carefully update the packages. I don't recommend this approach, especially if the modeler's time is limited.