Learning Solutions for Increased Project Performance

Welcome to Our November Issue

In this month’s issue, we’ll be focusing on Initiating Projects and the activities related to getting your project off on the right path from the beginning.

By the way, if you haven’t already, be sure to sign up for our the free November 16th webinar, Project Management Discipline Keys to Clinical Team Motivation, presented by Dee Suberla, MBA, PMP of Baxter Healthcare.

Included in this issue:

• Project Charter: Well Begun is Half Done
• Project Management Q&A
• Kick-Off Your Project Right!
• Project Kick-Off Meeting Agenda Template
• The Importance of Project Requirements
• Get a Solid Start with a Good SOW
• Taking On the Facilitator Role
• Reading Room: Creativity & Innovation
• Identify Your Project Stakeholders - and Only Then Plan Communications

Next Month’s Topic: Risk Management

If you’re not a regular subscriber, sign up for pmPractitioner today and be notified when next month’s issue is available!

pmPractitioner is published as a service to the project management community. Each issue provides practical project management solutions and tips adapted from a variety of business publications and resources.

Project Charter: Well Begun is Half Done

What’s so important about the project charter? Quite a few things, actually. The charter defines the project’s intent and the first level of project scope. It also authorizes the project, making it “official.” Most importantly, though, it answers the “why” of the project. Why are we doing this? Why is it important? Why should people care about it?

From a business perspective, the charter provides critical information for qualifying opportunities and results to ensure optimal investment of resources based on customer requirements, business needs and direction.

A solid, comprehensive charter should contain the following:

• Authorization statement for the project
• Summary description of the project/product
• Problem/need statement
• Scope boundaries
• Project objectives and success criteria
• Key deliverables
• List of key stakeholders
• Standards and references
• Set of preliminary requirements
• Summary of costs
• Expected benefits
• Organizational impact
• Constraints & assumptions
• Risk summary

From Action for Results, Inc.

Kick-Off Your Project Right!

Many projects get started without a formal project kick-off – it happens often. Afterwards, though, you may hear people say, “Did that project get started already?” And the reply is, “Yeah, about a month ago.” This is not a good thing.

A kick-off does two things: 

• It lets everyone know you are now starting the project and it’s time for people to live up to their commitments.
• It gives you an opportunity to walk everyone through the project charter.

With no kickoff, the stakeholders might be addressed separately or in small groups. With the kickoff, you get everyone together as a whole; it unifies everyone.

Formal kick-off meetings should include the project sponsor, project manager, team members and all the stakeholders. And although the kickoff is more than a pep rally, don’t under-estimate the value of having a pep rally. Without it, you start off with a thud instead of a bang.

Adapted from False Start: 5 Things That Can Derail an IT Project Before It Gets Going, Joseph Zucchero, The Casey Group

Project Kick-Off Meeting Agenda Template

One of the most important project meetings for the team and stakeholders will be the project kick-off. In our Resources section, you ‘ll find this agenda template to help you begin to organize the structure of the meeting and customize as needed.

From Action for Results, Inc.

The Importance of Project Requirements

What is a requirement? Isn’t it the same thing as “need”? Not exactly. Although requirements flow down from needs, they are different. For instance, a customer need is that they would like to reduce support costs by 15%. One of the requirements might be that the product must include the capability to diagnose problems remotely.

You should recognize a need versus a requirement and be able to document them as such.

Here are some key points about requirements:

• Requirements come from the customer needs, which is where the process starts.
• The product of the project is designed to fulfill the requirements and then is validated against those requirements.
• Without customer requirements, you cannot validate the product (even if you can “test” it).
• If you start with specifications (design), you risk creating something that does not meet the customer’s needs.
• In order to validate the customer requirements, they must be unambiguous and measurable.

Poorly defined and incomplete requirements are the number one cause of project failure, leading to the project being over budget, behind schedule or not meeting the stakeholders’ needs.

To ensure a solid, comprehensive set of requirements:

• Clarify the source of the requirement (business function, customer, standards and regulations, etc.).
• Assign an owner to each requirement (someone on the project team).
• Agree on the priority of each requirement related to the significance of its impact on the project/product.
• Be specific; use unambiguous, specific language that can only be interpreted in one way).
• Make them measurable and testable.
• Give each requirement a reality check – can it be implemented with available technology, within the project schedule and budget constraints?

From Action for Results, Inc., 2010

Get a Solid Start with a Good SOW

The statement of work (SOW) is a narrative description of products or services to be supplied by the project. It is one of the primary inputs to the project charter. As straightforward as it sounds, getting an SOW right is no easy task. However, nothing is more fundamental to the success of a project. If the SOW is too vague, too broad or too generic, it can leave room for various interpretations, which can lead to trouble later. 

A good SOW includes these things:

• Major deliverables and when they’re expected.
• The tasks that support the deliverables, as well as who will perform those tasks.
• The project’s governance process, along with how often governing committees will meet.
• The resources that are required for the project, what facilities will be used and whose equipment will be needed, as well as testing requirements, if necessary.
• Who will pay which costs and when.
• Clarification for all parties on what constitutes success or failure of the project.
• Make sure that the language in the SOW is clear, specific and easily understood by everyone involved.

Adapted from How to Write a Statement of Work, Mary Pratt, Computerworld Magazine, 2006

Taking On the Facilitator Role

As project manager, you will often be expected to take on the role of the facilitator in meetings, planning sessions and group discussions. It’s important, especially in the beginning of the project, to establish yourself as a competent and fair person.

If you don’t already have the skill set, take some time to learn a few techniques for providing structure to group discussions, dealing with difficult situations, and ensuring team focus on the right outcomes.

Here are some initial tips that will help you facilitate your initial project meetings and gain confidence in the role:

• Leverage the Resources Within the Group Help the group explore its own knowledge and source of creativity and get over knowledge gaps by using assumptions and action item/open issues lists.
• Honor Each Person Encourage full participation but respect the fact that it may look and feel different for every person.
• Start Right from the Beginning How you start your initial session can set the tone for the rest of the meetings. Allow time for proper understanding of needs, priorities and expectations of the work ahead.
• Contract with the Group Do this before and during the session to clarify roles, norms, commitment, goals, etc.
• Don’t Assume - ASK! You cannot possibly know every function, every culture, every individual…check your assumptions before you act on them.
• Get Results You are there to perform a job. Be clear what it is and stay focused on the needed outcomes.  Discern key issues and concerns so that you can get those addressed and move forward.
• Observe, Test, Think on Your Feet and Be Ready to Improvise You may have a brilliant plan going in but be ready to drop it if you discover that you built it based on partial knowledge or wrong assumptions. Don’t get stuck doing things a certain way.
• Admit Your Own Ignorance and Show Your Willingness to Learn and Improve Don’t ever pretend to know more than you do; ask for suggestions and feedback from the group.

Adapted from Essential Facilitation Skills for Projects, Action for Results, Inc., 2010

Reading Room: Project Initiation

Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management, Jamal Moustafiev, J. Ross Publishing, 2010

Determining Project Requirements, Hans Jonasson, Auerbach Publications, 2007

Practical Guide to Project Scope Management, Shyamkumar Narayana, BookSurge Publishing, 2008

Practical Project Initiation: A Handbook with Tools, Karl E. Wiegers, Microsoft Press, 2007

Project Requirements: A Guide to Best Practices, Ralph R. Young, Management Concepts, 2006

Identify Your Project Stakeholders - and Only Then Plan Communications

“Identifying Stakeholders” is one of only two process in the PMBOK’s Initiating Process Group (the other is “Develop Project Charter”), which highlights the importance of gathering this information right at the start of your project. Here are two resources to help you get started.

We had an entire newsletter on project stakeholders in July and provided a link to our stakeholder analysis tool here.  But we’d also like to point you in the direction of an excellent article by one of our consultants, Rich Maltzman, PMP. You can find it here.