That little post on Portfolio Analysis in Excel that I threw out into the Interwebs a couple of weeks ago seemed to engender a surprising amount of conversation – both online and off. As I’ve stated before, I am not a math major, but figuring that as of this writing we had three distinct comments posted – and generally most posts generate zero comments, then by my calculations, if I figure 3/0, we had approximately an infinite% increase in postings (+-10%).
In my books, that puts PPM Simulation postings on par with Earned Value postings as potentially being the third rail of the EPM tool blogging space. I guess this means that when I develop some sort of controversial content around simulating the application of EVMS to PPM, the kraken will really be let loose.
But seriously, my take is:
1) People do read this blog – and for that I thank you.
2) We need to take a look at what really differentiates Microsoft Project Server 2010 from the other PPM tools out there.
3) What we’re seeing is the fall out from the fact that Project Server 2010 is the first Microsoft EPM Server product to perform its own calculations *on the server*. (and yes, I know we said the same thing about the 2007 release, keep reading to see what I mean)
The main gist of the comments and offline discussions were around whether or not it was appropriate to document/reproduce some of the specific calculations used in the Project Server 2010 PPM module. My goal with this current post is not to get into a discussion around that topic, but more to direct the conversation to what I see as the key issue, which is the question of what differentiates the Microsoft offering from the other products out there.
The Report
Interestingly enough, this kerfuffle (if indeed 3 comments constitute a kerfuffle) occurred right around the same time that the latest Gartner Report on Project Portfolio Management tools was released (see here for the announcement and here for the full report).
A total of 31 vendor packages were evaluated. According to the report, the key criteria for inclusion was that the products support
1) Core project tracking/management
2) Time/cost management
3) Portfolio level management and reporting
4) Standardized demand collection mechanism
Here’s what Gartner had to say about Microsoft’s EPM package core strengths:
So to sum that up, Gartner is saying the the Microsoft package is competitive on the merits of its tight integration with the Microsoft stack, integration with the project management aspects of the tool, and support for custom enterprise demand management workflows. What’s noticeable is that Gartner is not saying Microsoft stands out for the quality of its calculations. Nor does the report state that Microsoft EPM has subpar calculations. The reason for that is that basic driver & project prioritization calculations are a prerequisite to be included in the survey, they represent the price of admission – they’re a commodity.
Here’s how I see the world:
1) Portfolio Management techniques have been around since the 50s if not longer. They’re taught in B-school and have well-documented calculations. As far as I can tell, almost every PPM tool uses pretty much the same calculations with some minor variations.
2) Project Server 2010 packages those techniques up into a convenient package and then adds customized workflow and tight integration with the project scheduling engine.
3) If all you’re looking for is a calculation engine to support AHP, you could buy one off the shelf or you could build one in Excel. In fact, Dr. Kardi Teknomo wrote a fantastic tutorial on how to do just that.
4) The true value of the MOPS 2010 PPS module is that it provides a customizable, extensible platform to support enterprise workflow. That platform is then dependent on the commodity PPM calculations that every tool provides as a base requirement for being a PPM tool.
Put in context….saying that modeling how to do PPM calculations in Excel devalues the Project Server value proposition is kind of like saying a model of Critical Path in Excel devalues MS Project. It doesn’t, because MS Project is far more than a Critical Path calculator. Project is a tool that encompasses a number of project management practices, most of which have been around long before Project. And let’s face it, if MS Project did not possess the facility to calculate the Critical Path, it wouldn’t be much of a Project Management tool, now would it? (And yes, I am aware that adherents of some methodologies may disagree with that last statement).
The Consultant Role
So now we come to a topic I’ve discussed before on this blog, what is the role of the consultant in all of this? Well, I would say that coming from a training and user interface background, I’ve always seen my role as one of explanation and interpretation – i.e. that much of what I do is to explain the inner calculations of Microsoft Project to end users.
For example, in the last couple of weeks, I have been working with a client to develop a summary reporting structure using a third party tool. In the process, they found that % Complete was being calculated differently on Summary Tasks than Child Tasks. That’s when they come to me. My job is to figure out behind the scenes how Microsoft Project calculates % Complete for Summary and Child Tasks. Once I’ve created an adequate model of those calculations, I can develop a formula to consistently apply Child Task % Complete calculations to a Summary Task.
As I’ve heard many times in training classes, the role of the consultant in an EPM tool implementation is to ensure that the tool is predictable, and that the end users understand the underlying calculations. To the best of my knowledge, that’s not a role that only applies to the desktop tool. It applies to the server product just as well. The only issue is that until the 2010 Project Server release, we really did not have all that many calculations to explain on the server side. The ones we did have were all replicated in the desktop scheduling engine.
That’s an observation that I hadn’t quite realized until I sat down to write this post. Project Server 2010 is arguably the first version of the Project Server family to feature server-side calculations. Now wait a second, you’re saying. Wasn’t 2007 the first version to feature server-side calculations? Technically, that’s true, but remember that the calculations featured in 2007 are the scheduling engine. Thus in 2007, whenever a client had a question about how updates were applied to the schedule, I could bring up a copy of Microsoft Project and explain it away. In 2010, with the portfolio prioritization and optimization engines, we now have a whole set of calculations that have gone to the server. This now requires a slight shift in mental models, insofar as we now can’t easily draw that distinction between calculations on the Server and calculations on the desktop.
As a consultant, I now have to be able to explain the calculations that are happening on both sides of that fence.