PMProfessional

Give me a dashboard...

2009-09-16T15:54:00.000-07:00

"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:

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

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

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

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

2009-08-17T09:25:00.000-07:00

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

Manage Expectations

2009-07-15T13:21:00.000-07:00

It's been a while since I blogged and that is for different reason. I have to be honest with you - I am not one of those addicted to Social Networks but I am trying to pick up with the progress :-)

Long story short, when anybody is talking to you about Managing Expectations they (and that including PMI) refer to Managing Customer Expectations in order to avoid the scope creep, gold plating or anything else related to major Project deliverables and performance indicators. Today I would like to talk about different expectations and those are, to my understanding, not less and sometimes even more important in your project environment as they build up a foundation stone for successes or failures to come - PROJECT TEAM EXPECTATIONS.
It carries paramount importance for Project Managers among us in order to assure the Project is on track, meeting expectations, maintaining professional and technical spirit of the team. This is becoming really challenging for large scale projects and projects heavily depending on external and non co-located resources. Software companies leveraging outsourcing and using large development centers oversees coping with those challenges on the daily basis. So how can we do that? Is there an easy and transparent way to keep the team working as a TEAM? I think there is a way and I would break it into two major components:
1. PM should walk the talk
It is really simple - no bullshit. You should always be on time to your meetings; you should have no red items on your task list; you should be the first one recommending enhancements and pointing out issues with the key project components; you should talk to the benefits other team members are bringing to the project AND you should be the first acknowledging your mistakes
2. Evangelize and leave Ground Rules
Ground Rules is one of the key Project Artifacts. It outlines major behavioral attributes of the Project Team and basically - puts the stick in the ground. Keep those simple and achievable, by the way, if you want your team to live to them and again - LEAVE THOSE YOURSELF. Ground Rules should address or relate to major Project Knowledge areas:

Initiating (working out the charter, scope document, team's involvement in the project definition, suggestions, issues raising and so on)
Planning (team's involvement in Project Schedule, Quality Planning, speaking up when project is going off the rails, responsibilities and accountability)
Executing (participation in the meetings, being on time, reporting tools and processes, deployment and testing procedures, Risk Management and ownership, team dynamics, etc)
Monitoring & Control (sprints timing, success criteria, key performance indicators)
Closing (lessons learned, documentation, handing over procedure, etc)

You can follow a very simple set of steps to implement Ground Rules in your Project environment:
2.1 Create an area in your PMIS (for example, a list in your SharePoint site) and outline those Ground Rules
2.2 Review those periodically. It can be daily, weekly, based on the frequency of your Sprints or following any other logic you would like to work with
2.3 Review deviations of those Ground Rules during your team meetings. That might be tricky but I leave it up to you to work out the politics. With that being said, you absolutely HAVE to do it as Project Manager has to be a Leader with the capital "L". Your projects don’t really stand a chance if you are not one
2.4 Try not to introduce changes to your Ground Rules and keep them as generic as you so there are not a lot of changes as you move from one Project to another. People don't really like changes so keep their number to minimum

Here is a small example of one of the Ground Rules I am using:

Good luck and let me know how it goes

Keep your friends close and your enemies closer

2009-06-24T11:32:00.000-07:00

Somebody once said that politics is probably the most important part of the project management. In my relatively short 14 years professional life I have seen people promoted after making company loose more than 500k and on the other hand, people being fired after very successful implementations but failing to deliver their success to the management.

So how do we keep our friends close and our enemies closer? In my previous postings I talked about making everything visible. This is extremely important part of message delivery as well as reducing the chance of being set up during or after the project is done. I hate to sound paranoid but those are the brutal facts and rather than sticking our head in a pile of sand, we should face them and be prepared. On the other, more positive note, we are talking about approach that can bring more participants to our project and open it up for more acceptance and success.

I might be missing something, but I have not come across any structured suggested approach on how to do with that so here are my thoughts: one of the Key Project Artifacts is a Concern (see screenshot below). Concern can be opened by any member of the project team or any stakeholder and, in Project Ground rules is considered the only media where people can express their concerns or ideas regarding Project's agenda, objectives, goals, deliverable, schedule or any other critical component.

Concern can be further linked to a Risk or an Issue. It is being raised against a party - usually a Role in the Project or Group of participants, i.e. Consultant, Developer, PM, etc. It has top be either Dismissed or declared Valid. If declared Valid, a Risk should be associated to a Concern which will fall under your Risk Management (I will definitely address this in my further blogs). The following list some of the statuses you can use to manage Concerns: {Concept; Raised; Under Review; Valid; Dismissed; Deferred}. Those statuses can be managed thru a workflow, process driven (i.e. Ground Rule says that only PM can change the status) or managed thru field level security http://kwizcom.com/ProductPage.asp?ProductID=1048&ProductSubNodeID=1049 in case your PMIS is SharePoint based.

See you next time

SharePoint PMIS - basic principles

2009-06-09T08:14:00.001-07:00

In my previous blog i have mentioned some key principles that have to be used in successful Project Management Information system. Let us focus today on Visual.
On of the issues with any PM system is the enormous amount of information team members usually have to go thru. So what's usually happening, is that team members, for example, Developer would create a link to the page showing assigned tasks and will never even attempt to navigate anywhere else by that building a silo. This is kind off defeats the purpose of the PMIS. On one hand, you as a Project Manager, wants them to get to the information they want or need to work with, but on the other hand, you want to keep this team alive and abreast with the Project - its Issues, Challenges and Concerns, Scope Changes, Lessons Learned, Risks, etc.
There are probably multiple ways to do that. I prefer using the following approach (i would use SharePoint here as an example of PMIS hosting platform):
1. Have main project page containing only high level generic information. I will talk about it in details later but in a nutshell - Mission, Objectives, RACI Matrix, Milestones, Overall Project Health Status, Document Library with Detailed Project Schedule and Meeting Minutes and possibly - acute and urgent open Issues and useful Links. Team Members are asked to provide any feedback on any on of those Main-Page artifacts during the regular Stand Up Review Meetings (in case you are using SCRUM)
2. Left side navigation area (Quick Launch) would have Role or Phase or Deliver-based headers with links to dedicated pages with the relevant (time-based) content that you want team to use to view and report on personal tasks, for example, or anything else you would like your team members to work on; or Phase Delivery Checklists
Tip: you, as a PM, might want to change URLs once in a while at the first phase of building the team culture to assure that people are not necessarily saving the direct link to the "personal" page but using PMIS navigation. This is very important when working with large and geographically dispersed teams or multiple organizations with different cultures

Stay tuned...

SharePoint as a PM and BA Tool

2009-06-08T10:28:00.000-07:00

There are couple of things I like about SharePoint:
1. It can really reduce the Total Cost of Ownership and make software delivery process much more lean by configuring a solution in "no time" for a user and work with the user community, which I find being more visual and analytical to finalize requirements
2. I came up with this term that helps me explaining the benefits of this platform to users: VETO which stands for Visual, Empowering, Transparent and Obvious. I use this for my PMIS (Project Management Information Systems) sites building up the main site page to show 80%-90% of the information Team Members are looking for when working on a project.
I will use my next blogs to give more examples and talk about the way you can make your Project be more successful simply by tuning up the message to users and make key Project Artifacts transparent and "named" identifying ownership
Stay tuned