Menu

#38 Max hours for a task limited to 840

OPT_1.X_(Max)
closed
None
5
2003-10-16
2003-10-14
No

I know it's not good PM practice to define tasks with
loads of hours in it. Better divide it in subtasks.

However, I just ran into a requirement for such a high
number, where in phase 1 we define the plans for phase
2. Phase 2 is currently estimated for 1888 hours.
Well.. OPT is limited to 840. I tried to modify the
number check in tasks/task/add_form.inc ->
validate(form), but in the end OPT resets the value to
839:59 :-((

I would like to request a much higher limit, like 9999.

Thanks, Martin

Discussion

  • Anonymous

    Anonymous - 2003-10-16

    Logged In: YES
    user_id=22084

    You're running into a limit in the column type 'time'
    supported by MySQL. This is non-trivial to work around.
    I'd recommend that you use the groups within OPT.

    Project
    -> Milestones
    -> Request
    -> Task
    -> Sub-tasks ...

    In this case I would recommend that you split up this
    massive task into multiple requests grouped within a
    Milestone (what you call a phase). Each request can have a
    number of tasks. Each task can have a number of sub-tasks.

    This will let you have the granularity to plan from a high
    level initially down to a precise level for particular tasks.

    Let me know if you have any questions about this approach.
    For this reason, I'm marking this issue closed.

     
  • Anonymous

    Anonymous - 2003-10-16
    • assigned_to: nobody --> guy_davis
    • status: open --> closed
     
  • Anonymous

    Anonymous - 2003-10-16

    Logged In: YES
    user_id=22084

    You're running into a limit in the column type 'time'
    supported by MySQL. This is non-trivial to work around.
    I'd recommend that you use the groups within OPT.

    Project
    -> Milestones
    -> Request
    -> Task
    -> Sub-tasks ...

    In this case I would recommend that you split up this
    massive task into multiple requests grouped within a
    Milestone (what you call a phase). Each request can have a
    number of tasks. Each task can have a number of sub-tasks.

    This will let you have the granularity to plan from a high
    level initially down to a precise level for particular tasks.

    Let me know if you have any questions about this approach.
    For this reason, I'm marking this issue closed.

     
  • Anonymous

    Anonymous - 2003-10-16

    Logged In: YES
    user_id=22084

    You're running into a limit in the column type 'time'
    supported by MySQL. This is non-trivial to work around.
    I'd recommend that you use the groups within OPT.

    Project
    -> Milestones
    -> Request
    -> Task
    -> Sub-tasks ...

    In this case I would recommend that you split up this
    massive task into multiple requests grouped within a
    Milestone (what you call a phase). Each request can have a
    number of tasks. Each task can have a number of sub-tasks.

    This will let you have the granularity to plan from a high
    level initially down to a precise level for particular tasks.

    Let me know if you have any questions about this approach.
    For this reason, I'm marking this issue closed.

     
  • Martin Vernooij

    Martin Vernooij - 2003-10-20

    Logged In: YES
    user_id=608879

    I agree splitting a huge task into subtasks is a good idea.
    In fact, as a PM, I normally insist on maximum packages of
    around 300 hours. Anything more gives too much freedom to
    the task owner ;-)

    But.....
    If you are in a planning phase, there can be situations that
    you say: "well in phase 1 I'm going to determine what we're
    going to do in phase 2. We have a budget of 100 hours in
    phase 1 and a budget of 3000 hours in phase 2. Let's see
    what we can do in 3000 hours."

    This is e.g. in software development methods like DSDM a
    valid statement. In my case it's all about a research
    project, where in phase 1 we're going to determine what
    we're going to do in phase 2. The customer just expressed a
    timeline and financial budget. Those two happen to result in
    a small phase 1 and a huge phase 2.......

    I understand why this is not simple to modify in MySQL when
    you used the 'time' type. I would like to suggest to switch
    a more generic approach by use the 'epoch' time, but I have
    to assume this will be a major effort......?

    Martin

     

Log in to post a comment.