PerformancePoint and Virtual Earth for Data Visualization

So I just learned how to create a custom map utilizing Microsoft’s Virtual Earth.  To be honest “learned” may be too strong a work.  I can now “play around with” may be better.

This thing rocks.   If you ever though about linking a scorecard with a Visio map to display geographic data, then re-think what you are doing and look to use Virtual Earth instead.  

I relied heavily upon the Virtual Earth SDK and the MSDN forum (and some good advice and posts from a lot of people) and a whole lot of different blogs and web searches to help me create a GeoRSS layer to add to a custom map.      

From a data visualization point of view it is unbelievable.   The only caveat is that in a commercial use there is a charge for using Virtual Earth.  But ultimately it comes out to about $0.02 per use, which is pretty cheap if you think about it. 

I can’t access the server that this resides upon, but as soon as I can, then I will post some screen shots.

Still Alive

Been working  on a couple different projects all with go-live dates at the same time.  I hate this actually having to work at my job.  Soon as I get things under control in the next week or so I will have some new posts.  I have some neat stuff to share on taking PPS Planning to the next level as well as Monitoring with Virtual Earth.

Beware of Scope Creep

Not really a technical post here today but one that is more implementation practice related.

As part of my role here, I am responsible for helping design the overall architechure of a client’s solution.  Basically I figure out a way to fix the client’s business pain with the tools we have at our disposal.  The information I gather up-front when working with them ultimately helps feed our Statement of Work.  For those of you who are unfamiliar with this concept, a Statement of Work ends up being the guiding document between us and the client.  In it (in a nutshell) we spell out what we have agreed to deliver and what the client has agreed to pay.  And once we agree upon a scope, then any changes are formally handled via a change order.  This help ensure that the project is delivered on time and on budget and all client expectations are met.  

So where am I going with this?  Well, so far it seems that a common trait of all the PerformancePoint projects (either modeling/planning or monitoring/analytics) we have been working on so far, is that once you get into the project and begin having more in-depth discussions and showing more mock-ups and the like, is that more and more light-bulbs begin turning on for the client.   Now this is a great thing, because when it happens, they begin getting really excited about the product and begin seeing more and more uses for it, as well as seeing the potential they now have to change how they do things.  

However, what also comes along with these revelations is the fact that now the client will want to tweak how PerformancePoint is going to be deployed in their organization.   And that means what they want delivered is no longer identical to what was agreed upon in the Statement of Work and that means scope creep. 

The fact that you can knock out new scorecards or dashboards or budget models so quickly means that most of these requests can be handled with minimal extra effort.  So it is natural for a consultant to just simply sit down and quickly handle the request.  And when this is one or two extra items is no big deal.  But this whole thing can easily snowball out of control, because the more a client sees, the more excited they become, the more ideas they get and the more they will want to change.  

If you are billing on a fixed bid basis all these little changes can mean that you spend far more time on a project and not gain any additional revenue.  If you are on a time and materials basis, all these little changes can add up to hours and hours of extra billings about which the client may not be happy.   So just make sure that if you are an implementer of PerformancePoint you keep a sharp eye out for scope creep.