Give me a dashboard...

"Dashboard" - as a Project Manager or just person frequently getting requests directly from the leaders of the huge multinational company I can testify to the profound and growing popularity of this term. We talk and breathe dashboards whether we acknowledge that or not. And as the downstream requests are flourishing with "Show me the dashboard" pattern so are the trends at the middle or lower organizational levels. Software is not an exception - every application has a Dashboard of its own (as I am writing those words I have just noticed that http://www.blogger.com/ is not an exception either). As I am teaching a Project Management course using SharePoint technologies, I have noticed that the most frequent question people are coming with to the course is "What is the best practice and how can I build a dashboard".

So what the hell is a "Dashboard"? Here is a small service I did for you, people - Wikipedia definition says the following: "A dashboard, dash, "dial and switch housing" or fascia, (chiefly in British English) is a control panel located under the windshield of an automobile. It contains the instrumentation and controls pertaining to the operation of the vehicle". In a nutshell, it means that the area contains all the necessary information for you to understand what is going on with your car and shows you key parameters identifying operational status. Let me try and translate it into business language: Centralized area showing status of Key Performance Indicators (KPIs) pertinent to current business area or agenda.

Ok, let's dive deeper and follow the thought thread. "Business Agenda" applies to everything we are interacting with and has a complete different flavor for different businesses, operational units within the same business and even people requesting the information. Its content and focus can be changing pretty frequently as does our business focus and key areas of attention/concern/opportunity. Some organizations have a very clear set of Key Performance Indicators - I find it more prevailing in Manufacturing and Financial Industries; for some - the agenda has a project-driven orientation and can change every couple of weeks. Here is couple of examples:
1. As a Project Manager or PMO member we might be interested in seeing Past Due Tasks, Tasks Due in the next week or Runs (if you are working using SCRUM), Outstanding Issues, Critical Risks, Budget Status chart, Run Down chart, Release Schedule, Customer Satisfaction level. As you can already see some of you are disagreeing with me already which proofs the point that as we are different so is the way we are driving things and so will be our Operational Dashboard
2. As a person working in the industry driven by strong financial characteristics, I know my Directors would like to see information using characteristics like EBIT, ROFE, Sales Awarded, Quoting Business
3. Working closely with Operational team, I know their focus it most likely to be Time Spent on support Tickets during the last 3 months, Servers uptime, Upcoming Maintenance, Vacation Calendar

Let's look at the second aspect which I kind of touched on in a previous paragraph - "Pertinent". It means relevant to a person receiving information. Using our car analogy: some people are only interested in the odometer, some also would like to see gas consumption and some don't really care about this weird red light spot in the form of a pitcher or meat grinder. Every information thread has two ends: Provider and Receiver. Let us focus on the second one. Using Project Management terminology, Receiver is a Stakeholder and Managing Stakeholders is an extremely critical project activity. My personal experience shows me that it is probably the most important one when managing a Project. I have seen project declared as a complete failure after a very successful implementation and people being promoted after talking more than half a million down the drain. And all because of a proper or improper handle of key business players/stakeholder and proper or improper information delivery and expectation management. So does our Dashboard - the content might differ based on the audience. Well, actually the better way to put it is: "The content should change based on the audience".

To summaries the rules to adhere to when building a Dahsboard I would recommend the following steps:

1. Figure our the audience (Stakeholders) that will be using the Dashboard


2. Understand their needs (type of information, preferred format - graphs, tabular, etc; when this information is required, process for it to be reviewed - for example if it has to be reviewed during the montly Steering team meetings; what is the expectation of the information currency, souce of data, ways to retreive data, additional "tweaking" that might be required prior to publishing the information, expectations to alerts around content changes, potential export requirements - need to export into Excel or email it, need to go back in time and review data from the previous periods). One of the key points is also to verify that the way the data is being accumulated or passed to the Dashboard has to be part of the existing or highly supported process


3. Based on the data collected in #2, do a thorough review to understand the best platform and the location of the future Dashboard to come. This is going to be crusial in assuaring acceptance as well as success of the initiative


4. Identify a small but eager group of people representing Key Stakeholder and test functional "prototype" level solution (addressing only some of the areas the Dashboard is to cover) with them

All of the above can be reletavely easy implemented in SharePoint using out-of-the-box functionality and some free or really cheap chart or/and gauge webpart. Will try to give you some examples in my next posts ... see you

Visualizing Task Status

For most of us our day and work is broken into activities that have Start, End and Due Dates. Those might be unrelated tasks, like working with the HelpDesk system or heavily related ones when working on a project with several milestones and a complicated task dependency schema. As a nature of our work, our performance is often measured by our ability to complete those assignments on time, within the budget, and under predefined quality conditions. We will leave budget and quality out of equation today and see what we can do better to assure the timeliness of our actions which can be particularly challenging when working with large teams, large projects or just simply with a large number of tasks. The last one is particularly challenging as in most business environments the unfortunate reality is that the priority of those tasks is sometimes blurry and undefined or everything is classified as “High Priority”.
So let us look at a simple common scenario. You have a project with a series of tasks that are of different with the only common denominator being your desire to meet the schedule. And let’s assume another set of business rules you would like to adhere to:

1. Tasks that are past due should be visually demanding your attention so that you can take appropriate action.
2. Everybody is responsible for their own tasks but the Team Leader or Project Manager should see and be able to act on any tasks assigned to the members of the team.
3. Tasks identified as “Critical” should stand out.
4. You would like to live to the Schedule Baseline and drive forecasting to perfection so all tasks that are falling out of the originally defined schedule should be clearly visually indicated.
We usually use relatively complex Project Management tools like MS Project, and Primavera. Those tools, while providing significant value added to the organization, are not really there yet from visualization stand point and require significant training as well as work involved in surfacing up all the project key performance indicators. Sometimes it is easier from user acceptance and visibility stand points to use simpler and more available tools. SharePoint smoothly fills in the gap. I won’t go too deep into the Pro’s and Con’s of using SharePoint to manage projects; instead I will be showcasing some simple techniques to accomplish the objectives we have outlined above.
Let’s assume you have a site with a simple list you are currently using to track your activities around two different projects.
Here is an example of what this might look like:

So I would like to do the following to comply with my objectives:
1. Flag tasks being on schedule, due today and being past due using relevant icons
2. Make tasks of critical nature bold and red, which in our case means Category=”Critical”
3. Highlight tasks that have slide off the originally planned schedule
This will result in a page that looks more like this:

Task #1 – Flagging
The ‘flagging’ process is how we visually represent overdue tasks to the user. In our example when the current date or date of ‘today’ is greater than the due date and the task is still incomplete we know the task should be flagged as ‘overdue’.
The most challenging part is to compare the Due Date to the current date. SharePoint doesn’t allow you to work with Today() function in the Calculated column. Another challenge here is the fact that Calculated Column by its nature is being updated when the record is being updated. That means there is no assurance that it updates regularly. It also means it does not update on its own (without action being taken).
There are several workarounds with adding 'Today’ and a temporary column. Which we would then use in the calculations and further remove it from the list; or creating code that periodically runs and recalculates the value of the Calculated column.
These approaches have lots of disadvantages and some will stop working after a certain period of time. Instead the solution proposed in this document is to use HTML in conjunction with JavaScript embedded within a hidden Content Editor webpart.
Here is an outline of how to execute the solution using the example scenario described above:
· Add a Calculated column to the list with the logic generating HTML script on the page

- Add a Content Editor Webpart (has to be below the List on the page) with the java script (jquery component) that would process tagged HTML and generate appropriate icon based on the Due Date and Today driven logic:

· Hide the Content Editor WebPart that contains the JavaScript you just completed. (Go to webpart properties and under layout set Hidden to true (check the box).)
So now the script is analyzing the content of the page and puts a relevant icon while processing the HTML content of the column. This means that when todays date is greater than the due date the task item will be ‘flagged’.

Task #2 – Marking Critical tasks with bold and red font
It gets really easy from this point on. We are just going to add additional java script into the already existing Content Editor Webpart that you added in Task 1.










The page should now look similar to this:

Task #3 – Highlighting Tasks slipping of the baseline We will use the same approach we used in the previous tasks where we update the Content Editor Webpart’s script.

So finally our Tasks page looks as we wanted it to be.

At this point you should now have the task list showing the way you want it. Make certain to adjust the views and relevant site links or roll ups of the list so that you consistently use these visual indicators and good luck.

Special thank you goes to great solution architect and developer Riyaz Patel who helped me with the java script part