Clarity

We are moving to having Open Workbench as our standard desktop scheduling tool. We do have instances when we need to share the project schedule to someone who uses MSP.  I tried saving the OWB file to XML and opening into MSP with no success.  I thought it would be just an easy save as and then open XML, but apparently am missing a step.  I thought I would reach out and see if anyone else has been successful in doing this and if so what steps would need to be taken.

Art

Hi Art.

   To accomplish this we have a few users with both OWB and MSP installed and they have the ability to change what they can open a project's schedule in. When they need to send an MSP schedule to a vendor, they simply change the client tool type and open in MSP read only.

    If anyone outside of these users needs their schedule in MSP, they email me or open a ticket and I follow the process above.

  Here's an Idea where I dreamed aloud for the 'open with' capability to be able to be controlled with more granularity, like with checkboxes. We find this read-only MSP pretty handy and wished we could share this read only access with more users. As a Workbench shop, we'd keep Read/Write for Workbench, and Read Only for MSP. Most of our MSP usage is for communication (best printing capability) & 3rd party visualizations.

Hi Rob,

Thanks for responding.  We wanted to avoid having the multiple export options as some of the PMs have issues with the schedlink and I was trying to avoid that in the future.  I do have a question about your process of opening a ticket for you to open into MSP.  Is the agreement that whatever the schedule shows, the requestor is responsible for any "fixes" that are needed or do they push back for you to make what they feel are needed corrections due to the interface?

The OWB xml schem is different from MS Project xml schema so you cannot save from OWB and open in MS Project.

There was a converter from OWB to MS Project by Dietmar Hiller  from days of Openworkbench.org and even simple GUI. by DLandfried and Alistair Miller wrote an overview of the process.

Great Question. You know your MSP interface. The world of Open Workbench welcomes you - where all of these calisthenics simply go away...

I have all the best practice settings in my MSP and calculation option turned off. At a previous organization I was in the business of 'fixing' schedules, but as an OWB shop where my project managers went through a full bake-off to decide client tool - my customers are very aware of the differences & what they're signing up for with MSP. My rule is I'll send you what I get out the interface. 

That said, I do eyeball project finish dates, phase start & finish & give it a general look for anomalies. With MSP calculation off & Fixed Work as default - things stay pretty stable. (The Green Paper recommends Fixed Duration to keep dates tight, but I think this was published (2010) before MSP had calculation off capability. Try things out and choose what is best for you.)

I think the DocOps are pretty fantastic and I'm assuming most of the information in the attached Green Paper have been rolled into here by now, but this has been a faithful guide to have around to help people understand the differences in the scheduling tools and why neither PPM nor I are to be persecuted for changes to someone's schedule when opened in MSP...

HTH

Oh - I also send a PDF of the schedule with the MSP file. This is my static 'checksum' for what I've sent them. Once the file travels, I can document and recommend, but I can't control another's MSP version, default settings, schedule calculation settings, etc. Not all settings travel with the file - contents can shift when opening & when manipulated. This risk exists regardless of PPM's involvement. I used to be a MS Project Server admin - these calisthenics exist here as well. It's just a nature of a 'connected schedule' being shared with static, unconnected clients with varied settings.

I've used export from MSP as XML to open up in OWB, not the way you are trying.

CA provides a warning, which may not be applicable in your case as you are sending the data externally:

Do Not Use Open Workbench and Microsoft Project for the Same Project

CA PPM also supports full bi-directional connectivity with Open Workbench. Some organizations configure their CA PPM environment to support both scheduling tools. 

However, the following use case is not supported:

1. You open and schedule your plan in Microsoft Project and save it to CA PPM. 

2. Later that day, another project manager opens the project plan to reschedule it in Open Workbench. 

This situation can lead to the unexpected shifting of task dates and other serious scheduling issues.

Hi Roland. Correct, we do not use MSP in a bi-directional manner as the guideline above cautions against. This is a one way read (open read-only) sent to external sources. This is why I'd like to have the option mentioned a couple posts up to provide my users full read/write OWB support with the added read-only for MSP. Like the warning above, I have a couple power users who have the capability for multi-tool bi-directional, but they've promised not to do this. So far this agreement is working - but I'd sure sleep better at night with a 'read-only' easy button that keeps them safe!

We have recently build a custom microsoft project export (one way) for CA PPM. The focus was to show the project plan in MSP just like in the CA PPM Gantt (MSP does an "autoschedule" on open, when the standard MSP interface is used). There where also some aditional customer specific requests.

The solution is build right know for OnPremise users (it uses a server side script query the db and create the msp file) but if there is interest, we can adapted it for the SaaS platform.

We can make this solution availble for further customers, is better than fighting with the xml format (which I also used to do).

Kind regards,

Sergiu

Sergiu, does IT Design have this as a product offering? I am checking the website and am not finding it.

I wrote the original PMW (Project Manager Workbench) to MSP converter using .MPX (MSP) files and ".FIX" files (PMW), I called it "MPX2FIX", surprisingly. This was way back under Widows 3.1 when both Workbench and MSP were younger (so was I of course). I mention this only because I have literally grappled with the multitude of differences between the 2 products for many (many!) years.

If you put the complete CPM project model into MSP you will have differences in the schedule to deal with no matter what. It is way better  "In My Rarely Humble Opinion" *  to export "just" the tasks with current start/finish dates and baseline start/finish dates. Forget about putting full dependencies into MSP. Also exclude the assignment information assuming that isn't required when you are trying to communicate the project schedule. Instead of assignments, consider using task level text fields to mark "responsibility" for the task. If you follow this line of thinking you can reliably reproduce the project schedule in MSP and it will remain consistent no matter what the settings are within MSP for a user. Remember you are likely to be sharing those schedules with users who know nothing about the (long) list of settings you might prefer to see in use. In other words, reproduce a set of tasks, and not much else.

So, I would like to propose that you do NOT use the built-in export from CA PPM to MSP, and much prefer to style of suggestion that Sergiu Gavrila has proposed. MSP is a lot more flexible about inputs than Workbench and it can read a variety of file types including Excel sheets.  Thus you could build a portlet that collects the standard columns you want to share as a project plan (using NSQL) and simply export from there.

---

* I saw "IMRHO" for the first time recently, I like it, it suits me well 

Can't disagree with you. Thank you for your effort over the many years in supporting the use of OWB, MS Project and CA PPM (Clarity). When you wrote the initial converter both Project Manager Workbench and MS Project were file based. Since then the supported file types have changed for both and later both got database support. A side track was the Open Workbench which was freely available and only file based. A different converter was required for that and it was written to utilize the xml format which both supported, but had its limitations at each end. Now the filebased standalone Open Workbench is not generally available while the one that comes with CA PM is mainstream. Being database based gives the opportunity to query exactly the data needed and to convert what is supported to eg. a MS Project file format as Sergui and his team have done. That even requires less technical skill and information than developing MPX2FIX. If you can do that or have such a converter available I do not think there is any reason to consider anything else.

However, you can transfer the data, but as you point out the differences in functionality remains.

So is the FIX file an XML file or another format (maybe structure like XER)?

I have been working on another project requiring the conversion of MPP files to another format.  One earlier issue I ran into is that MPX files are no longer importable into MSProject 2013.  MSP2013 does support an XML file following the mspdi_pj15.xsd schema.

V/r,

Gene

Neither the .FIX (fixed format) nor the .MPX ("Microsoft Project eXchange") are relevant any longer. Neither of them were XML based  as they both pre-dated XML standards. I was only attempting to stress that the differences go way back, but that those changes remain similar in principle.

The points I wanted to make were:

1. IF you exclude dependencies when exporting to MSP you can be much more confident that it will represent your current schedule (as the point of that export). As soon as you include dependencies you open-up the (very high) risk that the schedule will "move" by auto-calculation. As an added precaution I would also suggest you copy the current start/finish dates into one of the baseline start/finish date pairs available in MSP (e.g. start10/finish10), and this would be in addition to exporting the true project baseline (if you intended to do that).
2. The most onerous set of differences between the products is how assignments are handled.  Unless there are truly compelling reasons for sharing this I would suggest you exclude this also. IF you include this, and IF an MSP instance has auto-calculate on, then your exported schedule would not reflect what you currently see through CA PPM or Workbench. Particularly if timesheeting and/or using non-linear distributions. For those who are sharing information outside your organization (e.g. to contractors) excluding assignment data may actually be a requirement.
3. In lieu of using MSP's resources/assignments, consider placing information on tasks to signify "responsibility" (e.g. the list of resource names that are assigned). If placed into MSP Text(n) fields then it won't influence any MSP calculations but still assist in communicating "who" is intended to be involved in each task.

I guess my overarching advice is to be selective in what you do export so that you maximize the benefit of sharing information, and minimize the risk of that information being misleading.

Following the comments on this thread (as always, an education!), I wonder about the actual original requirement.  The question was posed about OWB vs MSP, but I wonder if that hits it quite correctly.  OWB and MSP are both management tools, and as alluded to here, both operate on different principles and with different algorithms.

If there's a genuine need to pass the project plan - in MSP format - to a non-OWB user, it stands to reason it would be passed so the non-OWB user can make updates.  If this is the case, unless there's a way to get those updates back into CA PPM, they will get lost in transit. And, how would you identify which updates were made because of the different algorithms and which were intentional?

If, on the other hand, the purpose of passing information to the non-OWB user is to report status or progress, then I submit there are better mechanisms, not subject to the vagaries of a planning tool.  A representation of the gantt chart in a custom Jaspersoft report would be one such mechanism. Alternatively, dropping the plan into Excel and formatting it there might work just as well.