Description
Speed Indicators-quantifiable measurements that reflect the critical success factors of a project or organization. These measures use measurements that can be used to track the progress in achieving important goals within an organization.
Project Management on
Steroid’s
“Using Speed Indicators”
Definition
• Speed Indicators-quantifiable
measurements that reflect the
critical success factors of a project or
organization. These measures use
measurements that can be used to
track the progress in achieving
important goals within an
organization.
Team-Priority Number One
• Your team is your number one focus, without the
team you don’t have a project. Without your
team the schedule versus cost factor is just an
exercise, you MUST have a team to schedule and
a team to generate project costs. You'll also start
to allocate costs to the individuals on the team
and to the tools (software, computers, and
servers) that they will need to successfully
develop the project. Although YOUR team is the
first focus, it's easy to see that the schedule
time/cost factor/risk factor work in tandem with
the team factor.
Team Indicators
1. Skills-What skills are going to make your application
development project a success. At this point you
will need to evaluate your skill sets amongst your
assembled team. You can assign skill levels to team
members (from novice/intermediate/expert.
2. Team Supervision-Teams come in all shapes and
sizes as do the individuals who work on them, one
type of supervision for all members of the team will
not work. As a PM/Scrum-Master you will have to
decide who requires one on one supervision,
occasional supervision, and who is self-directed.
Schedule Indicators
1. Tech Events related to Schedule/Cost-They are
VERY hard to predict, there
unpredictability/frequency in all projects can
put a damper on both Costs and Schedule
creating a runaway project. You must look out
early in a project, maintain constant risk
planning.
2. Quality Review Related to Schedule/Cost-
Discussions should start on quality assurance.
The business will usually determine the quality
of the project because you will have to meet the
business/stakeholders expectations of a
successful project (application).
Risk Indicators
1. Quality Assurance (testing)-You must “plan to test and to
test early and very often”, these are basic traits of the Agile
methodology “conduct your tests throughout construction of
the application” The team knows the requirements, the
developers can work in unison with the quality assurance
team to create the “unit tests” so after testing each unit the
total product will be tested at delivery time, in Agile delivery
time is each 2 week iteration.
2. Updating Plans (2)
• Communication Plan-Includes all information on the
business/stakeholders that you will need to communicate
during the course of the project.
• Procurement Plan-Reliable numbers, emails, and contact
names to all the suppliers/contractors/vendors on your
projects.
Scope the Project
• So the business/stakeholder has defined the scope of the
project, the scope of the project is the set of objectives for
the project that will be undertaken. As the project plan
comes together you are going to have to break down the
scope of the project into smaller pieces all the way down to
the individual task level. When you share the scope of the
project completely with your team you will need to give
them the full insight into the development the project. Bring
everyone together to detail the scope from inception to
completion and try to use some kind of media (power-point,
visio, and white-boards) to convey the new application.
Plan the Project
• Once the team has seen the complete scope of the project
you will need to indentify the skill sets that will be needed to
complete the project. Try not to add all team members to all
planning sessions because in my experience it is a receipt for
things going awry. All of your team members have to be
involved in at least one of more of the meetings so they feel
they are contributing to the overall success of the project.
Schedule your meeting for no more than an hour, planning
for a project is specialized focused and has objectives. Once
completed you should have some deliverables defined in the
scope. Try to detail each team session, what is the outcome?
The outcome from these sessions will fit into your project
plan, and documentation from the sessions, (activities, tasks,
time estimates) can be added.
Create the WBS
“Work Breakdown Structure”
• All the results of your planning sessions
are known by the
leaders/stakeholders/business. You know
what the project end game is all about,
and what the project will look like so its
time to create the “work breakdown
structure” or WBS.
• Work Breakdown Structure (WBS)-is a list
of all the tasks that will be performed on
the new project and are broken down to
small units to help in the manageability of
the work.
Work Breakdown Structure
Execute the Plan
• Start by assigning team leaders to help develop
parts of the plan for your planning sessions. Give
them YOUR expectations of their role, make sure
that the leaders understand all the small tasks
that have to happen so they can delegate them
and focus on the development of the application.
Start having planning execution meetings and
make sure the leaders have all their plans for
development of the application ready. Go over
each plan at a high level and ask questions, the
key here is to make sure that everyone is on the
same page.
Development Starts
• Now your team can start the “real work” of the project, and
now you are very dependent on your team leaders, teams
and the business/stakeholders. You must have meetings at
regular intervals, this is where Agile comes into play, the
“daily stand-up” should follow these guidelines.
•
• Meetings start on time Always!
• Meetings last no longer then 15 minutes
• Same place, same time, same location All the time!
Three Questions should be answered by all Team
Members during these meetings
1. What did you do yesterday?
2. What are your plans today?
3. Any issues that prevent you from accomplishing your
goal?
Final Thoughts
• It will be your role as the Project Manager or Scrum Master
to facilitate resolutions for any impediments. Also do these
OUTSIDE of this meeting (daily stand-up) so the stand-up can
run the 15 minutes of allotted time you give it each day.
Keep the team’s momentum up; Agile helps your cause
because you are working in 2 or 4 week iteration cycles
delivering working software every iteration. With Agile
Project Management/Scrum-Master it’s not a hand-off
scenario, you have to communicate daily and face to face
with your team members driving your involvement and your
commitment to the development project.
About the Author
Paul Gravina has been working in the Information
Technology arena for the past 15 years. He has worked in a
variety of roles related to technology such as Quality
Assurance, Business Analyst and Project Management. He
has been certified as a Six Sigma Green Belt and is the owner
of Agile Management Solutions an IT contracting firm. Paul
also contributes to the blog Agile Management Solutions.
doc_463785781.pptx
Speed Indicators-quantifiable measurements that reflect the critical success factors of a project or organization. These measures use measurements that can be used to track the progress in achieving important goals within an organization.
Project Management on
Steroid’s
“Using Speed Indicators”
Definition
• Speed Indicators-quantifiable
measurements that reflect the
critical success factors of a project or
organization. These measures use
measurements that can be used to
track the progress in achieving
important goals within an
organization.
Team-Priority Number One
• Your team is your number one focus, without the
team you don’t have a project. Without your
team the schedule versus cost factor is just an
exercise, you MUST have a team to schedule and
a team to generate project costs. You'll also start
to allocate costs to the individuals on the team
and to the tools (software, computers, and
servers) that they will need to successfully
develop the project. Although YOUR team is the
first focus, it's easy to see that the schedule
time/cost factor/risk factor work in tandem with
the team factor.
Team Indicators
1. Skills-What skills are going to make your application
development project a success. At this point you
will need to evaluate your skill sets amongst your
assembled team. You can assign skill levels to team
members (from novice/intermediate/expert.
2. Team Supervision-Teams come in all shapes and
sizes as do the individuals who work on them, one
type of supervision for all members of the team will
not work. As a PM/Scrum-Master you will have to
decide who requires one on one supervision,
occasional supervision, and who is self-directed.
Schedule Indicators
1. Tech Events related to Schedule/Cost-They are
VERY hard to predict, there
unpredictability/frequency in all projects can
put a damper on both Costs and Schedule
creating a runaway project. You must look out
early in a project, maintain constant risk
planning.
2. Quality Review Related to Schedule/Cost-
Discussions should start on quality assurance.
The business will usually determine the quality
of the project because you will have to meet the
business/stakeholders expectations of a
successful project (application).
Risk Indicators
1. Quality Assurance (testing)-You must “plan to test and to
test early and very often”, these are basic traits of the Agile
methodology “conduct your tests throughout construction of
the application” The team knows the requirements, the
developers can work in unison with the quality assurance
team to create the “unit tests” so after testing each unit the
total product will be tested at delivery time, in Agile delivery
time is each 2 week iteration.
2. Updating Plans (2)
• Communication Plan-Includes all information on the
business/stakeholders that you will need to communicate
during the course of the project.
• Procurement Plan-Reliable numbers, emails, and contact
names to all the suppliers/contractors/vendors on your
projects.
Scope the Project
• So the business/stakeholder has defined the scope of the
project, the scope of the project is the set of objectives for
the project that will be undertaken. As the project plan
comes together you are going to have to break down the
scope of the project into smaller pieces all the way down to
the individual task level. When you share the scope of the
project completely with your team you will need to give
them the full insight into the development the project. Bring
everyone together to detail the scope from inception to
completion and try to use some kind of media (power-point,
visio, and white-boards) to convey the new application.
Plan the Project
• Once the team has seen the complete scope of the project
you will need to indentify the skill sets that will be needed to
complete the project. Try not to add all team members to all
planning sessions because in my experience it is a receipt for
things going awry. All of your team members have to be
involved in at least one of more of the meetings so they feel
they are contributing to the overall success of the project.
Schedule your meeting for no more than an hour, planning
for a project is specialized focused and has objectives. Once
completed you should have some deliverables defined in the
scope. Try to detail each team session, what is the outcome?
The outcome from these sessions will fit into your project
plan, and documentation from the sessions, (activities, tasks,
time estimates) can be added.
Create the WBS
“Work Breakdown Structure”
• All the results of your planning sessions
are known by the
leaders/stakeholders/business. You know
what the project end game is all about,
and what the project will look like so its
time to create the “work breakdown
structure” or WBS.
• Work Breakdown Structure (WBS)-is a list
of all the tasks that will be performed on
the new project and are broken down to
small units to help in the manageability of
the work.
Work Breakdown Structure
Execute the Plan
• Start by assigning team leaders to help develop
parts of the plan for your planning sessions. Give
them YOUR expectations of their role, make sure
that the leaders understand all the small tasks
that have to happen so they can delegate them
and focus on the development of the application.
Start having planning execution meetings and
make sure the leaders have all their plans for
development of the application ready. Go over
each plan at a high level and ask questions, the
key here is to make sure that everyone is on the
same page.
Development Starts
• Now your team can start the “real work” of the project, and
now you are very dependent on your team leaders, teams
and the business/stakeholders. You must have meetings at
regular intervals, this is where Agile comes into play, the
“daily stand-up” should follow these guidelines.
•
• Meetings start on time Always!
• Meetings last no longer then 15 minutes
• Same place, same time, same location All the time!
Three Questions should be answered by all Team
Members during these meetings
1. What did you do yesterday?
2. What are your plans today?
3. Any issues that prevent you from accomplishing your
goal?
Final Thoughts
• It will be your role as the Project Manager or Scrum Master
to facilitate resolutions for any impediments. Also do these
OUTSIDE of this meeting (daily stand-up) so the stand-up can
run the 15 minutes of allotted time you give it each day.
Keep the team’s momentum up; Agile helps your cause
because you are working in 2 or 4 week iteration cycles
delivering working software every iteration. With Agile
Project Management/Scrum-Master it’s not a hand-off
scenario, you have to communicate daily and face to face
with your team members driving your involvement and your
commitment to the development project.
About the Author
Paul Gravina has been working in the Information
Technology arena for the past 15 years. He has worked in a
variety of roles related to technology such as Quality
Assurance, Business Analyst and Project Management. He
has been certified as a Six Sigma Green Belt and is the owner
of Agile Management Solutions an IT contracting firm. Paul
also contributes to the blog Agile Management Solutions.
doc_463785781.pptx