Project Management Form
______________________________________________________________________________
Project
Scorecard
______________________________________________________________________________
Prepared By: Doug Friend
Date of Publication: 10/03/05
Location : P:\shared
___________________________________________________________________________________________
Revision History
|
Version |
Date |
Author(s) |
Revision Notes |
|
1.0 |
|
DDF |
|
|
|
|
|
|
|
|
|
|
|
Identify criteria for success. Review the objectives and
deliverables in the Project
Definition, as well as any other existing information that is relevant to the
project. Based on this existing documentation, define what information
is needed to show that the project was successful. This can be from two perspectives:
·
Internal – These characteristics indicate that the project
was managed and executed effectively and efficiently. This might include having
deliverables approved with no more than two review iterations, hitting major
internal milestone dates on time and having a minimum amount of errors
uncovered in user acceptance testing.
·
External – These characteristics indicate that your project
objectives were completed successfully. Examples here include completing the
project within approved budget and timeline, ensuring your deliverables meet
approved quality criteria and customer satisfaction surveys.
Assign potential metrics. Identify potential metrics for each success criteria that provide an indication of whether or not the criteria are being achieved. These can be direct, quantifiable metrics, or indirect metrics that give a sense for success criteria. For each metric, briefly determine how you would collect the information, what the effort and cost of collection would be, and what value would be obtained.
Look for a balance. The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the project. For instance, you do not want to end up with only a set of financial metrics, even though they might be easiest to obtain. In general, look for metrics that provide information in areas such as:
· Cost – We will benefit from having project estimates to follow guidelines that give us selling price and cost for each phase. Even if your proposal shows one project number it needs to be broken down for quality measurements.
· Effort – What will it take in man hours? Think minimum, maximum, risk level?
·
Duration
– We will apply resources as efficiently as possible, with the recent hires
on the Microsoft and the development side this will help in time. Expectation
must be set properly in that it will take some time to ramp up. Allen Tobey has
worked here before so that should help expedite the ramp up.
·
Productivity
– We do what we can, PFW asked for another engineer involved they received
help from Erik who did a great job. He helped with Right Source as well.
·
Quality
of deliverables – Starts with the Sales Managers identifying the
deliverables and expectations.
· Customer satisfaction with the deliverables produced – Understanding, managing and influencing needs so that customer expectations are met. This requires a combination of conformance to requirements (the project must produce what we said it would) and fitness for use (the product or service produced must satisfy a real needs).
· Project team performance – What are some ideas for metrics?
·
Business
value delivered- Each project has business value.
Prioritize the balanced list of metrics: Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the project. There can certainly be as many metrics collected as makes sense for the project, but there may end up being no more than one or two per category. In general, look to provide the most information with the least amount of work.
Set targets:
The raw metric may be of some interest, but the measure of success comes from
comparing your actuals against a predefined target. The target may be a single
value you are trying to achieve, or it may be a range. For instance, you may
need to complete your project by a certain fixed date, but your actual cost
might need to be +/- 10% of approved budget. We need to identify a budget for projects?
Add workplan detail: For each metric that remains, determine the specific information necessary to add the appropriate activities to the project workplan. This will include:
· What specific data is needed for the metrics?
· Who is responsible for collecting the metrics?
· When will the metrics be collected and reported?
· How will the metrics be reported (status reports, quarterly meetings, metrics reports)?
(Remove this comment section from final document.)
Potential Scorecard Metrics
1. Identify criteria for success
2.
Assign
potential metrics
3.
Look
for a balance
4. Prioritize the balanced list of metrics
(Remove this
comment section from final document.)
|
Int |
Success Criteria
(1) |
Potential Metric
(2) |
Balance Category
(3) |
Priority |
|
Int |
The project team must communicate
proactively. All project status reports must be completed on time and sent to
the project manager |
The percentage of status reports
that are late / number of status reports due per month |
Project Team Performance |
M |
|
Int |
The deliverables must be correct
the first time. We must establish completeness and correctness criteria for
all major deliverables. |
Each major deliverable must have
customer approved completeness and correctness criteria (100%) |
Project Team Performance |
H |
|
Ext |
We must deliver this project by
year end |
The date that the project is
formally approved by the sponsor |
Duration |
H |
|
Ext |
The application must have quick
response time |
The average system response time
at peak utilization, between 1:00 and 3:00 PM. |
Quality (Performance) |
L (hard to
collect) |
|
Ext |
The application must have quick
response time |
Survey the end users to determine
their satisfaction level with overall response time |
Quality (Performance) |
H (easy to
collect) |
|
|
|
|
|
|
|
|
|
|
|
|
For those balanced metrics that are of the highest priority (easiest to collect / least cost)
1. Set targets.
2. Add workplan detail.
|
Metric List the metrics that you are actually going to
collect. |
Target (5) What is the unit of measure? What is our
performance target? |
Data Needed (6) |
Metric Gathering (6) Who
is responsible for collecting the metric and how often? |
Metric Gathering (6) How are we going to collect the data? |
Metric Sharing (6) How
will we share the information and how often? |
|
status
reports late / status reports due |
No
more than 5% late |
# status reports due # status reports late |
project manager monthly |
manually |
quarterly status reports and at the
end of the project |
|
deliverables
with C & C criteria / # major
deliverables |
100% |
# deliverables with C & C criteria
# major deliverables |
lead analysts Monthly |
manually |
quarterly status reports and at the
end of the project |
|
formal
project approval date |
December
31 |
formal acceptance document signed by
the sponsor |
project manager |
manually |
final status report at end of project |
|
system
response time |
satisfaction
survey average
3.5 out of a 5.0 scale |
survey to end users |
implementation leader |
Manually, using email survey |
final status report at end of project |
Sample Categories and Metrics
The following list provides ideas on the types of metrics that could be reported. This list is not exhaustive by any means, but may help provide additional ideas for your project. What we need to do is identify what metrics we are interested in tracking?
|
Balance Category |
Sample
Metrics
|
|
Cost |
Actual cost vs. budget
(variance) for project, for phase, for activity, etc. Total support costs for x
months after solution is completed Total labor costs vs. non
labor (vs. budget) Total cost of employees vs.
contract vs. consultant (vs. budget) Cost associated with
building components for reuse Total cost per transaction Ideas for cost reductions
implemented, and cost savings realized |
|
Effort |
Actual effort vs. budget
(variance) Amount of project manager
time vs. overall effort hours |
|
Duration |
Actual duration vs. budget
(variance) |
|
Productivity |
Effort hours per unit of
work/function point Work units/function points
produced per effort hour Effort hours reduced from
standard project processes Effort hours saved through
reuse of previous deliverables, models, components, etc. Number of process
improvement ideas implemented Number of hours/dollars
saved from process improvements |
|
Quality of Deliverables |
Percentage of deliverables
going through quality reviews Percentage of deliverable
reviews resulting in acceptance the first time Number of defects
discovered after initial acceptance Percentage of deliverables
that comply 100% with organization standards Percentage of deliverables
that comply with organization architectural standards Number of customer change
requests to revise scope Number of hours of rework
to previously completed deliverables Number of best practices
identified and applied on the project Number of risks that were
successfully mitigated |
|
Customer Satisfaction with
Deliverables |
Overall customer
satisfaction with deliverables in terms of: (survey) Reliability Minimal defects Usability Response time Ease of use Availability Flexibility Intuitiveness Security Meets customer needs Easy to understand messages
User documentation Application response time
(calculated by the system) Number of approved business
requirements satisfied by the project |
|
Customer Satisfaction with
Project Team |
Overall customer
satisfaction with the project team in terms of: (survey) Responsiveness Competence Accessibility Courteousness Good communication Credibility Knowledge of the customer Reliability / follows
through on commitments Professionalism Training provided Overall customer
satisfaction Turnaround time required to
respond to customer queries and problems Average time required to
resolve issues Number of scope change
requests satisfied within original project budget and duration |
|
Business Value |
Based on the cost/benefit
analysis or the value proposition that was created when the project was
approved and funded. |