12-day limit on daily recurrence

[GRSmith]

In Project Pro 2007, why might I be limited to a value no greater than 12
when setting the recurrence pattern of a daily recurring task? Is there a
workaround?

 

[Mike Glen]

Hi GRSmith ,

Welcome to this Microsoft Project newsgroup

Only the programmer can answer that one. I suppose you could try creating a
new calendar where only the occurrence dates are working days and assign
that calendar in the occurrence dialog and selecting working days.

FAQs, companion products and other useful Project information can be seen at
this web address: http://project.mvps.org/faqs.htm

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP
See http://tinyurl.com/2xbhc for my free Project Tutorials

 

[Steve House [MVP]]

Do you have all the service paks, etc installed? When I try it there's no
problem setting as many as I want up to a max of 9999.

 

[GRSmith]

Regarding service paks, etc. Yes, I believe so. I am at 12.0.6211.1000 w/
SP1 MSO 12.0.6320.5000. And, there are no "disabled items". When you say
you can set as many as you want, are you referring only to entering the value
into the textbox? I too can enter any value. The problem is when you "OK"
the dialog. Then an error pops up saying "The period value is not valid.",
"The period for the recurrence must be between 1 and 12."

 

[Steve House [MVP]]

Try this ...

Insert Recurrring Task, select the Daily recurrence radio button, leave
"Every ... 1" to default, selecting "workday" radio button to avoid conflict
with default calendar, leave "Starting" field at default, select "End After
.... occurences" radio button and enter a number in the field. Click "Ok"
What results do you get?

 

[GRSmith]

I get the expected result - for example: three occurrences. Or, anticipating
your point, I get as many occurrences as I want - including any arbitrary
number of occurrences greater than 12.

However, that does not address the problem. The point of specifying the
frequency of recurrence is to space-out recurrence, thus enforcing some
desired "rest" interval. Specifying only the number of repetitions produces
a schedule in which the events are packed as closely together as the work
calendar allows, with no rest interval other than that allowed by the work
calendar.

For a single task, enforcing a specific rest interval might be possible by
playing with the work calendar. I think this is what Mike Glen was getting
at. However, I don't think this will work of me, at least not with any ease.

To be fair, this is not a project per se. It is much more on the order of
an ongoing maintenance schedule. So, one could argue that MS Project was not
designed to address this need.

It would work fine if the recurrence interval was weekly, on a specific day
of the week. However, in this case the desired interval is 18 days -
regardless of what day of the week that falls. Resources in this case are
unlimited. 24x7x365

Interestingly, I can specify a recurrence interval of 12 and then slide the
events around manually, on the Gantt chart, to give the desired 18 day
recurrence. But, any future change one might wish to make in the recurrence
dialog will wipe out all those manual moves and once again re-enforce the
12-day cap on recurrence interval.

I know I should not editorialize, but this a very odd limitation. I am
quite thankful that Outlook and the Windows Task Schedule (to name a couple)
do not behave this way. In those applications an 18-day recurrence interval
is understood to be exactly what that implies.

 

[Steve House [MVP]]

There are two parts to the problem. First of all, tasks can't be scheduled
for non-working days because by definition there will be no one there to do
them - that's what a non-working day in the calendar means, the workplace is
closed, dark, and cold with only the mice available to do any work (at least
as far as the project's resources are concerned - the business may be up and
running but no project related resource with the necessary skills will set
foot in the workplace those days). Thus it would be pointless for Project
to schedule the task onto a non-working day since it can't happen then
anyway. If there actually WILL be someone there to do the task, then the
first step is to create a new working time calendar that conveys that
information to Project, then specify that calendar to be the task calendar
when you enter the recurring task. If Sat and Sun should be considered
workdays for this task, create a copy of your Project calendar, perhaps
called "Everyday," and make Sat and Sun workdays with the same hours as the
rest of the week.

Let's be clear here - are you trying to schedule 18 occurrences of, say, a 1
hour task occurring on each successive day for a total of 18 days or are you
trying to create a sequence such that a tasks occurs once every 18 days for
some as yet undefined length of time out into the future? When you said you
wanted a daily recurrence, I understood that to mean the task should occur
once per day, each successive day, for some XX number of occurrences and you
couldn't get it to accept an XX entry greater than 12. Now it sounds like
you want it to be once per every XX days and you can't get it to accept an
XX entry greater than 12 (which I can't get it to do either).

Does it really HAVE to be every 18 days? Or could once a month, once every
2 or 3 weeks, or some other more conventional time interval suffice?

 

[GRSmith]

In retrospect, Mike Glen’s response most directly addresses the question,
even if it does deflect it to the development team. The original question
should have asked, “is this behavior fully intentional or is it a bug� And,
“if it’s a bug, is there a workaround�

From both your responses I would conclude it is a bug. None of us have
identified a logical reason to limit the daily recurrence values to 12.

The kind of workaround I had in mind was programmatic – like a macro or a
VBA solution.

It looks like connect.microsoft.com once offered a way of reporting bugs.
But, the “Connection†to MSO Project 2007 is not there when I list the
“Connection Directoryâ€. Is the development team no longer active?

Is there another way to report this?

 

[Mike Glen MVP]

Hi GRSmith,

I don't see how you reached that conclusion. To my mind a bug is a fault
that causes unwanted results. In this case, the programmer chose to allow
only 12 days for this selection. There's no bug to remove or repair. As you
beg to differ from this 12 days limitation, you will have to persuade
Microsoft that it is worth their while in progamming time to extend the
facility to allow more days. How many days would you program it for? Let
Microsoft know via the feedback selection here:
http://office.microsoft.com/en-gb/project/default.aspx?ofcresset=1

Mike Glen
Project MVP
See http://tinyurl.com/2xbhc for my free Project Tutorials

 

[GRSmith]

As a developer myself, I can't understand why one would assume this to be a
conscious choice on the part of the development team. Again, what logical
reason would there be for imposing this limitation? If you consider the
discovery of a bug to be insulting in some way, I can tell you it is actually
more insulting to assume the team did this intentionally. I know that is
certainly the way I would feel.

This is much more like something I might inadvertently do in borrowing, or
sharing, a snippet of bounds checking code for more than one purpose. For
example: bounding the input between 1 and 12 might at least seem sensible
applied to monthly recurrence (12 months in a year). However, it makes no
sense applied to days – which is exactly what I think may have
unintentionally happened.

If one really saw some need for bounding days one might set bounds of 1-7 (a
week), or 1-31 (longest month). Twelve just makes no sense. If you can
offer some logic, please do. I will relent. I am not trying to embarrass
anyone here. Defending the behavior of this dialog box – without any
supporting logic – is what seems much more embarrassing.

I certainly can’t speak to Microsoft’s cost for a hotfix. But, strictly on
the code level, this should be a very simple and very easy “fixâ€.

 

[Mike Glen]

No, GRSmith, I can't offer any logic to the programmer's decision, any more
than I can with what you call yourself Neither can I offer any logic to
many of the other limitations formally declared to what Project can or can't
do. It's just their decision and their design and I guess there was
probably little thought given to stopping at 12, they probably thought it
was enough!. It's nothing to do with being insulting or not ( I do not work
for Microsoft ), I just dispute that a lack of logic is a bug!.

Happy New Year,

Mike Glen
Project MVP
See http://tinyurl.com/2xbhc for my free Project Tutorials

 

[Steve House [MVP]]

My 2 cents, for what it's worth, I wouldn't call it a bug either ... a bug
would be where you input that you wanted a 12 day interval on the spinner
and actually got a 37 day interval or the spinner went to 24 but gave an
error if you tried to exit the dialog box with it set at more than 12. I do
agree that it seems an illogical choice, even "99" as the upper limit for a
two-digit value makes more sense to me, but be that as it may, the system
appears to be working exactly as designed. Whether the design makes sense
is another issue entirely.

 

[GRSmith]

Fair enough Mike. We will just call it a bad choice of word and avoid
offending the sensibilities of any similarly-minded reader. My only point
was that it seems unlikely that it was a deliberate and well-reasoned choice
on the part of the team. What term we use to describe that, I don’t care.

I guess I never answered your other question: “How many days would you
program it for?†In answer, I would make it behave exactly like the other
two Microsoft applications I have mentioned.

The easiest example would be for you to schedule a recurring event in the
Outlook calendar. There, you will find that a “Recurrence pattern†of “Daily
Every X day(s)†means exactly what one would assume. Try 18, 36, 72 or 144.
They all work just as anyone might expected. (Well, almost anyone

Happy New Year to you too Friend,
Gary

P.S. I did not mean to claim peerage with Microsoft developers. I only
design MSSQL-based web applications for internal corporate use. That is a
decidedly different ballgame. But, code is code. And, because of my
experience I probably do revere other developers slightly less than you.
From my perspective we are not questioning divine design here, just simple
ordinary human factors.

 

[Mike Glen]

OK, Gary, and a Happy New Year to you too

Mike Glen
Project MVP
See http://tinyurl.com/2xbhc for my free Project Tutorials