Project Management on Steroid’s

Project Management on Steroid’s

“Using Speed Indicators”

© 2010 Agile Management Solutions. (AMS LLC) All rights reserved.

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 Indicators1. 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 Indicators1. 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.


http://paulgravinaresume.blogspot.com/



http://agilemanagementsolutions.com/

http://agilemanagementsolutions.blogspot.com/

http://agilemanagementsolutions.blogspot.com/
