In this blog I ran across an interesting scenario that a customer requested.  The customer is running a three tier Project/SharePoint Server 2013 server farm on Windows 2008 R2 server.   The company required all servers to be on Windows Server 2012 R2 or higher and so the client wanted to migrate their Project/SharePoint 2013 farm to Window 2012 R2.  SQL server was not a concern, because it had already met the companies polices.

My first impression is why not migrate Project/SharePoint 2013 to either 2016 or 2019 and at the same time, install Project/SharePoint farm on Windows 2012 R2 servers.  Seems reasonable, however, the PMO (Project Management Office) didn’t want to migrate to newer version of project server, because of different SharePoint architecture, reports and customization.  This makes more sense to me now and so I came up with two possible scenarios to accomplish this with least impact.

• Install new SharePoint/Project server farm on new Windows 2012 R2 servers and then move databases and configure services on new environment.
• Swing new nodes in the existing farm by adding a new SharePoint front-end and app server on Windows Server 2012 R2 server. Configure app server to run same services as the 2008 R2 servers and then configure 2012 R2 front-end server

Three Stages of the SharePoint Swing

1) Original Farm on Windows Server 2008 R2 (above)

2) SharePoint Swing Farm on Server 2008 R2 and 2012 (above)

3) SharePoint Farm now running on 2012 (above)

It was decided to use the SharePoint Swing method.  The premise if fairly simple.  New windows 2012 R2 servers are created and SharePoint/Project Server is installed and configure.  The swing operation basically was the following

• Install two Windows Server 2012 R2 servers and install SharePoint 2013 on each node
• Join the new SharePoint servers to the SharePoint 2013 Farm. One as front-end tier and the other as app tier
• Using Central Admin add services to the new app and front-end SharePoint Servers
• Verify servers are working properly
• Shutdown old SharePoint front-end and app server. The SharePoint farm should continue to work without the redundant server.
• Optional after it is proven that the SharePoint has swung to the new SharePoint servers, the old servers can be remove and decommissioned.

Github provides PowerShell scripts to create a test environment in Azure using an IaaS architect.  https://github.com/MyProjectExpert/ProjectServer-Tools/tree/master/SharePoint2013Swing

Roadmaps have recently been release from Microsoft.  Roadmaps are a great way to summarize a PMO, Program, Project or anything that needs a summary.  When I first saw them, it seem like an easy thing to put together.  However, as I started to put together my Roadmap example, I released that its may be much harder than I thought.  After working thru a few examples, I discovered, that basically, it takes planning and a vision to make a Roadmap.  Duh!

Roadmaps can be used for many visions. One useful display of a Roadmap is to showing key milestones and dates in a program. My example is composed of several projects with dependencies between them. Visualizing key deliverable and milestones across a program can be best be done using a Roadmap.  When you think about it, there really isn’t any other tool within office to do this for user.  There hacks, web parts and web pages that a SharePoint admin could do, but not really one for typical users.  The following Roadmap consists of three projects, each with their own project manager and deliverable dependency between the projects.  Looking at my program Roadmap, I can easy determine the major deliverables and if it is on track on now.

As mention earlier, it takes planning and vision to build a Roadmap.  It may seem obvious now, but before building a program Roadmap in this blog, I had to go thru several iterations of a building my master project before I could get my Roadmap off the ground.  Once that was done, building my first Roadmap was simple.

 

Roadmap is like any other feature in Office 365; it must be turned on.  Brian Smith – MSFT provides the core steps with turning Roadmap on. https://blogs.msdn.microsoft.com/brismith/2018/12/07/project-online-getting-started-with-roadmap/

My blog provides the steps and along with screen shots of what you can expect to see.  Once “Roadmap” is turned on, the following option shows up when creating new projects or Roadmaps!

Default form for Project Online

Steps to enabled Project Roadmap:

• Office 365 Admin: Log into office 365 and click on “Admin” icon.  It may ask for your login credentials. https://www.office.com/?auth=2&home=1
• Settings and then “Services & addins https://admin.microsoft.com/AdminPortal/Home#/homepage
• Services & addins https://admin.microsoft.com/AdminPortal/Home#/Settings/ServicesAndAddIns
• Project Online and turn on “Roadmap” and click Save
• Make a note that “Project Online settings have been updated” and click Close
• If working properly it looks like top screen.

Office 365 Startup page

Office 365 Admin Center pager

Office 365 Admin with Service & addins listing services

Turn on Project Roadmap

Verify option enabled and click close.

When designing an Azure IaaS architect; should IaaS use a Windows Server AD VM or Azure ADDS for managing user and service accounts? The diagram below show two strategies.   The yellow arrow points to WCC2016AD, which is a windows 2016 server running AD. The red arrow points to Azure Active Directory. Each with their advantages and disadvantages.

Using Azure to setup IaaS environments for either TEST and QA is a great way to reduce costs. Typically for an on-premise solution, the organization’s support costs may double or triple for supporting a production application. TEST and QA environments are typically created for supporting application. This means additional hardware and software are added to the total cost for support. For a large IT shops this may not be a problem; however, for small and medium size, it can be a real burden.

Azure IaaS (Infrastructure as a Solution) can be a real cost saver if managed properly. The cost saving occurs when VM are turn off when not needed. When VMs are turned off, there is no billing for compute processing and disk storage is a relatively low billing item. In my small world, I can keep all my Azure costs below my MSDN subscription fees and thus not pay anything at end of month.

A typical IasS includes Front-End Server, Application Server, SQL Server, Windows 10 and Active Directory VM.  Typical for me, because I build and configure many different SharePoint environments and need a minimum of five server VMs. The Azure LAB environment provides a good enough environment to typical production environment. Over time, I have always wonder if it would be cheaper or better to use Azure ADDS or continue to use my Azure AD server VM.

The answer really depends on what you are doing and trying to accomplish. In my case, keeping costs down is important.   The ADDS cannot be disable. It can only be deleted and causes a lot of trouble when rebuilding. Because of this and many other factors, my preference is to continue to use the Azure Windows Server AD VM.   Spin it up when it is need and turn it off when done.

	Azure ADDS	Azure Windows AD VM
Cost	Minimum of $2 /day	Zero cost if VM is turned off
Managing Accounts	Useful (half dozen)	Useful (six)
Account creation	Must be done on Azure and synced	Not required using VM
Syncing User Profile	Required for testing AD Sync	Not needed unless testing

In summary, my preference is to use Azure Windows Server VM with Active Directory installed and configured to support my TEST and QA environment.

Microsoft announce Roadmaps during Ignite 2018.  To be perfectly honest, during the demo and afterwards, I didn’t find it very interesting.  It looked mostly like a One-Pager report that I had seen many years ago and Roadmaps implied that it was only for executives.  I attribute this view because One-Pager reports was developed for executive management that didn’t want to see many details.

Then it dawned on me that the Project Roadmaps was much more than what I originally thought and can be applied to many different visions.   The “Vision Roadmaps” can be used not only for executives, programs or projects but even small teams and personal goals.  Once I saw these capabilities, I was sold on it.

What are Project Roadmaps?

Basically, it’s a reporting dashboard that pulls project data from multiple sources, such as Microsoft Project, Teams and Visual Studio azure boards.  Then major deliverable are highlighted with different colored bars, milestones and dates making it easier to see the vision and how it’s going to be achieved.

Whats Next in Project Maps?

Microsoft Ignite announce it but it’s not out at the time of this writing (11/4/2018).   It’s pretty much ready for, however Microsoft will continue test, refine and enhance new feature until it met all of Microsoft requirements for integrating into the Microsoft’s Modern Solution; which means it runs as part of CDS (Common Data Service).  For example, Project Roadmaps is fully integrated into Flow and Power BI.

 

 

As we all know, Project Online/Server (PWA) does a great job with managing project schedules and resource loads; however, can PWA manage other company process when we stretch the PMO into taking on more roles? For example, several of my previous clients have used PWA to estimate next year’s annual budgets. This article takes a quick look on how PWA can be used to roll up departmental budgets and improve on the capturing of the real resource load across a whole organization.

Let’s first look at what project center looks like when departmental budgets are loaded into PWA. Then, we’ll walk back and see how to accomplish this. Note that the same project center view shows next year’s budget (2019) rolled up for all the departments in the organization. In the example below, the company only has three departments, but the concept works for as many departments as are required.

The project center view is grouped by year. Because of this, we can roll up the plan costs for all the departments. The blank year displays current projects that are in process— some of them across multiple years. These are current projects not involved with the budget. Year 2019 shows the day to day (D2D) schedules. You might wonder what that means. It will be discussed later, but basically it captures non-project work for those people not on a project. For example, D2D 2018 IT schedule, which captures work business as usual work from a DBA or help desk person.

Year 2019 is the roll up of all the departments for next year. This is accomplished by having each department or business group create a staff schedule with any additional fixed expenses. The screen shot below shows what a schedule may look like. There are many ways to do this. My preference is to set up each staff member as a summary task and include big pockets of time showing their main activity. For example, Teresa Black is estimated to spend 1400 hours on projects, 500 hours on design and questions outside of her projects, and 100 hours on administrative activities. The hours add up to about 2000. Close enough for me; however, based on your requirements, you may want a more accurate accounting of hours.

You may have a circumstance where you wish to add two additional people for next year. The same kind of hourly planning can be added to that schedule.

Finally, utilizing fixed costs or cost resource options can be used to capture other costs and overhead. This would bring your budget in line and provide an accurate picture of what you are asking for for the following year. As I said before, this is just one of many ways to create a budget with PWA. Of course, you’ll want to include enough details to make good decisions on what is required or to be cut for next year’s budget.

Once the D2D schedules are completed, they can be revised and several iterations can occur until the final budget is approved. Wow! This makes budgeting easy for next year, and could be the end of article, but it’s not!

There are many more benefits beyond just budgeting to this approach for both the PMO and the company as a whole. Resource load is more accurate for all resources throughout the year, and using PWA time-sheets can be a good replacement for primitive or expensive time tracking systems. Let me explain.

By capturing the day to day schedules of all resources for the year, the project and resource manager have a better view of what the actual resource load looks like. For example, the DBA may spend half their day doing maintenance leaving them with only 20 hours a week for working on projects. The diagram below shows a more accurate picture of resource workloads when using D2D schedules.

Once the schedules are published, there is a good reason to start using the PWA time sheet system or at least removing an old-time tracking system. The PWA time-sheet can be configured to use charge code and capture where time is really going. It also has a robust approval system. See an example below of a simple time-sheet showing a few day to day items. Another bonus is entering vacation time and capturing the impact of such on project schedules.

In summary, when using PWA to estimate next year’s budgets, we have killed three birds with one stone:

• The company has a better way to estimate annual budgets each year.
• The PMO has better view of resource workload for the year.
• The PWA Time sheet system allows for the replacement of outdated time sheets, making time tracking easier to manage by department.

I hope you will join me for my upcoming webinar on this topic, as we’ll explore more fully the in’s and out’s of implementing the process I have suggested here.