Project Mission Statements – Justifiable, Objective Focus

John Brunswick — Wed, 11 Nov 2009 07:01:17 +0000

It is not uncommon for project mission statements and organizational mission statements contain lofty, heartfelt missions that sound terrific – but fail to translate into meaningful guidance for a project or company. If you ever had a chance to use the Dilbert mission statement generator before it was decommissioned, you may have created mission statements like the following, which highlight how NOT to create a mission statement -

“We have committed to synergistically fashion high-quality products so that we may collaboratively provide access to inexpensive leadership skills in order to solve business problems”
“Our challenge is to assertively administrate timely resources and authoritatively integrate enterprise-wide products while promoting personal employee growth.”
“It is our job to continually foster world-class infrastructures as well as to quickly create principle-centered sources to meet our customer’s needs”

The above mission statements are ultimately empty and provide no guidance or control over the execution of tasks that will take place to fulfil them.

In his book Winning, Jack Welch emphasizes the need to take a pragmatic, no-nonsense approach to mission statement development if any real value is to be gained by it. Mr Welch states that “Too often, these exercises end with a set of generic platitudes that do nothing but leave employees directionless or cynical. Who doesn’t know of a mission statement that reads something like, “XYZ Company values quality and service,” or, “Such-and-Such Company is customer-driven.” … Give me a break—every decent company espouses these things!”

To make the most out of a project charter’s mission statement it must be meaningful enough to provide business justification, focus the project execution and provide a high level metric to objectify project results. If developed correctly, a mission statement will act as an excellent compass by which to deliver a successful project. This is done by clearly defining

WHAT the project is about – focus execution via this statement
WHY it is being undertaken – business justification
HOW it will be achieved – objective metrics for success

This might sound trivial, but it is amazing how often this fundamental criteria is not met. If this criteria cannot be clearly articulated by a project team, the project should not be undertaken.

Although the Project Management Institutes’s (PMI) Body of Knowledge can be idealistic, it does a good job of making sure that a project mission statement is clear in these respects and define it as follows – “Brief summary, approximately one or two sentences, that sums up the background, purposes and benefits of the project.” (from http://www.pmi.org/PDF/pp_besnerhobbs.pdf). In my abbreviated approach above, addressing the WHAT (goal), WHY (business justification) and HOW (metrics for success) will ensure that a foundation for project success is created based on a strong vision.

Large Project Success – Pragmatic Phasing

John Brunswick — Wed, 01 Jul 2009 16:43:17 +0000

I marvel at the complexity of various finely made time pieces. I cringe at the complexity of various projects. A timepiece is generally valued by the number of “complications” or moving parts that it has. Conversely, a project is punished by the number that it has. Unfortunately the possible surface area for project issues grows exponentially as the number of tasks within a project increases.

Working in technology consulting all of my professional life it might seem that it would be to my benefit to sell and manage a variety of large, complex projects to drive revenue. It can actually be detrimental and somewhat like a race car going too fast in the corners. If a project looses control and never crosses the finish line both the client and I have lost. I am not a management consultant, but clearly understand that is not a good approach to doing business.

The key to winning is to deliver the project in smaller, cleanly scoped and controlled phases.

Most importantly – the project must really be approached in a phased manner – it cannot just be lip service from the project team. At the end of the day a business sponsor will be expecting some business value to be produced from the project efforts and steering away from the phases approach in any regard blurs the lines around that sponsor’s expectations and can derail the project.

Consider these steps in order to help support and create a pragmatic, phased approach that I hope can assist you in delivering predictable benefit to your project sponsors.

Pragmatic Phases Project Approach

1. Projects only begin to provide value once they start to support or produce for the business that they are designed for:

a. Fight the urge to bundle all of the business value into a single, monolithic development effort. If that efforts stumbles or is halted, the business value is impacted

b. By phasing the project value can be provided to the business much earlier in the overall project life cycle

2. In almost every project it is possible to decompose and prioritize various business benefits that will be made available by the project completion

a. Review the list and sort it by the priority of each business benefit

b. Observe various dependencies and finalize the list c. Schedule your project into phases on the basis of the list

3. Treat each phase as a traditional project: a. When complete each phase should yield a working deliverable available for review, revision and release. b. Continuing to think pragmatically each release does not need to be made public, but should be treated as though it were final given its place in the overall project life cycle.

For more on project approach check out ***** link to nat part ******.

Hopefully the above tips help project teams avoid trying to “boil the ocean”. There are many good project teams that have fallen short of their potential by trying to address all requirements in a long running project and ultimately failing to deliver a working product. By approaching those same projects in a strictly phased manner they could have greatly increased their chances at getting their projects out of the door.

I look forward to additional thoughts on pragmatic approaches to project management for larger projects. Please feel free to drop me a line or comment.

I marvel at the complexity of various finely made timepieces. I cringe at the complexity of various projects. A timepiece is generally valued by the number of “complications” or moving parts that it has. Conversely, a project is punished by the number that it has. Unfortunately the possible surface area for project issues grows exponentially as the number of tasks within a project increases.