At Spider Strategies, we have a “Research and Development” (R&D) day each week that allows us to pursue projects we find interesting. For the last few weeks, I’ve been working on a search feature for CMS 2.1 that will allow you to quickly search through everything in CMS: bookmarks, strategy maps, documents, reports, etc. This will be a handy feature if you’re looking for something and you know its name but aren’t quite sure where it would reside within CMS.

Here is a screenshot of the new search feature in action.

Possibly one of the most useful aspects of the CMS software is the ability to assign weights to any scorecard node, at any level of the scorecard tree. For any node in this tree, any number of subordinate nodes can play a role in determining the score of their parent. This allows users to emphasize the importance of certain higher priority items over others.
When you have two very important objectives, such as “Produce many widgets” and “Keep cost low”, chances are that the default weight of “1″ (setting each of their weights equally, so 50% for each) would work just fine.

But what happens when you add a new node of lesser importance to the tree?

Of course it’s important to keep the water cooler filled, but the default weight of “1″ means that it is of equal importance to “Produce many widgets” and “Keep cost low”(so 33.3% each). So now we need to alter weights of the nodes so that they are scored more appropriately.

The question now may become “How do I modify the weights of these nodes so that ‘Keep water cooler filled’ is only worth 15% of the overall score for this level of the tree?” One way of accomplishing this would have been to first do some calculations in your head to determine the desired weight for each node. Second you would right click on the first node, change its weight and click save, then do the same actions for all subsequent nodes that you need to change.

Not too difficult when only working with 3 nodes, but what if you have, say, 17 nodes, that’s a lot of calculations, and node editing to do!

Our solution is to allow users to modify all nodes at any level of the tree, simultaneously.

After right clicking on “Keep water cooler filled” and selecting “Edit Weighting”, you will see the above screenshot. All siblings of “Keep water cooler filled” now appear in one single list, allowing you to modify all of their weights at the same time.

One of my favorite features about this screen is the immediate “percentage calculations” that take place while editing weights. For example, if you clicked inside the “Keep water cooler filled” textbox and changed it from “1.0″ to “2″, you’ve just increased the weighting of that node to be double that of the other two nodes. At the moment you press the “2″ key, CMS recalculates the “% of Total Weight” and instantly displays “25%” for the first two nodes, and 50% for “Keep water cooler filled”, clearly not a good weight distribution considering that the water cooler isn’t anywhere near the importance of the other nodes, but thanks to the new Edit Weighting interface this was an easy error to catch!

As I mentioned earlier, it doesn’t seem like that big of a deal, manually doing calculations and editing weights for only 3 nodes, until you have to do it for a lot of nodes. Then the calculating and editing can become quite tedious.

The introduction of this feature in version 1.6 of CMS is one that we hope will provide users with an even greater appreciation for both the usability of our application, and the focus that we place on providing our customers with cutting-edge solutions to even the most mundane of problems.

I’ve spent the last couple weeks working on a new feature in CMS 1.6 that allows you to create, edit and save reports just like performance charts, documents and other items in the system. This feature can save a ton of time because now reports don’t have to be rewritten if a new user wants to see them or if the dates for the report change.

In the past, the only way to save a copy of a report was to save it to your bookmarks. This worked great for the person who created the report, but it was impossible to share that report with other people on the team without recreating it for each user. Now you can create a report once, and it will be available to everyone on your team under the reports tab.

The other reason reports had to be rewritten was when the time period changed. For example, a monthly report would have to be rewritten every month so that it referenced the correct month. Thanks to the relative date feature Chris described last week, reports can be written so that they always show information for the correct time period.

Below is an example report. I set it up to show me all of the metrics under the Customer perspective for the California Manufacturing Plant. I set the dates to relative so once November rolls around the report will automatically show me the data for the last complete month where I have data, October.