Building a Project Dashboard

Use Windows SharePoint Services to create a project-tracking portal for your developers.

Agile teams already using Windows SharePoint Services (WSS) to manage product and sprint backlogs can also use WSS to create a project dashboard. The dashboard offers an easy-to-use, one-stop shop for project status, reporting roadblocks, evaluating progress and keeping track of assignments.

The project dashboard is simple to build. By starting with a WSS Web part page, you can customize it to meet the needs of your project team based on content that you already have on your site.

Figure 1 shows a project dashboard from a fictional project called CubiQ, in which the project team is building a cubicle-management system. Although this project is fictional, the layout is typical of an agile project, and divided into five sections: project overview, current status, product backlog highlights, roadblocks and burn-down chart.

Figure 1. Project Dashboard
[click image for larger view]
Figure 1. The overview page puts up-to-date project information in front of all engaged parties, and allows quick drill down to the various modules.

We'll discuss how you create each one of these sections in this article. You can add other sections as needed, or customize the page to work with other project management methodologies. The final section of this article lists some other ideas I've had for content on a project dashboard that might be helpful.

Project Overview
Project stakeholders don't always remember the specifics of your particular project, especially in a large organization. The project overview section of the dashboard helps them put your project in the context of its scope and schedule.

The project overview is a content editor Web part that you can add content to. I normally grab some text describing my project, usually from the documentation (project charter, etc.) that I created as part of the initial justification. The text needs to describe the objectives and deliverables of the project in a succinct, straightforward way. It must also make sense to people on the periphery of your project, who might drop into your project site for a look around.

Current Status
The current status is just an announcement list. I'm typically asked to give a weekly status update to stakeholders, so I use this section to summarize and point out areas where we could use help. I set the announcement to expire after a week, so it's always up to date. If you're expected to provide a more detailed status report document, you can link to it from here.

If you measure velocity and use it to project an end date for your work, be sure to include that data in the current status field every time you update either the status or the burn-down chart.

Product Backlog Highlights
The product backlog is a prioritized list of all the features the project will implement over the course of the effort. In an agile project, this list is reprioritized at the start of every sprint to ensure the project team is always working on the most valuable features. Since project priorities can change frequently, it's important to have a dynamic view of the features as they're currently scheduled.

The product backlog highlights section helps stakeholders understand the big picture. It shows them which features have already been implemented, what's currently being worked on and what's coming next. This section is just a view of your product backlog list, grouped by the values in the "sprint" field. Another option is to create a "current sprint features" view that shows only the features from the current sprint. You might choose this approach on a large project with lots of features.

It's up to the project manager -- or "scrummaster" -- to remove roadblocks, or obstacles impairing progress. It's easy for me, as the project manager, to lose sight of my responsibility to get these obstacles out of the way and help my project team move forward. By putting these roadblocks front and center on the dashboard where everyone can see them, I force myself to focus on resolving them as quickly as possible. It's my goal to remove roadblocks in a day or less, every time.

The roadblocks section is a view of the sprint backlog that includes only tasks that are identified as being blocked. As soon as a team member identifies a task as being blocked, it appears in this view.

Burn-Down Chart
The burn-down chart is a key feature of agile project management. It tells you how fast you're moving, how much work remains and when you might complete the project based on the pace of progress so far. It's a fairly simple chart-a line graph of hours (or dollars) of work remaining before the project is complete -- that's updated regularly, preferably on a daily basis.

The slope of the line is called the "velocity" or sometimes "burn rate." It tells you how quickly you're progressing. If you extend the line to where it crosses the X-axis you'll find the projected end date of the project. It's important to note that the "work remaining" is an estimate based on the items remaining in your product and sprint backlogs. Sometimes, such as when you're planning the next sprint, that estimate will temporarily go up as you add more detailed tasks to a feature that was previously estimated at only a high level.

Creating a burn-down chart in WSS 3.0 isn't as easy as it ought to be. I typically export the product backlog and sprint backlogs to Excel, create the chart there and then export the chart as a graphics file. I can then add this file to my dashboard using a content editor Web part. Once the Excel file is set up, updating the chart is a manual but easy process -- I just synchronize the data between Excel and my custom lists and export the chart again.

I'd love to have a built-in burn-down chart in WSS 3.0. A burn-down view of a sprint and product backlog list would be a fantastic addition to WSS 3.0. That would make managing an agile project with Windows SharePoint Services a piece of cake.

Other Ideas for Customization
Once you get started using WSS 3.0 to create a project dashboard, you'll find yourself generating lots of ideas for using it. Here are a few I've experimented with:

Project logo: Create a logo and display it on your dashboard. Some places like to code-name projects after cartoon or video game characters. Why not put a picture of the character on your dashboard?

Tabs: WSS 3.0 lets you assign tabs across the top of your site. Add your dashboard page to the top link bar in site settings to make your dashboard easy to find.

Useful links: Create a list of useful project links to project documents and tools to help team members find their way around. You can also create groups of useful links for testers, developers and stakeholders.

Current build version, features and known issues: Post a list of known issues in the current build, so testers will waste less time reporting duplicate bugs.

My tasks: If you based your sprint backlog on a WSS task list, you can create a "my tasks" view of the list that shows only the tasks assigned to the user viewing the list. Having a "my tasks" list right on the dashboard helps project team members focus their efforts.

Risks and issues: If you track risks and issues formally you can display high profile risks and issues on your dashboard. Just add a "display on dashboard" yes/no field to the list, with a corresponding view, and put that view on your dashboard.
comments powered by Disqus

Reader Comments:

Mon, Oct 20, 2008 Anonymous Anonymous


Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above