Project Plan using RUP implemented in Microsoft Project

Question

I am rather new to PM and have done a lot of research on RUP. I am having a bit of a hard time structuring a software project plan using the RUP methodology.

The project has 4 distinguishable modules, each of which have different levels of difficulty. My current strategy has been to structure it as follows:

• Inception
  • Shared Tasks
  • Module 1:
    • List of Tasks
  • Module 2:
    • List of Tasks.
  • Shared Tasks
• Elaboration
  • Iteration 1
    • Module 1:
      • List of Tasks
    • Module 2:
      • List of Tasks
    • Feedback
  • Iteration 2:
    • Module 2:
      • List of Tasks
    • Feedback
• Construction
  • Iteration 1
    • Module 1:
      • List of Tasks
    • Module 2:
      • List of Tasks
    • Feedback
  • Iteration 2:
    • Module 2:
      • List of Tasks
    • Feedback
    • Testing
      • Iteration 1
      • Module 1:
        • Execute
        • Fix
      • Module 2:
        • Execute
        • Fix

You get the point. The structure is divided first by phase, then by iteration, then by module.

Is this the right strategy to use?

My concern is that the Iterations will leave tasks behind that are not completed and it will be rather difficult to deal with tasks that haven't been completed from Iteration 1, when we should be (formally) in Iteration 2, because Iteration 2 could have dependent tasks on Iteration 1.

Answer 1

Is this the right strategy to use?

I'm not quite sure. Maybe I've spent to much time in Agile and Lean projects, so I think planning a project based on a tool (RUP) is not a good idea. Although in RUP on paper the first two phases - inception, elaboration - are smaller than the third one - construction -, but in the real life they are almost as long as the construction phase. So it can happen that you spend a lot of money on inception and elaboration, but you won't deliver anything useful. I would approach the problem from the module point of view if you cannot use anything else but RUP.

• iteration 1

  • module 1
    • task 1
      • inception
      • elaboration
    • task 2
      • inception
  • module 2
    • task 1
      • inception

• iteration 2

  • module 1
    • task 1
      • construction
    • task 2
      • elaboration
  • ...

With this approach after each iteration:

• you'll learn more about the work

• your teams can work parallel

• you'll have something, which works, after each iteration

• you can refine your plan and make it more accurate

This would be the Agile approach.

My concern is that the Iterations will leave tasks behind that are not completed and it will be rather difficult to deal with tasks that haven't been completed from Iteration 1, when we should be (formally) in Iteration 2, because Iteration 2 could have dependent tasks on Iteration 1.

That's absolutely true, plus it can happen that working on a task in iteration 1 brings up issues, which will delay iteration 2 etc.

I don't want to convince you to do Agile, but if you have some time for reading another book, you may find good ideas and hints on project management in here: Agile Estimating and Planning by Mike Cohn