In the last post we discussed tracking. Some work items will often:
1. Take longer than anticipated.
2. Just not get done.
Then we came up with some ways you can incorporate these findings into your schedule.
This week we discuss what can be done to “save time” by doing work in parallel. I put saving time in quotes because the exercise may not save time by itself but it is still useful. What does doing work in parallel mean for us? It means taking tasks that were supposed to done by one person, assigning them to more than one person and executing the tasks independently of each other. This example can be extended from individuals to groups as well.
Some questions to consider:
1. What is my critical path? Assigning tasks that are not on the critical path to new team members will not shorten your project cycle. In Step 7 we briefly discussed critical paths. The important thing to remember:
a. “Calculating Critical Paths can be tricky. For small, simple schedules look for the longest path through schedule.”
Looking at what can be done out of sequence is a useful exercise in that it makes a team take a closer look at the project elements (architecture, process, resources).
2. Can the work be actually performed out of sequence? Some work items will seem like they can be done in parallel when in actual fact they cannot. This is where discussing the work with senior people is important.
3. Consider individual workloads. Giving work to someone that is unfamiliar with the task is not going to make the project go faster. Giving work to some that is already bogged down with work will not make the project go faster.
4. Creating a new critical path. There may be multiple task sequences in your schedule. By shortening one, you may reveal the next longest sequence in your schedule or inadvertently lengthen another (for example the testing cycle).
Prepare everyone for the debate about what can be done out of sequence. Some people don’t like change or doing things out of order. As a project manager be prepared to ask: why not? Make this an innovation challenge. Perhaps there is a way to develop a totally new process or tweak an existing process that will enable more people to work independently and out of sequence.
We'll discuss a output of this process next week, the question: Can we add more people to the schedule to speed things up?
Need help with your schedule? Email sterg@lamda-alpha.com
Experienced software project management when you need it. Leveraging the best of Agile,Scrum and PMBOK.
Monday, November 30, 2009
Friday, November 6, 2009
Step 12 of 44: That won't do, let's take a closer look at what's slowing things down.
As the schedule progresses you will notice:
1. Work that’s taking longer to do than anticipated.
2. Work that’s just not getting done.
In the case of work that’s taking longer than anticipated, try to figure out what causing the delay:
1. New work that wasn’t estimated. For example A and B were planned for but A, B, C, D is what is required. This is a typical and uncomfortable situation to be in. You can:
a. Replan with the new work – unpopular with management.
b. Work with the team to reduce scope.
c. Work with management to reduce scope.
d. Add more people – tricky.
e. Work more hours – unpopular with the team.
Typically the answer will lie in some combination of the above.
2. In the case where the work is not going as fast as anticipated. This could be due to:
a. Team members being pulled off to support existing customers – typical.
b. An inexperienced team member – even experienced developers haven’t seen everything.
c. Increased wait times for feedback – common and easy to forget to plan for.
d. Vacations.
e. Team member absence.
For the case of work that’s just not getting done consider:
1. Is the work still relevant? Can it be dropped?
2. Is the work in the wrong sequence?
Often you will find in software projects, that there are things that won’t get done because they are of lower priority. It’s a judgment call whether the work should be dropped from the schedule or added to the next cycle.
The important thing to remember is that you shouldn’t wait to address work that is not getting done or is delayed. The team will need to answer for it in one way or the other.
Stergios Spandonidis
Project Manager
sterg@lamda-alpha.com
www.lamda-alpha.com
1. Work that’s taking longer to do than anticipated.
2. Work that’s just not getting done.
In the case of work that’s taking longer than anticipated, try to figure out what causing the delay:
1. New work that wasn’t estimated. For example A and B were planned for but A, B, C, D is what is required. This is a typical and uncomfortable situation to be in. You can:
a. Replan with the new work – unpopular with management.
b. Work with the team to reduce scope.
c. Work with management to reduce scope.
d. Add more people – tricky.
e. Work more hours – unpopular with the team.
Typically the answer will lie in some combination of the above.
2. In the case where the work is not going as fast as anticipated. This could be due to:
a. Team members being pulled off to support existing customers – typical.
b. An inexperienced team member – even experienced developers haven’t seen everything.
c. Increased wait times for feedback – common and easy to forget to plan for.
d. Vacations.
e. Team member absence.
For the case of work that’s just not getting done consider:
1. Is the work still relevant? Can it be dropped?
2. Is the work in the wrong sequence?
Often you will find in software projects, that there are things that won’t get done because they are of lower priority. It’s a judgment call whether the work should be dropped from the schedule or added to the next cycle.
The important thing to remember is that you shouldn’t wait to address work that is not getting done or is delayed. The team will need to answer for it in one way or the other.
Stergios Spandonidis
Project Manager
sterg@lamda-alpha.com
www.lamda-alpha.com
Subscribe to:
Posts (Atom)