1) Highlights invisible bottlenecks
2) Allows you to detangle the issues before they materialize
Take a look at below diagram.
Critical Path Identification:
By taking the time to flowchart your tasks, which items can be conducted in parallel and which needs to be done serially (i.e. has some dependencies among them). By plotting out the parallel tasks in columns and the serial tasks in row, you forecast how long this current plan will take to execute.
At first glance, you may think that it will take a maximum of:
1 day to execute Task 1 list; maximum of 3 days to execute Task 2 lists; maximum of 2 days to execute Task 3, 2 days for Task 4 lists, 1 day for Task 5 and 2 days for Task 6. This totals 11 days.
But from the chart, you can see that there are three arrows going into and out of Task 3. This is a tale-tell sign that you have created a bottleneck. Task 3 cannot start it’s coding duties until all three of his previous tasks have completed and been delivered. Also, the rest of the team is in a ‘stop production’ mode until Task 3 is completed. This is something we need to ‘nip in the bud’ before any resources, design specifications and develop clocks are started.
Coding resource allocation in your Critical Path Charts:
Another helpful trick is to color-code your resources directly into your Critical Path Charts. In this example, each developer or resource has a different color assigned:
Once you have color-coded your critical path charts with your resources, you can now re-evaluate the time it will take your team to complete the task. You now see that (although your original estimate was three days to complete Task 2 lists) it will take at least 5 days to get through the Task 2 iteration because Dave is assigned to both Task 2a and Task 2b. The tasks themselves are not dependent upon each other (and therefore could have been done in parallel), Dave can only concentrate on one task at a time.
Once you have identified this issue, you can choose to:
1) Add time to the schedule
2) Assign one of the Tasks to another resource
3) Split and isolate specialized functions into separate routines, and have other people (not familiar with that specific technology) just call those specialized macros or routines.
By color coding our resources, we can visibly see when we are under or over utilizing our people. We can quickly see that perhaps we can split some of Dave’s duties in phase Task 2 to Dianne.
Since we have already identified Task 3 as a potential bottleneck and risk, we can investigate splitting that task into mini-tasks and assign to Dianne or Deek.
Since we have already identified Task 3 as a potential bottleneck and risk, we can investigate splitting that task into mini-tasks and assign to Dianne or Deek.
But what is Dave is the only person that can do this work? Not to worry. There are still things we can investigate to detangle Dave from this resource bottleneck.
For instance: If Dave is the only person that has Sequel Server knowledge, then isolate all the Sequel Server items from the rest of Task 3 goals. Have Dave create re-usable subroutines in which Dianne and Deek can call upon to accomplish the rest of the activities. Dianne and Deek doesn’t need to know exactly how the database works underneath. They only need to understand the essence of what they are trying to accomplish with the code and use the proper function calls.
0 comments:
Post a Comment