If You Use Microsoft Project Server or Project Online, You May Be in Trouble. Here’s What to Do.

OnePager has been a proud Microsoft Partner for many years. We both build and integrate with Microsoft technology. So we are generally pretty pro-Microsoft. But in this case, we think Microsoft has messed up big time, and it will negatively impact thousands of our customers. That’s why we’re asking you to get involved.

To make a long story short, starting this year, it may no longer be possible to use OnePager to make graphics from Project Server 2016 without also doing a desktop installation of Microsoft Project Professional. That means our customers who want to pull project data directly into OnePager from Project Server or Project Online, without using Microsoft Project on the desktop, will be out of luck. If that bothers you, good — we discuss at the bottom of this post what to do about it. First, a little detail.

At issue here is how Microsoft treats the local custom fields in Project. These include the Flag1 – Flag20 Yes/No fields, which more than 90% of our customers use to filter which tasks and milestones display in their OnePagers. Basically, it’s the part of Project you use to turn a 1,000-line project plan into a readable 50-line OnePager.

Microsoft has devised two methods for partner applications like OnePager to read the data (the Yes and No values) directly from Project Server. The older method, called PSI (which stands for Project Server Interface), allows applications to read all 130 local custom fields like Flag1 – Flag20, Text1—Text30, Number1—Number20, and so forth. The newer method, called CSOM (which stands for Client-Side Object Model), does not allow applications to read any local custom fields from Project Server.

Unfortunately, because Microsoft apparently didn’t think Project Server customers were actually using local custom fields, Microsoft decided to stop supporting the older, Flag-field-friendly PSI method for Project Online 2013, without first making the new CSOM method Flag-field-friendly. We learned this the hard way when we tested OnePager version 5.3: We found that customers wanting to import from Project Online directly would not be able to use their Flag fields to select tasks for OnePager. Customers would have no choice but to let all 1,000+ tasks from their plans show up in their Gantt charts. Not good.

For this reason, we had to disable direct import from Project Online, which forces all OnePager users to install Microsoft Project on the desktop (ironic, right?), now the only remaining technology for feeding local custom fields to OnePager. We hated to reduce our customers’ deployment options and raise their costs like this, but there was no other technical alternative. On the business side, once we were pretty sure that we had fully understood and documented the facts of Microsoft’s inexplicable decisions, we began trying to bring this oversight to their attention and to find out whether they had plans to fix it (to the best of our knowledge, they don’t).

But meanwhile, it got worse. We started hearing knowledgeable rumors that Microsoft may stop supporting crucial portions of the Flag-field-friendly PSI technology for all deployments of Project Server 2016, not just Project Online 2016. That would mean that all on-premises customers would be in the same boat as the Project Online customers. For all users of Project Server 2016, your choices would be to (1) not use Flag fields at all, so import every task from your project plan into OnePager, or (2) pay to install Microsoft Project Professional for every user who needs OnePager to access Project Server.

What can be done? There’s not a technical fix within our power, so all we can do is implore Microsoft to reverse the odd business decision to omit local custom fields from their new CSOM data access method. They could, in other words, change CSOM from Flag-field-unfriendly to Flag-field-friendly. We now have reason to believe Microsoft simply may not understand that Project Server customers use local custom fields like Flag1 – Flag20. Our hope is that by making our voices and practices heard, we can convince them to complete the CSOM software by including local custom fields.  This would allow us to remove the requirement to install Project Professional for every user who needs to make OnePagers from Project Server 2016, Project Online 2016, and Project Online 2013.

To that end, we urge you to add your vote to the online petition we have started by clicking on this link to Microsoft Project’s user feedback page. Simply click “Vote” on our petition; in the upper-left corner, you’ll see that you need to login to vote, but all you need to login is your first name, last name, and business e-mail address. You can give our petition 1, 2, or 3 votes, and of course we’d recommend 3 as the amount of weight to give to this issue! You should also feel free to add comments at the bottom of the page, explaining the importance of Microsoft Project Server/Online and OnePager to your business, and the importance of local custom fields (Flag1 – Flag20, Text1 – Text30, Number1 – Number 20, …) to your use of OnePager.

If you feel moved to tweet, we have also started the hashtag campaign #FixProjectServer– please tweet your comments with that hashtag to the Microsoft Project Twitter handle, @project.

We are committed to helping OnePager customers use our software in whatever way their business requires, even when it involves ruffling some feathers. Thank you for helping us persuade Microsoft to do the right thing for its customers. We’ll keep you posted!

This entry was posted in Microsoft Project Tips, OnePager 5.3 by Nathan. Bookmark the permalink.

About Nathan

Nathan Black was on the founding team of OnePager, joining as a beta tester in 2005. The product was exciting — the lack of paycheck, exciting in a different way. So he went out into the world, working as a project manager, management consultant, and academic (he was most recently a research fellow in the Government Department at Harvard University). Everywhere he went, he saw a need for more and better project management, particularly by people who don’t call themselves project managers but end up filling that role on teams and ventures large and small. In 2014, he returned to OnePager as Vice President of Solutions. His primary roles are (1) helping customers use OnePager more effectively and (2) developing new versions of the software. He is passionate about getting project visualization and reporting right, and eager to hear from project managers (in title or in reality) who feel the same way! Nathan lives in Kansas City, Missouri with his wife Whitney and sons Ethan and Adam. They enjoy classical music, the outdoors, and politics. E-mail him at [email protected].

4 thoughts on “If You Use Microsoft Project Server or Project Online, You May Be in Trouble. Here’s What to Do.

    • Thanks for the suggestion, Brian. The Microsoft product team seems also to be making this suggestion in their response to our petition. The problem with it is that many people create and work with their projects in Project Professional, and then migrate their data to Project Server. When working on the desktop, they put a lot of work into setting their Local Custom Fields correctly. When they migrate to Project Server, they do not want to go through the hassle of transcribing all this data into Enterprise Custom Fields. This not only takes time but also introduces the possibility of transcription errors. Furthermore, putting all the information into Enterprise Custom Fields only means it would not be available to them when they need to work offline. It seems to us like it would be better for everyone if Microsoft Project Server could just read Local Custom Fields, like most of our customers expect.

      • Well from a process standpoint they should likley think about starting their projects on the server and then they dont have to worry about any of that. They would also be able to report on that other data via the reporting database but everybody has their own way I guess.

        But in any case they only need to do it to ONE field, right? This reduces the issue I would think. They could even use a simple VBA routine to move the data for them when they move the project to the server.

        Also, Enterprise custom fields ARE available in enterprise projects when they are taken offline.

        Anyway, good luck.

        • Thank you for the correction, Brian! You are right that you can access Enterprise Custom Fields when bringing the files offline.

          Please note that we’re simply trying to keep our users’ experience as fluid as possible. Many of our customers use more than one Local Custom Field, so the effort to translate this data into other Enterprise Custom Fields could pile up.

          Our point of view is that, at a minimum, the Project users we support should not have functionality taken away from them with the introduction of new technology. Instead it should be enhanced.

          We very much appreciate your valuable time and willingness to weigh in on this matter.

Leave a Reply

Your email address will not be published. Required fields are marked *