Project disclaimers

Hal Macomber reports an idea from a PM discussion group in Warning: This is NOT an accurate representation of how the project will unfold (quoting Amy Schwab of True North pgs):

Here is an example of a forward looking statement disclaimer I recently ran across in a news release about a company's new product offering. Imagine the slight change required to include this for your project -- and how it would more appropriately communicate the uncertainties included in that project:
Certain statements made by the company in this release may constitute forward-looking statements. In light of the risks and uncertainties inherent in forward-looking statements, many of which are beyond our control, actual results may differ materially from those projected in the forward-looking statements. Forward-looking statements should not be regarded as a representation that anticipated events will occur or that expected objectives will be achieved. These forward-looking statements involve risks and uncertainties including, but not limited to, the following: our ability to successfully market a new product in the current economic environment; changes in the demand for, pricing of, or supply of our products; competitive considerations, including possible actions by competitors and an increase in competition for our products; general economic conditions, including changing interest rates, rates of inflation and the performance of the financial markets; and various other factors. We undertake no obligation to release publicly the results of any future revisions we may make to forward-looking statements to reflect events or circumstances after the date hereof or to reflect the occurrence of unanticipated events.

Not a bad idea to include with any projections. In a previous entry Macomber talks about doing "Back to the Future" activities. He didn't elaborate, but I wonder if this is the heart of the way I have learned to plan projects: Identify the project endpoint and successively work backwards to identify the activities that must be accomplished to reach the goal.

2 Comment(s)

Hal said:

While I didn't say it there, I frequently say, "Identify the project endpoint and successively work backwards to identify the activities that must be accomplished to reach the goal." However, think of this backwards look as a process rather than a (one-time) backwards pass. One of our big problems with our projects is we plan separately for performing. That misses the learning that only the performers get. And then we wonder why we didn't succeed!

vioxel said:

I'm curious. Why is my journal linked here?

Leave a comment


Previous entry: Powerpoint and gov't work

Next entry: Review of The Future of Knowledge

About this Entry

This entry was published on October 20, 2003 4:16 PM and has 2 comment(s).

Related Entries

Find recent content on the main index, explore the full tag cloud, or look in the archives to find all content.

Syndication Options

Email Subscription

Powered by MT-Notifier

Powered by Movable Type 4.21-en
Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn

Blogarama - The Blog Directory