Iterations Methodology - Project Planning Chunking Algorithm and Method "80 Hour Rule"
Original Publication Date: 2008-Oct-31
Included in the Prior Art Database: 2008-Oct-31
No one likes to receive bad news on a project especially, the project manager and senior management. How well a problem is handled can depend on how quickly the problem is surfaced and reported. The following scenario illustrates this situation: A project manager has created a project. One of the tasks is to write a program with a high number of function points. The project manager has allocated nine weeks for the programmer to write the program. The project manager holds weekly status meetings. End of week 1: Project Manager: How's the program coming along? Programmer: Pretty good. End of week 2: Project Manager: How's the program coming along? Programmer: It's going well. I would estimate that I am already 70 percent done. End of week 3: Project Manager: How's the program coming along? Programmer: Still good. End of week 4: Project Manager: How's the program coming along? Programmer: Great. I think I am 80 percent done. Weeks 5 through 8: Project Manager: How's the program coming along? Programmer: It's going well. I'm about 80 percent done. End of week 9: Project Manager: Can I have my program? Programmer: It's still only about 80 percent done. Percentage complete is an insufficient model for a project manager to reflect on. Things are either not done or done. Because, the program is not ready, the project manager now has to react to a delay that may delay the project nine or more weeks depending on the type of problem the programmer was having. If the project manager had discovered that there was a significant problem with a deliverable within a two week period, the options available to the project manager and the project team may be more palatable than if the deliverable were nine or more weeks late. Discovering problems too late, minimizes the number of options a project manager has, and puts the manager in a negative reactive mode. Timely discovery, allows the manager to act positively and without unnecessary alarm. Our method for chunking deliverables, creates a disciplined approach to manage all types of deliverables -- especially those that may take many weeks or months to complete. Our method uses a chunking rule to control the duration of all project deliverables. By default, all identified deliverables must be completed within 80 hours. Eighty hours represents two business weeks for companies that use a 40-hour work week. In project management terms, 80 hours represents 80 hours of duration and not 80 hours of effort. The 80 hours is 80 contiguous work hours or two business weeks this is a duration. Effort represents the actual amount of time a person gets to spend on a deliverable. If a person can only spend one hour on a deliverable within the next two business weeks, then following our method, that one hour must produce a tangible deliverable. In our method, all deliverables are tangible and can stand-alone. Therefore, they do not represent a percentage of completeness, and are in of themselves complete. If a deliverable is targeted to last five weeks, the resource to the deliverable is responsible for breaking the deliverable into a minimum of three deliverables - where two of the deliverables potentially take two weeks each to complete and the third taking one week to complete. Example If a database administrator was tasked with creating and populating a data mart over five weeks where the data mart consists of two dimension tables and one fact table, the database administrator might create one of the dimension tables as one deliverable lasting 80 hours, the second dimension table as a second deliverable lasting 80 hours, and the fact table as a third deliverable lasting 40 hours. Advantage Using the chunking rule, when the project manager asks for a progress report, if the deliverable is not 100 percent complete within the chunked timeframe, the project manager can immediately react to a delayed deliverable. Reacting to something that is possibly two weeks late offers more options for mitigation that one that is months late. Main Claims A user defined chunking time period variable, x, in which all deliverables must be completed. The use of the variable to systematically ease project management through chunking. If a deliverable is targeted to last more than x then the deliverable is broken into n chunks where n = ceiling(deliverable total time / x); where each chunk n has <= x hours to complete the deliverable.