Project Score Card
LOW RISK/COMPLEXITY MEDIUM RISK /COMPLEXITY
Intermediate total cost, e.g., $100K -
Low total cost, e.g., $1 - <$100K
<$1M
Incremental effect on goals and Clear effect on one or more of the
objectives of a single department or business goals of multiple departments
unit or units
Intermediate sized project team, e.g.,
Small project team, e.g., 1-4 people
5-10 people
Small number of departments/units, Intermediate number of
e.g., 1-2 dept's departments/units, e.g., 3-4 dept's
Average project duration, e.g., >6
Short project, e.g., 1 day - <6 months
months - <24 months
Technology is developed but not in
Proven and tested technology,
widespread use or is new and recently
techniques, and procedures
released
Limited availability or still in beta
Widely and commonly available
testing
Project team experienced with Project team only familiar with
technology, needs no training technology, may need training
Schedule is not fixed and therefore Schedule can tolerate some
flexible variation/td>
None to a few (1-2) schedule
Several (2-5) schedule dependencies
dependencies
Less than 50% of project resources
No external resources needed
from external sources
Project lead collects requirements from
Business analyst collects requirements
sample of stakeholders. Fairly
from most stakeholders. Fairly
confident captured primary
confident captured all requirements
requirements
Externally mandated requirements
outside the project owner organization
No externally mandated requirements
from department(s) within the
university
Alpha/Beta testing is conducted by a
Pilot phase, with end user involvement representative group of end users on
and testing planned the developer's side and sometimes by
independent team of testing
Mid-project or only end of project,
Continuous (i.e., for entire project
project metrics defined. Some non-
lifecycle) project metrics defined with
quantifiable measures used, e.g.,
quantifiable measures
improved process
No sensitive data, or data does not Data persists outside of the origin
persist outside of the origin system it system it was obtained from and is
was obtained from encrypted
The project level indicators are to be used in conjunction with the Project Scorecard and management experience a
Projects at low, medium or high risk
levels show some or all of the following
properties:
HIGH RISK/COMPLEXITY
High total cost, $1M+
Effects strategic direction of
department or unit, or university-wide
goals
Large project team, e.g., >10 people
Large number of departments/units,
e.g., >4 dept's
Long project duration, e.g., 24+
months
Leading edge technology still in
development, not released
In alpha testing
Project team unfamiliar with
technology and needs education and
training
Schedule is fixed and can not be
changed
Many (>5) schedule dependencies
More than 50% of project resources
from external sources
Project lead collects requirements from
project team and sponsor only. Not
confident captured all requirements
Externally mandated requirements
outside the project owner organization
and outside the university
None or developer testing only
No project metrics defined or non-
quantifiable measures used
Data persists outside of the origin
system it was obtained from without
encryption
ROCESS OR STAGETRADITIONAL (WATERFALL) GUIDELINESAGILE GUIDELINES
Initiation Processes
Or
Product vision
Agree to a vision for the project, define the major goals & project justification (why do this project)
Bring together the core team members and the stakeholders
Assign a project manager and establish others' roles and responsibilities
As much as possible, identify the resources needed, the cost estimates, and a broad timeline
Obtain approval to move forward with detailed planning
Recommended documentation:
IT Project Initiation Form
IT Project Charter Template
Agile Guideline
Product vision
Definition of what your product is
How the product will support your company or organization’s strategy
Who will use the product
Recommended documentation:
IT Project Charter Template
Product roadmap
Create user stories
Identify Product owner
Identify Scrum Master
Identify Development Team
Process or Stage
Planning Processes
Or
Product roadmap
TRADITIONAL (WATERFALL) GUIDELINES
Collect requirements as needed. Some options include, focus group sessions, stated stakeholder requirements, an
Begin developing the project scope by describing, in sufficient detail, the project's deliverables and the work require
Begin development of a work plan that details the activities or tasks required, including time and cost estimates
Determine resources and staffing needs (resources can be special skills, hardware, software, services, etc.)
Identify special skills needed to accomplish project tasks
Assess project procurement needs of goods and services and determine best course of action
Develop a budget plan to include the life cycle cost or total cost of ownership, projected out 3-5 years
Assess the communication needs and prepare a communication plan if required
Perform a risk assessment, analysis, and plan, if required, and include mitigation options as appropriate
Assess the security issues for the project and its deliverable(s). Send a completed IT project security initial review
Analyze testing needs and plan accordingly
Assess training needs and develop a strategy or plan as appropriate
Plan for project changes and how they are documented and submitted, responsibilities, and steering committee me
Plan for project quality management including a strategy, quality assurance, and quality control activities
Analyze need for independent verification & validation (IV&V) and plan accordingly
Complete the scope document that includes how to verify completion of deliverables and how to manage scope ch
Document any lessons learned up to this stage in the project
Obtain approval to move forward with executing the project plan
Recommended documentation:
IT Project Scorecard
IT Project Security Initial Review
IT Project Scope form
Product roadmap
A high-level view of the product backlog
Loose time frame for when you will develop those requirements
Prioritizing and roughly estimating the effort for those requirements
Recommended documentation:
???
Executing Processes
Or
Release plan
TRADITIONAL (WATERFALL) GUIDELINES
Assemble and develop the project team (training, etc.)
Procure or secure required resources (hardware, services, software, etc.)
Review security plan with project team. Make sure security issues are prominent and addressed
Implement quality assurance procedures
Make project information and status available to stakeholders
Recommended documentation:
Status reports
Release plan
Identify a high-level timetable for the release of working software
Prioritize Product Backlog
Typical release includes three-to-five sprints
Create a release plan at the beginning of each release
Recommended documentation:
???
Monitoring & Controlling Processes
Or
Sprint planning,
Daily meetings,
Sprint review
Change control and management - modifications of original project scope, cost, schedule and technical strategies
Direct and lead the project team
Manage project progress
Implement quality control plan
As required, implement independent verification & validation (IV&V) plan
Measure project performance against the plan
Ensure project progresses according to the plan
Manage project issues and risks
Conduct status review meetings
Disseminate status reports
Implement testing plan
Plan for a final project security review. Send a completed IT project security final review form to the IT Security Off
As appropriate, implement training plan
Document any lessons learned up to this stage in the project
Obtain approval to close the project
Recommended documentation:
Status reports
For major projects: Independent Verification & Validation (IV&V)
IT Project Security final review
Sprint planning
Identify Definition of Done for that Sprint
Pick user stories from Product Backlog and create Sprint Backlog for that Sprint
Daily standup meetings
What you completed yesterday, what you will work on today, and any roadblocks you have
Sprint review, demonstrate the working product created during the sprint to the product stakeholders
Sprint Retrospective
Recommended documentation:
???
Closing Processes
Or
Sprint retrospective
Obtain acceptance of project deliverables
Outline the long-term operational implications then hand off operations and support responsibilities
Document or summarize costs spent on project and close any purchase orders
Document any timeline changes (schedule compression and/or overruns)
Document the lessons learned over the course of the project
Formalize closure
Obtain sign-off from project sponsor and project manager
Archive project documentation
Recommended documentation:
Lessons Learned
IT Project Closing form
Releasing the developed user stories to production
Recommended documentation:
???
ccomplish those deliverables
the IT Security Office
