Significant changes are happening with Microsoft Project at the moment. For a long time, this mammoth of a desktop application has seen very minimal modifications to the core experience. It’s one of those tools that project managers could use brilliantly. Or, if you are anything like me, sink hours into instead, as you figure out all of its nuances and unique features, compared to other products in the Microsoft Office suite. Now, in tandem with Microsoft Ignite earlier this year, Microsoft has announced that their new Project for the web experience is now generally available for customers worldwide. The primary selling point of this product is its entirely refreshed user interface and deep integration with the Power Platform, as outlined by Jared Spataro in the above announcement post:

Built on the Microsoft Power Platform, Project enables you to quickly connect to the apps and services you already use, and to create custom desktop and mobile experiences to meet the specific needs of every project team. Easy to use tools make it simple to create automated workflow processes that streamlines compliance and increases efficiency.

The product also sets the groundwork for the eventual replacement of the current Project Service Automation (PSA) V3 experience with one identical to the new Project for the web experience, but deeply embedded within the Common Data Service (CDS) & Office 365 and fully extensible via tools such as Power Apps, Power Automate and Power BI.

Having had an opportunity to play about with the new app for a few weeks now, in this week’s blog post, I want to share my thoughts relating to it. In true wild west fashion, let’s dive in and see what’s good, bad and - frankly - borderline confusing and non-sensical - with this new product.

The Good

• Microsoft has succeeded in taking a beast of a desktop application and making it simple and easy to use within a web browser. Project managers can, therefore, focus more on building out their project plans instead of faffing around with multiple views, settings and other beastly configuration properties, that exist within the current desktop version of the app.
• The Roadmaps feature shows a lot of promise and, particularly if your organisation is managing your projects as part of programmes to PRINCE2 principles, act as a great way of being able to handle this engagingly.
• A much-touted benefit of the new solution is its native integration alongside the Common Data Service (CDS). In practice, this means that all Project data is stored within a CDS database, utilising some of the entities available within PSA. At the moment, Project for the web uses the following entities from PSA:
  • Bookable Resource
  • Organizational Unit
  • Project
  • Project Parameters
  • Project Task
  • Project Team Member
  • Rating Model
  • Rating Value
  • Work template
• By leveraging existing functionality, it makes it a lot easier for those familiar with PSA to start working with the innards of Project for the web, with very little training required.
• The ability to connect to Azure DevOps projects within the tool is a significant boon for IT-focused organisations. To achieve this integration, users can get the app to deploy out a pre-built Power Automate flow. All you need to do is provide sign-in details, and the Project app will handle the rest for you!
• Alongside the Project app, Microsoft also provides a model-driven app that can be used to interact with the data, using an experience familiar to most Dynamics CRM / Dynamics 365 users. The functionality exposed here is relatively limited (more on this shortly), but it does provide a tried and tested way of working with Project data. The screenshot below provides an example of how this app looks when being used:

  • 

The Bad

• Currently, although the new Project app is leveraging some PSA entities and features, there are some glaring omissions. For example, we are unable to configure skills or skill ratings for a resource at the time of writing this point. This deficiency is a minor irritant, which will likely disappear over time with updates/releases to the product.
• Resource management for the new app must take place within the model-driven app discussed above. It would be nice if we could do this from within the Project app itself.
• The transition route from working with the old-style Project Web App (powered by SharePoint) to the new experience appears, based on my research, to be a little bit unclear. For example, there is no precise mechanism to move any existing Projects across automatically so that they are stored in the CDS and exposed within the new Project app. Over time, we might see some tools released to help achieve this requirement but, unless I’m missing something, it looks like some manual effort is necessary to migrate your Projects across to the new experience.
• The ability to create Project groups - a collection of people involved in delivering your project - is a sensible idea in principle. However, as this functionality is reliant on Office 365 Groups under the hood, it could be open to abuse, leading to literally hundreds of different groups suddenly popping up on a tenant. Having the ability to control this will no doubt please Office 365 tenant administrators enormously.

The Ugly

• Although the Azure DevOps integration is a nice touch, the fact that it creates a Power Automate flow within the default environment and that it is not subject to control via a solution could cause some difficulties when managing this in the long-term. It will also mean that a) any calls back to CDS will count against your daily/monthly API call limits and b) your monthly allocation of Power Automate flows. The Power Automate license type will determine the precise limits that will exist in practice. These facts could be better-signposted when setting up this integration for the first time.
• Perhaps I am just super stupid, but some features don’t appear to work for me at all currently. For example, I would expect that any Resources I create within the Project model-driven app to surface automatically within the Project for the web app. Based on my testing, this does not appear to be the case. Hopefully, there is just some property or configuration element that is causing this.
• Currently, the majority of support and training articles for the new Project experience are available solely on the Office 365 support website. Which is fine…but considering that the majority of CDS and PSA documentation resides on the Microsoft Docs website, it does make it a little challenging to locate help and support for the product. The documentation also currently blends information from both the new and traditional experience, making it somewhat confusing.  Hopefully, over time, the documentation will move across to the Microsoft Docs site, so it can benefit from features such as integration with GitHub to raise documentation issues directly with the product team.
• Although the new Project for the web sits on top of the CDS, you have no choice over which CDS environment that data is ultimately stored within. When configured, the application automatically installs the base solution to the individual (default) environment within your tenant. Users/administrators are not presented with an option (currently) to select one of their other environments to connect Project for the web up to. Data relating to all Projects, and their associated components, will, therefore, remain isolated in a separate database, with no apparent means of getting this data into your desired CDS database or to eventually migrate this all across in a straightforward way. For me, this represents one of the primary reasons why organisations currently using PSA or are interested in implementing it should stay far away from Project for the web, at least until the middle of next year.

Verdict

The new Project for the web application provides a unique window into the future evolution of Project and also PSA, as a modern, cloud-first application, that leverages the full benefits of the Power Platform underneath. However, I get the feeling that it’s not quite there yet. Perhaps there was a desire to get the product released as fast as possible, to ensure early feedback is received and factored into future development. There are no problems with this and, frankly, to see an organisation like Microsoft adopt this kind of “fail fast”, Agile approach is admirable. But, as mentioned already, there is a fundamental issue with the product if you sit in one of the following camps:

• You are a current PSA user, setup with your own Dynamics 365 / CDS environment, interested in leveraging the new functionality available in Project for the Web.
• You are an organisation contemplating the adoption of PSA, but want to ensure you are using the new Project for the Web experience, to ensure you are operating a version that will be actively developed and supported in future.

At this stage, my view is that it is impossible to recommend organisations fitting into these categories to start using Project for the Web. I believe the current setup of the solution from a CDS perspective is going to cause lots of issues from organisations who bite the bullet this early when we move into 2020. For now, by all means, spin up a trial and get a feel for the new experience, but don’t invest a lot of time just yet on starting to migrate fully across to it; particularly if you hope to fully leverage current PSA or other Power Platform functionality in depth.

What are your thoughts on the new Project for the Web? Are you a non-stupid human, unlike myself and have been able to get some of the things mentioned in this post working successfully? Let me know your thoughts in the comments below!