Automated Project Office Dashboard Screenshots

Editor's Notes

• #2: DISCLAIMER: These examples have been redacted in a variety of ways to protect customer data. Numeric values have been changed, and names have either been blurred out or changed entirely. In any examples where whole numbers or names are represented, those values have been altered significantly.
• #4: This tab represents current performance of 6 selected “key” KPIs, as well as average performance over time for the past 3 months. This is a division-level look at data from many projects, and can be drilled into by levels of the organization. Results are a combination of operational data from external systems and risk associated with contextual data from surveys.
• #5: This scorecard represents a portfolio view of several projects, with focus on several selected KPIs. The portfolio can be reorganized to sort by risk associated with any of the available KPIs. This solution is delivered at a 100-150 person IT shop with a nearly even split between on-shore and off-shore resources.
• #6: This screen represents a slightly more detailed view of project performance, including performance trends over time by reporting period (in this case, the customer assesses teams twice a month).
• #7: This tab represents results of a large (several thousand) satisfaction survey with helpdesk support across the organization. Data is sorted by department and physical geography, and results are anonymous. This solution is deployed at a large organization managing IT projects staffed by 400-500 individuals (per project). They are distributed across the continental US.
• #15: This implementation collects resource utilization data from several time/effort tracking systems and consolidates results, making the data reportable by project, role, or individual (both current utilization, and totals over time). This customer is a state government agency with an IT staff over 500.
• #17: This engagement represents planned vs. actual hours at a high level, along with status against milestones (all data in this example is derived from survey results)
• #18: In a different view of utilization, this instance represents forthcoming demand based on planned activities. Status (and delays) of current activities, coupled with forthcoming projects, presents total capacity and demand, filterable by date (results are combination of survey responses for current project status, along with imported data for time-on-task and pipeline). In this example, results are limited to 3 months in the future, but that is an artificial limit posed by the user.
• #20: At a more detailed level, staff count “swells” are shown over time to identify changes in projects with high resource consumption. Specific “key” metrics are also teased out as significant criteria to watch over time – any downward trending results in warnings.
• #21: Satisfaction is reported as a purely survey-based representation of data. Summary results of satisfaction on 6 criteria are reported, with the ability to drill down by role, portfolio, organization, or project. Results are reported over time as well as current status.
• #22: This implementation uses project plan data to plot degree of project completion over time, then also trends actuals as reported by the team via surveys to represent likelihood of completing on time. When the probable completion date extends beyond the planned date, the message text turns red and projects a new delivery date. Adjusting the date then turns the warning off. This deployment covers a large engagement managing many vendors for a single project – all constituents are rolled together to represent one overall picture of project status.
• #23: This screen represents relatively straightforward EVA data, in this example fed by an external financials spreadsheet. Data could come into the system via surveys or a direct feed as well.
• #25: This implementation is tracking ticket closure by month – reporting on overall resolution rates, and total open/closed within the month. In this example, the customer wants to show projects in the list even if they do not have any tickets to report for the month (normal behavior would be to show only the projects with tickets in the latest month displays). Totals are then rolled up to report over time, showing incidents by project, as well as overall for the entire organization. In this example, data is completely fed by an external system.
• #26: This example is a representation of external data evaluated against expectation guidelines and showing overall performance over the life of a project.
• #27: This is another representation of SLA-based data over time, broken out as a percentage. This particular customer wanted a decimal-based representation in order to align with other status reports already in place.
• #29: This tab allows a user to evaluate total participation in qualitative data collection, which can be represented by role, assessment, respondent, organization, or project. At a glance, a user can evaluate their overall confidence in data being reported back to them.
• #30: This screen represents a report-style summary of responses to assessments, broken out by phase.
• #31: The “standard” question response tab allows a user to consume distribution statistics for each question, and drill down by response, respondent, role, project, organization, or date. It also represents distribution of responses over time.
• #32: An alternative interpretation of the question response tab for a customer who wanted to be able to put specific emphasis on variation in response distribution from one week to the next.