Project capabilities

[JackD]

OK, you asked for it.

The problem of a non-standard company calendar is one I'm quite familiar
with.
I have found work-arounds for it - the best work around is actually using a
calculated field rather than VBA and placing the results in a text fields
which are displayed on the task bars.
However, try as you might, you can NOT change the timescale to reflect the
non-standard calendar.
You can work around it. But a workaround is not always a completely
satisfactory result. It may be close, but there is always room for
improvement. In addition, a workaround may take a large amount of
administration time (to design, deploy, train people on and maintain). In
many cases this is an unacceptable strain on limited resources. You are
talking about numbers like $50, $100, $1000. Do you really think that is
sufficient for an organization of even a couple hundred people? What about
an organization of 10's of thousands?

In some cases doing the "right" fix is something only microsoft can do. I'm
familiar with the case of the workweek numbering in Outlook, where we
requested (and I believe paid) Microsoft to modify outlook to display the
"correct" workweeks in the calendar.

For most of my life I've worked in design environments where "anything is
possible - given enough time and money" but to be responsible (and good) the
second part of that slogan has to be carefully considered. So, strictly
speaking, you are right, the answer is never truly "no". But there are cases
where the effort to achieve the result, and the quality of the result itself
are so unbalanced that the "practical" answer is truly "no".

I'm always happy to suggest some way in which things can be achieved with
VBA and you know that I go out of my way to help people learn and use it to
do things which are otherwise impossible, but really, sometimes it is unwise
to step out of the box.

 

[John]

Users,
Recently a user posted a question concerning the ability of Project to
do a certain thing. In this case handle a calendar other than the
standard Gregorian calendar. This particular user's company uses a
common 4-4-5 financial calendar. One of the MVPs replied that Project
does not have this feature. Well, yes and no. I took exception and said
that it is possible. Here is my thinking.

Project is a very affordable application with tremendous capabillity.
It's features are really quite amazing but like any application there
are always limitations. What is unique about Project and all other MS
applications is that Microsoft bundles a very nifty tool with every user
license. That tool is VBA. It comes at no extra cost and provides a
method for working around any limitation, at least from my experience.
It is because of VBA that I took exception to the response that Project
could not handle "non-standard" calendars. As a matter of fact I take
exception to most responses that say, "it can't be done".

"But using VBA does not quality as a built-in feature of Project itself
and developing code costs extra money". Yes and no, and yes and no.
Although the developed code is not "built-in", the fact that VBA is
readily available allows expansion of Project's basic capabilities.
Depending on the user training, costs to learn VBA may be required but
free training materials are readily available (the MVP website) and the
built-in VBA Help file is zero cost approach. If the user is not
inclined to learn VBA or does not have the time, then yes, an outside
resource will be necessary. The cost of that resource need not cost a
"lot of money". In a business world what is a "lot of money"?
$50, a few Hundred, a $1000? It depends on the need and the value added.

I invite comments and other viewpoints. I apologize if I sound like I'm
on a soapbox. I simply believe we are limited only by our ability to
solve problems with innovative thinking, sometimes outside the box.

John
Project MVP

 

[John]

Users,
Recently a user posted a question concerning the ability of Project to
do a certain thing. In this case handle a calendar other than the
standard Gregorian calendar. This particular user's company uses a
common 4-4-5 financial calendar. One of the MVPs replied that Project
does not have this feature. Well, yes and no. I took exception and said
that it is possible. Here is my thinking.

Project is a very affordable application with tremendous capabillity.
It's features are really quite amazing but like any application there
are always limitations. What is unique about Project and all other MS
applications is that Microsoft bundles a very nifty tool with every user
license. That tool is VBA. It comes at no extra cost and provides a
method for working around any limitation, at least from my experience.
It is because of VBA that I took exception to the response that Project
could not handle "non-standard" calendars. As a matter of fact I take
exception to most responses that say, "it can't be done".

"But using VBA does not quality as a built-in feature of Project itself
and developing code costs extra money". Yes and no, and yes and no.
Although the developed code is not "built-in", the fact that VBA is
readily available allows expansion of Project's basic capabilities.
Depending on the user training, costs to learn VBA may be required but
free training materials are readily available (the MVP website) and the
built-in VBA Help file is zero cost approach. If the user is not
inclined to learn VBA or does not have the time, then yes, an outside
resource will be necessary. The cost of that resource need not cost a
"lot of money". In a business world what is a "lot of money"?
$50, a few Hundred, a $1000? It depends on the need and the value added.

I invite comments and other viewpoints. I apologize if I sound like I'm
on a soapbox. I simply believe we are limited only by our ability to
solve problems with innovative thinking, sometimes outside the box.

John
Project MVP

Followup:
I forgot to add this footnote. My viewpoint should not be taken as any
disrespect or degradation of newsgroup responses posts by my fellow MVPs
or others. I highly respect them all. We are all volunteers, not
employed by Microsoft, and give freely of our time, expertise and
experience for the benefit of the user community.

John

 

[John]

OK, you asked for it.

The problem of a non-standard company calendar is one I'm quite familiar
with.
I have found work-arounds for it - the best work around is actually using a
calculated field rather than VBA and placing the results in a text fields
which are displayed on the task bars.
However, try as you might, you can NOT change the timescale to reflect the
non-standard calendar.
You can work around it. But a workaround is not always a completely
satisfactory result. It may be close, but there is always room for
improvement. In addition, a workaround may take a large amount of
administration time (to design, deploy, train people on and maintain). In
many cases this is an unacceptable strain on limited resources. You are
talking about numbers like $50, $100, $1000. Do you really think that is
sufficient for an organization of even a couple hundred people? What about
an organization of 10's of thousands?

In some cases doing the "right" fix is something only microsoft can do. I'm
familiar with the case of the workweek numbering in Outlook, where we
requested (and I believe paid) Microsoft to modify outlook to display the
"correct" workweeks in the calendar.

For most of my life I've worked in design environments where "anything is
possible - given enough time and money" but to be responsible (and good) the
second part of that slogan has to be carefully considered. So, strictly
speaking, you are right, the answer is never truly "no". But there are cases
where the effort to achieve the result, and the quality of the result itself
are so unbalanced that the "practical" answer is truly "no".

I'm always happy to suggest some way in which things can be achieved with
VBA and you know that I go out of my way to help people learn and use it to
do things which are otherwise impossible, but really, sometimes it is unwise
to step out of the box.

Jack,
I respect your opinion. Thanks for weighing in.

Actually with regard to the accounting month issue, the method I use
does not try to do it all in Project. Like you said, the Project
timescale can NOT be changed to accommodate a non-standard calendar.
However, the data CAN be converted and exported to an application where
it can be readily integrated with other company financial systems.

With regard to cost. If a macro or add-in is developed to provide needed
functionality, why can't it be made available to all users in a company,
whether there are 10 employees or 10's of thousands? It is no different
than existing add-ins and utilities.

And I do agree, some of the requests for added "functionality" are NOT
worth the effort to write up in code. I think we have both seen that on
this newsgroup. However, I think it is always wise to think outside of
the box, but it isn't always worth the effort to implement the resulting
solution.

John

 

[davegb]

I've seen a few very hairy implementations of VBA to get project to do
things it isn't designed to do. And talked with the users. One compamy
had hired a consultant/VBA programmer to take cost data directly from
Project and export it into their accounting system. It never ran
consistently, and they were constantly calling the consultant out to
fix it yet again. In the consulting business, we call such a product a
"Trojan Horse". It gets you inside the organization and assures you of
continuing business until the client wises up. Common practice among
unethical consultants.
So while anything is theoretically possible, complex solutions usually
result in complex problems, which may not be economically feasible to
fix. I'm not convinced that ANY problem you might have can be truly
fixed with a programmed solution. But I don't consider it a fix if the
problems it creates are worse than the ones it supposedly solved.

 

[Steve House [MVP]]

My opinion is that developing anything beyond the most rudimentary of macros
in VBA requires all the skills and experience of a full-time professional
programmer and is not a viable solution for the typical user (of ANY MS
application, not just Project), no matter how expert they may be in the
application itself. One might be a competant project manager or one might
be a competant programmer but it's going to be a very rare bird that can or
should aspire to be both at once. If the average project manager using MS
Project can't do it without either taking the weeks or months out of his
"day job" that it will require to become an expert programmer or hiring a
professional developer who is a skilled and experienced expert in VBA at a
hundred bucks plus or so an hour for the time it will take to fully develop
including error handling, test, debug, and deploy, for all practical
purposes it can't be done.

Of course, as long as it doesn't violate the laws of nature and mathematics,
one can do anything one can afford. But does it make sense to pay someone 1
or 5 or 10 kilobucks to write the necessary VB code to incorporate 4,4,5
financial calendars into Project sufficiently seamlessly that a non-IT savy,
non-developer, assistant project manager can use them as easily as they
might use the standard calendar functions? Is THAT report, which really
exists only to cater to the convenience of the bean-counters, so important
so as to justify that level of cost and aggravation, just to get a "nice to
have" report that has no real utility in performing the basic Project
function of getting the right person to the right place at the right date
and time to get the project done on time and under budget?

"The right tool for the right job" needs to be a basic mantra. Project can
tell the accountants that $xxxx in labour cost will be accrued between 01
March and 15 March and/or it will cost $10000 to paint the walls. Let the
accounting system figure out what financial period it should be reported in
and what cost centre gets the bill - the PM has enough to worry about in
getting the right crew on site with the right tools to do the work required.
Just let him pass along how much money he spent or will spend on what dates
to the people whose job it is to track the money, something Project can tell
him right as it comes from the box, and wash his hands of it from then on
in.

Just one aging hippy's 2 cents...

 

[JackD]

Put down the keyboard and come out with your hands up. We have you
surrounded!

-Jack

 

[davegb]

ROFLMAO!
I agree with you in principle, Steve. But my real world experience
shows me that many organizations are run to accomodate the bean
counters. Usually at the expense of overall product quality and
customer satisfaction. In fact, today's Dilbert is about this sort of
thing.
http://www.dilbert.com/

 

[Steve House [MVP]]

I agree that the bean counters are often in charge and more's the pity. Any
business organization is a human structure created and maintained to serve
human needs. Certainly all managers must keep their eye on the bottom line
and a company that consistently runs in the red won't be around very long.
But there's a problem when those who are charged with monitoring the bottom
line become the force the drives the organization - procedure then becomes
more imprtant than results. All of the financial and accounting management
in the world is only a means to an end and only has validity (IMHO) when it
serves that end. When it becomes the end itself, the business loses sight
of its human values and we have a problem.

 

[John]

My opinion is that developing anything beyond the most rudimentary of macros
in VBA requires all the skills and experience of a full-time professional
programmer and is not a viable solution for the typical user (of ANY MS
application, not just Project), no matter how expert they may be in the
application itself. One might be a competant project manager or one might
be a competant programmer but it's going to be a very rare bird that can or
should aspire to be both at once. If the average project manager using MS
Project can't do it without either taking the weeks or months out of his
"day job" that it will require to become an expert programmer or hiring a
professional developer who is a skilled and experienced expert in VBA at a
hundred bucks plus or so an hour for the time it will take to fully develop
including error handling, test, debug, and deploy, for all practical
purposes it can't be done.

Of course, as long as it doesn't violate the laws of nature and mathematics,
one can do anything one can afford. But does it make sense to pay someone 1
or 5 or 10 kilobucks to write the necessary VB code to incorporate 4,4,5
financial calendars into Project sufficiently seamlessly that a non-IT savy,
non-developer, assistant project manager can use them as easily as they
might use the standard calendar functions? Is THAT report, which really
exists only to cater to the convenience of the bean-counters, so important
so as to justify that level of cost and aggravation, just to get a "nice to
have" report that has no real utility in performing the basic Project
function of getting the right person to the right place at the right date
and time to get the project done on time and under budget?

"The right tool for the right job" needs to be a basic mantra. Project can
tell the accountants that $xxxx in labour cost will be accrued between 01
March and 15 March and/or it will cost $10000 to paint the walls. Let the
accounting system figure out what financial period it should be reported in
and what cost centre gets the bill - the PM has enough to worry about in
getting the right crew on site with the right tools to do the work required.
Just let him pass along how much money he spent or will spend on what dates
to the people whose job it is to track the money, something Project can tell
him right as it comes from the box, and wash his hands of it from then on
in.

Just one aging hippy's 2 cents...

Steve,
Wow! I'd say we got a whole lot more than 2 cents from you on this one.
You and I obviously have very different viewpoints on the viability of
what is possible and practical at reasonable cost. And you are certainly
entitled to your opinion. I assume you agree that I am entitled to mine.

With regard to the example of a non-standard calendar, there should be
no disagreement that Project cannot accommodate that need. However I
don't understand how you can say that "that report" exists only to cater
to the bean counters. If a plan is developed and tracked in Project and
the users, be they CAMs, (I support the idea of having performers
develop and track THEIR own plans), or a designated schedule manager,
(PM or otherwise), how does the periodic status update information get
from Project to the company's financial system that operates on a
non-standard calendar? Indeed there are many ways. I'm just suggesting
that a VBA routine is one of the ways. And although a professional
software developer could develop the code for big bucks, someone who is
reasonably competent with VBA can write a usable and reliable routine to
perform the translation.

My guess is that I've hit a cord and this discussion can probably go on
for days. In the end we will likely agree to disagree. Each of us has
our own approach.

John

 

[John]

I've seen a few very hairy implementations of VBA to get project to do
things it isn't designed to do. And talked with the users. One compamy
had hired a consultant/VBA programmer to take cost data directly from
Project and export it into their accounting system. It never ran
consistently, and they were constantly calling the consultant out to
fix it yet again. In the consulting business, we call such a product a
"Trojan Horse". It gets you inside the organization and assures you of
continuing business until the client wises up. Common practice among
unethical consultants.
So while anything is theoretically possible, complex solutions usually
result in complex problems, which may not be economically feasible to
fix. I'm not convinced that ANY problem you might have can be truly
fixed with a programmed solution. But I don't consider it a fix if the
problems it creates are worse than the ones it supposedly solved.

Dave,
I agree that unscrupulous or incompetent consultants can wreak havoc on
a company. The same same can be said of some people within the company
organization itself. Such is life but I don't advocate or support this
type of behavior.

What I do find is that people have a tendency to limit themselves in
what they do and think. I dislike the idea of answering a question with
a flat, "no, it can't be done". No alternatives? No explanation? How
does that help the person? I favor the approach that often it can be
done and not always with the caveat that, "yeah, most anything can be
done with enough time and money". It is not possible to do everything -
we live in a physical world with real limitations. However, thinking
solely inside the box and not looking at other possibilities is a
limitation I refuse to accept.

When I first started working with Project I was told by seasoned
professionals that Project could not handle our company's non-standard
calendar. Indeed years earlier our IT department developed a translation
program, (not VBA), to handle the task. However, me being an employee to
dumb to know better, decided to look into the possibilities for doing
the translation in VBA. Not that it was needed by our business/financial
people, they already had a working translator, but rather to help CAMs
who were responsible for their own Project files to more easily see how
their plans would "mesh" within our formal EV system before the plans
were formally uploaded. Not knowing better I developed a VBA translator.
When the seasoned IT and Project professionals saw what I had they said,
"how you do dat"?

My little story is not meant to "toot my own horn". It is simply to
provide a first hand example of what can be done with some drive, desire
and a little bit of knowledge. And that's all I'm suggesting when I
answer a post and say, "yes, it can be done".

John

 

[John]

Put down the keyboard and come out with your hands up. We have you
surrounded!

-Jack

Jack,
Y <- me with my hands up. Please don't shoot.

Hohn

 

[Steve House [MVP]]

How does the financial information get from Project which uses one calendar
to the accounting system which uses a different one? By transferring raw
data rather than summary or otherwise manipulated data. $100 spent on 15
March is $100 spent on 15 March, regardless of whether your system chooses
to group that into the month of March, the 1st quarter of 2005, the third
period of 2005, or the first period of fiscal 2006 (fiscal year beginning
March 01).
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[John]

How does the financial information get from Project which uses one calendar
to the accounting system which uses a different one? By transferring raw
data rather than summary or otherwise manipulated data. $100 spent on 15
March is $100 spent on 15 March, regardless of whether your system chooses
to group that into the month of March, the 1st quarter of 2005, the third
period of 2005, or the first period of fiscal 2006 (fiscal year beginning
March 01).

Steve,
By "raw data" I assume you are referring to a query on the Project
database itself. Yes, that is certainly one way to do it and perhaps the
preferred way ... but it is NOT the only way ... it can also be
extracted using VBA. I'm not sure what you mean by summary or otherwise
manipulated data.

Companies that use a non-standard financial calendar and also use
Project as their planning, scheduling and tracking application need the
Project data converted. For example, the business people get actuals
from the timekeeping system. In order to do earned value metrics they
also need to know how many hours (BCWS) of each Project task is
allocated to each accounting period. If the accounting period is monthly
(a typical scenario), they need to know how many hours of Task "A" are
allocated to financial January, February, etc. It is pretty much
irrelevant that "$100 was spent on 15 March". Likewise, the functional
managers and/or human resource people need to have a manpower projection
based on financial months. Again a translation of the basic Project data
is needed. Maybe the Program Manager wants a special report showing
schedule performance (over and above EV metrics) by financial month.
There are any number of "needs" for standard calendar Project data to be
converted to company financial data. That's why we see posts, (albeit
occasional), asking about it on the newsgroup.

John
Project MVP

 

[Steve House [MVP]]

I'm not saying they have to adopt their accounting methods to Project's way
of totaling and allocating costs. Use any metrhod they want but I'm saying
they should use the right tool to prepare the reoprts. Use Project to track
expenditures as they occur and to measure performance against the project's
objectives. Take that same day-by-day base data from Project and send it to
the accounting system to perform the financial analysis. Why expect
Project to be the tool used to total and report the Project's financial
performance - that's not what it's for. Why use Project to attribute that
the costs of work performed on 31 Jan is part of January's totals or the
first period's total or the 2nd period's total or the 4th week's total? Why
should Project care if monies spent on for work on January second be
included with total costs for 2004 or 2005 or if the week 1 of 2005 began on
27 Dec 04, 03 Jan 05, or 10 Jan 05? MSP is simply not financial management
software and those sorts of tasks are what you buy accounting software to
do - tell the accounting system our labour costs were $28 on Dec 29th, $5000
on Jan 3rd, and $15 on Jan 10th and let the accounting system decide what
reporting periods to accumulate which date's expenditures into and report it
back to the PM if monitoring performance by period is part of his
responsibility.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[John]

I'm not saying they have to adopt their accounting methods to Project's way
of totaling and allocating costs. Use any metrhod they want but I'm saying
they should use the right tool to prepare the reoprts. Use Project to track
expenditures as they occur and to measure performance against the project's
objectives. Take that same day-by-day base data from Project and send it to
the accounting system to perform the financial analysis. Why expect
Project to be the tool used to total and report the Project's financial
performance - that's not what it's for. Why use Project to attribute that
the costs of work performed on 31 Jan is part of January's totals or the
first period's total or the 2nd period's total or the 4th week's total? Why
should Project care if monies spent on for work on January second be
included with total costs for 2004 or 2005 or if the week 1 of 2005 began on
27 Dec 04, 03 Jan 05, or 10 Jan 05? MSP is simply not financial management
software and those sorts of tasks are what you buy accounting software to
do - tell the accounting system our labour costs were $28 on Dec 29th, $5000
on Jan 3rd, and $15 on Jan 10th and let the accounting system decide what
reporting periods to accumulate which date's expenditures into and report it
back to the PM if monitoring performance by period is part of his
responsibility.

Steve,
I don't think anything in my response said that Project should do the
accounting or that Project should care what is done with its data. But I
think we can both agree that for a company that uses a non-standard
calendar, Project's data needs to be translated. I also said that there
are multiple ways to translate that data and one of them can be through
a VBA procedure. Is it the best method? Perhaps not, but depending on
what the company needs, VBA may be a viable solution.

I think I mentioned this in my last response, but let me reiterate.
Beyond a company's accounting needs, users, business people, managers,
etc. may want customized reports, for whatever reason, that simply are
not available from commercial software. In this regard, VBA is likely a
good candidate for preparing these reports. I could just as easily
suggest that "C" or some other method of extracting information can be
used but the only method that is provided as a basic component of
Project is VBA.

The central theme of my original post was to highlight what I believe is
an underutilized component of Project, namely VBA, that can expand
Project's functionality. I used the inability of Project to deal with
non-standard calendars as an example. Whether users feel adequately
trained or comfortable using VBA is another matter. Perhaps I think too
far out of the box ... but then again.

Anyway, that's my conviction. Enough said.

John

 

[Mike Glen]

Hi John,

Now the dust has settled, I'll give my viewpoint I have always perceived
my task as helping people with problems they have with using the Microsoft
Project software that they have purchased. I therefore primarily respond
with respect to what Project can do out of the box. If is not a built-in
feature, or one that can be solved using in-built features (like
customization), I will invariably say it can't be done. If I believe the
procedure is sufficiently simple to lend itself to being recorded as a
macro, then I'll say so, and I sometimes add to that the possibility of
writing vba code if, in my limited experience, I deem that a reasonable
possibility. All my postings refer to our Project MVP pages which include a
large amount of companion products that anyone can purchase to solve their
problems and also to vba references which they are free to call upon. I
thus feel it unnecessary to raise people's hopes that they could possibly
get some free code. If you, or anyone else sees vba possibilities that I
have missed, I would expect a follow to up my posting with an offer. I have
no problem with that and take no exception to it


Mike Glen
Project MVP

 

[John]

Hi John,

Now the dust has settled, I'll give my viewpoint I have always perceived
my task as helping people with problems they have with using the Microsoft
Project software that they have purchased. I therefore primarily respond
with respect to what Project can do out of the box. If is not a built-in
feature, or one that can be solved using in-built features (like
customization), I will invariably say it can't be done. If I believe the
procedure is sufficiently simple to lend itself to being recorded as a
macro, then I'll say so, and I sometimes add to that the possibility of
writing vba code if, in my limited experience, I deem that a reasonable
possibility. All my postings refer to our Project MVP pages which include a
large amount of companion products that anyone can purchase to solve their
problems and also to vba references which they are free to call upon. I
thus feel it unnecessary to raise people's hopes that they could possibly
get some free code. If you, or anyone else sees vba possibilities that I
have missed, I would expect a follow to up my posting with an offer. I have
no problem with that and take no exception to it


Mike Glen
Project MVP

Mike,
Has the dust settled? I thought it had, but it looks like it just got
kicked up again.

I'll reiterate a bit because it addresses some of the issues you raise.
From my point of view, VBA IS a built-in feature of Project right out of
the box. Whether the user has the need, desire, or training necessary to
use VBA is another matter. When it comes to finding solutions that
aren't obvious or may seem impossible, I am an optimist. What may seem
like a very strange question [in a post] to us may be very important in
the eyes of the user. If I believe or know that the question can be
answered directly or indirectly, I respond accordingly, even if the
solution is "unconventional". When I suggest a VBA solution I feel I am
simply exposing the possibilities that are often overlooked or
dismissed. My suggestions can be ignored or pursued, it is entirely up
to the user.

I fully appreciate that many users are intimidated by VBA and using it
perhaps does require a certain type of "structured personality". If I
detect a desire or a direct indication that the user wants to learn VBA
I always refer them to both the MVP website link for VBA training and to
Jack's very excellent website of VBA examples. As far as raising
people's hopes of getting free code, we (myself, Jack, Jan, Rod and
others) often publish the necessary code directly in our responses. I
find the problem is more an issue of making users understand that some
VBA solutions require code that takes some time to develop and write.
Users should not automatically expect this code to be freeware. When I
post a response that suggests a unique VBA solution I often add the
offer that if they would like more information to contact me direct. If
they do chose to contact me, I provide more details including whether I
am willing to write the code for free or whether there would be a
charge. I don't think that is any different than listing a personal or
reference website in my responses. From time to time I also receive
queries from users who have read a past post and want to know more. As
an MVP I feel a responsibility to provide whatever help I can.

Each of the MVPs have their area of expertise and interest. I feel we
have great diversity and I don't know of any other newsgroup where the
response rate to posts approaches 100%. We don't always agree on the
answer or method mainly because there is often more than one way to get
there. When we disagree I think our collective discussions are good. It
gives the user a selection of viewpoints. The biggest reward is seeing
that "thank you" response and knowing that we helped someone solve a
problem.

I'll get out my broom and dustpan again.
John

 

[JackD]

Comments in-line

-Jack

Mike,
Has the dust settled? I thought it had, but it looks like it just got
kicked up again.

I'll reiterate a bit because it addresses some of the issues you raise.
From my point of view, VBA IS a built-in feature of Project right out of
the box. Whether the user has the need, desire, or training necessary to
use VBA is another matter.

Quite an important matter however. Even though in my opinion it is a fairly
simple feature. It should probably be classified as an advanced feature. To
write effective VBA code requires a fairly solid understanding of how
project behaves. It also requires some programming skills. Many people do
not have these skills.

When it comes to finding solutions that
aren't obvious or may seem impossible, I am an optimist. What may seem
like a very strange question [in a post] to us may be very important in
the eyes of the user. If I believe or know that the question can be
answered directly or indirectly, I respond accordingly, even if the
solution is "unconventional". When I suggest a VBA solution I feel I am
simply exposing the possibilities that are often overlooked or
dismissed. My suggestions can be ignored or pursued, it is entirely up
to the user.

No one has any problem with you saying that - at least as far as I have
seen.

-Jack

 

[John]

Comments in-line

-Jack

Mike,
Has the dust settled? I thought it had, but it looks like it just got
kicked up again.

I'll reiterate a bit because it addresses some of the issues you raise.
From my point of view, VBA IS a built-in feature of Project right out of
the box. Whether the user has the need, desire, or training necessary to
use VBA is another matter.

Quite an important matter however. Even though in my opinion it is a fairly
simple feature. It should probably be classified as an advanced feature. To
write effective VBA code requires a fairly solid understanding of how
project behaves. It also requires some programming skills. Many people do
not have these skills.

When it comes to finding solutions that
aren't obvious or may seem impossible, I am an optimist. What may seem
like a very strange question [in a post] to us may be very important in
the eyes of the user. If I believe or know that the question can be
answered directly or indirectly, I respond accordingly, even if the
solution is "unconventional". When I suggest a VBA solution I feel I am
simply exposing the possibilities that are often overlooked or
dismissed. My suggestions can be ignored or pursued, it is entirely up
to the user.

No one has any problem with you saying that - at least as far as I have
seen.

-Jack

Jack,
Thanks for checking in. I wondered if any of the MVPs who work with VBA
had an opinion. I was beginning to think I was the guy way out in left
field. (For that matter, I probably still am).

I agree about VBA being an advanced feature. I should have offered that
up earlier in the discussion. And yes, VBA code won't be much good if
the user doesn't good understanding of Project itself.

John