**Developing an Implementation Plan with Iterations by Russ Pitts **

Ok, so you have come to grips with understanding that applying the iterative concept, as defined by OUM is simply breaking up the project effort you have estimated for each phase into one or more six week calendar duration blocks of work.

Idea being the business user(s) or key recipient(s) of work product(s) being developed never go longer than six weeks without having some sort of review or prototyping of the work results for an iteration…”*think-a-little”,* *“do-a-little”*, and *“show-a-little”* in a six week or less timeframe…*ideally the business user(s) or key recipients(s) are involved throughout.
*

* *

You also understand the OUM concept that you only plan for that which you have knowledge of. The concept further defined, a project plan initially is developed at a high-level, and becomes more detailed as project knowledge grows. Agreeing to this concept means you also have to admit to the fallacy that one can plan with precision beyond six weeks into a project…Anything beyond six weeks is a best guess in most cases when dealing with software implementation projects.

Project planning, as defined by OUM begins with the Implementation Plan view, which is a very high-level perspective of the effort estimated for each of the five OUM phases, as well as the number of iterations within each phase.

You might wonder how can you predict the number of iterations for each phase at this early point in the project. Remember project planning is not an exact science, and initially is high-level and abstract in nature, and then becomes more detailed and precise as the project proceeds.

So where do you start in defining iterations for each phase for a project?

The following are three easy steps to initially define the number of iterations for each phase:

**Step 1 => Start with identifying the known factors…
**

** **

*…Prior to starting a project you should know:
*

* *

<!--[if !supportLists]-->· <!--[endif]-->The agreed upon time-period for an iteration (e.g 6 weeks, or 4 weeks, or…) within a phase (recommend keeping iteration time-period consistent within a phase, if not for the entire project)

<!--[if !supportLists]-->· <!--[endif]-->The number of resources available for the project

<!--[if !supportLists]-->· <!--[endif]-->The number of total number of man-day (effort) you have estimated for each of the five OUM phases of the project

<!--[if !supportLists]-->· <!--[endif]-->The number of work days for a week

**Step 2 => Calculate the man-days of effort required for an iteration within a phase…
**

** **

Lets assume for the sake of this example there are 10 project resources, and you have estimated 2,536 man-days of work effort which will need to occur for the elaboration phase of the project. Let’s also assume a week for this project is defined as 5 business days, and that each iteration in the elaboration phase will last a calendar duration of 6 weeks. A simple calculation is performed to calculate the daily burn rate for a single iteration, which produces a result of…

*((Number of resources * days per week) * duration of iteration) = Number of days required per iteration
*

* *

((10 resources * 5 days/week) * 6 weeks) = 300 man days of effort required per iteration

**
**

** **

**Step 3 => Calculate the number of iterations that can occur within a phase
**

** **

Next calculate the number of iterations that can occur for the amount of man-days of effort estimated for the phase being considered…

*(number of man-days of effort estimated / number of man-days required per iteration) = # of iterations for phase
*

* *

*(2,536 man-days of estimated effort for phase / 300 man days of effort required per iteration) = 8.45 iterations, which should be rounded to a whole number such as ***9 iterations***

* *

*Note - It is important to note this is an approximate calculation, not an exact science. This particular example is a simple one, which assumes all resources are utilized throughout the phase, including tech resources, etc. (rounding down or up to a whole number based on project factor considerations). It is also best in many cases to round up to higher number, as this provides some calendar scheduling contingency.