changing timeline to account for different types of accounting months?

[L Kelly]

Question regarding MS Project Timeline:

My company recently changed to an accounting system where
each month ends on the 4th Sunday of each month as opposed
to the last friday of the month. As far as I know, MS
Project only deals with actual calendar months.

Example - schedule is baselined as normal (so Jan 31 is
the end of the calendar month in Project). January 2004
accounting-wise really ends on Jan 25, 2004. So the week
of Jan 26-30 is really in the accounting month of
February. So any work not completed by Jan 25 has to be
moved to start after Jan 31. This causes a week schedule
slip compared to the baseline which finishes Jan 31. We
have had to go back and readjust the baseline spread to
move this week of baseline into February to avoid charging
the program an unfair week's slip of the schedule for any
of those tasks. We now have to do this every month where
the 4th Sunday of the month is not the end of the month or
when it's the end of the quarter.

We were afraid this is the only way to fix this when
establishing the baseline but does anyone know a way to
change MS Project calendar to match an accounting calendar
(that's different from the real calendar) like this
without having to set the task dates in the next month?
Back to my example - I don't want the tasks for Jan 26-30
to have to be set in actual month of February when I
baseline because that doesn't help the project team manage
their schedule correctly. They will be doing the work the
week of Jan 26-30 and schedule dependencies need to be set
correctly based on the actual dates.

Any insight would be most helpful! THANKS!

 

[Rob Schneider]

First, Project is not really an accounting program. That being said, I'm
not sure why you can't you keep the dates in Project as is? Any work
scheduled for week of Jan 26 is indeed on those dates. You know it.
It's fact. It's just, by definition "February". Don't move the work
into February in Project even though it's going to be done on the part
of "February" you call January 26. I think you need to keep the
accounting aspects, and computations about accounting aspects of project
data, outside of Project. Leave Project aligned with the real calendar.
After all, on Friday January 23rd I wouldn't think that folks talk about
their planned work on Monday January 25th as "next month". They think of
it probably first as "after the weekend", or "next Monday", or "on the
25th". Project plans are for people. Keep it simple for them.

Am I missing something? Is there an absolute requirement to add this
complexity into Project?

Hope this is useful to you. Let us know.

rms

 

[John]

L Kelly,
This issue comes up from time to time on the newsgroup. Unfortunately,
no version of Project will easily handle company financial months in
lieu of calendar months. However there is a solution.

Our company uses a 4-4-5 financial calendar. That is, Jan and Feb are 4
week months followed by March at 5 weeks. The cycle repeats through the
year. Our company also had internal and contract requirements to use a
validated EV system. Basically Project was used as normal (i.e. calendar
months) to develop and track the program plans. Information for EV is
offloaded each month to MPM (Microframe) or SAP where it is tracked with
the company financial system. The method works fine but it is not
readily available to the users who must develop and track their
individual project plans.

Since I was the Project Manager for one of our programs, I wanted to be
able to utilize a method independent of the company developed offload
interface in order to allow our individual Cost Account Managers (CAMs)
to see the EV impact of their original plan and status data directly
from their desktop Project application. I developed a VBA macro that
took the normal Project data, converted it from calendar months to a
4-4-5 system and exported the data to Excel where EV and manpower
loading was presented on a spreadsheet. The macro was so successful that
other Project managers and company IT personnel wanted to understand how
it was done. Our CAMs loved it especially for the manpower planning
function.

So, it can be done. The heart of the macro is the algorithm that does
the conversion. If you would like more information and assistance, write
me direct.

John

 

[Guest]

We have to move any uncompleted work for that week into
February in MS Project so our EV model can pick up that
week's remaining work for ETCs.

I agree to keep it simple in MS Project but we have to
figure out a work around for the accounting issue. The
other posting answer was our "plan B" and we will most
likely go with that. Thanks for your input!

L Kelly

 

[Rob Schneider]

John's approach, unless I'm missing something, is to dump the data into
Excel for analysis ... and not move uncompleted work inside of Project
into psuedo-February dates. It's not really a matter of keeping it
simple in Project so much as to keep the work scheduled/planned on the
dates it actually scheduled/planned. I guess if there are no knock on
affects by changing dates, and taht everyone knows that the dates are
"wrong" ... well, then it would work. It's the movement of data in
Project for accounting purposes I'm having a conceptual problem with ...

Hope this is useful to you. Let us know.

rms

 

[John]

Rob,
Just for reference, the financial month analysis is accomplished in the
macro and simply presented as such in Excel. Earned value fields in
Project are not used. All other Project data, including dates, work,
assignments, baseline etc. are all handled in the "standard" way using a
normal calendar. The only difference is that monthly status input is
captured as of the financial end of month.

John