Monday Mar 19, 2012

Developing an Implementation Plan with Iterations by Russ Pitts

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.

 

Monday Feb 06, 2012

Back to the Strategy

Methodologists are much like everyone else in that we are all too crazy busy to spend time reflecting on the past.  However, as I was preparing for a presentation at the 2012 JDE Summit last week, I found myself reflecting on the fact that I had returned to the site of an important milestone in the evolution of OUM.

It was seven years ago, in a conference room at the Oracle campus in Broomfield, Colorado, that several legacy Oracle, PeopleSoft and JD Edwards folks got together and sketched out what became Oracle’s method integration strategy.  We may have tweaked the actual wording since that meeting, but the foundations of the strategy have remained:

  • Support current methods (Compass, AIM, ABF, Siebel, DWM FT, etc.)
  • Develop a single, integrated method, to support the entire Oracle ecosystem, across all Oracle products (OUM).
  • Decommission legacy methods as the field transitions to OUM.

In the seven years since the initial meeting in Broomfield, this strategy has served as a solid foundation as OUM has evolved and many acquisitions have subsequently been brought into Oracle.  So I suppose that for even crazy busy people, there is benefit in reflecting back on the fundamental decisions that continue to drive our day-to-day tasks.

About

OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds