The success of a project manager largely lies in the individual’s ability to communicate. Some project managers have great oratory skills but don’t ask the right questions at the right time.

Here are some key questions for each of the project management process groups. This is not meant to be a comprehensive list; just some questions to get you thinking. Neither will you need to ask all of these questions for every project.

Keep in mind, the project process groups are seldom sequential, one-time events; they are overlapping activities that occur throughout the project.

Initiating Process Group

1. Why are we doing this project?
2. Is your project sponsor fully engaged and on board?
3. What is the authority level of the project manager?
4. What do we wish to accomplish?
5. What are the products and services we wish to deliver?
6. What are the budget constraints?
7. What are the schedule constraints?
8. What assumptions are being made?
9. Who will be impacted? Which stakeholders have the greatest interest and power?
10. Who will comprise the project team?
11. What are the most significant risks?
12. How will we know if the project was successful?

According to PMI, "47% of unsuccessful projects fail to meet goals due to poor requirements management." Wow! Requirements are a pretty big deal. Let's look at five things to start and five things to stop in requirements management.

5 Things to Start

1. Identify and engage appropriate stakeholders. Project managers who work in a matrix environment should seek resource approval from stakeholder's managers early in the project.
2. Ensure the requested software features will be used. Inquire (politely) why the features are needed. How does the requirement align with the goals of the project? The results of one Standish Group indicated that 45% of product features were never used.
3. If questionable, ask if a requirement is in the scope of the project. The project manager may wish to capture out-of-scope requirements in a parking lot for future consideration. Check with the Project Management Office (PMO) or other authority on how to handle these requirements.
4. Analyze requirements using context diagrams, use cases, stories, and other tools and techniques. Project managers or business analysts who use different tools help the stakeholders see things from various perspectives.
5. When requirements change, be sure to update the requirements under version control. Ideally, the project manager should be able to see the versions of the requirement from the initial version to the current version. Many of the requirement tools today provide this capability.

How many times have you experienced scope creep? You know the drill—you elicit and document the requirements. You receive sign off. You continue to see changes to the requirements. Many projects experience 10, 20, 25-percent change in requirements over the life of the project. Let's explore how to manage project scope.

Scope is Not a Mouthwash

You cannot manage what you do not understand. Let's get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK) defines scope as the sum of the products, services, or results.

When we use the word "scope", it is helpful to specify the type of scope—product scope or project scope. The product scope are the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.

Imagine that you plan to have a painter paint your living room. Here are some product scope questions:

• What color do you want for the walls, trim, and ceiling?

• What brand and type of paint do you want?
• Do you want a second coat of paint?

What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:

• Will someone remove the furniture from the room before the room is painted?
• Will the painter clean the walls and trim before painting?
• Will the painter tape the trim before painting the walls?
• Will the painter use a brush or a paint sprayer?
• Will someone inspect each step before the painter moves to the next step?

Want more clarification on product and project scope? Read this article from Villanova University.

Manage Your Project Requirements

When it comes to requirements, I wish I could read my user's minds. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.

A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.

Like the word scope, it is helpful to use an adjective when talking about requirements. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.

I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements into greater detail.

• Business requirements - the high-level business goals of the project (e.g., Increase customer retention by 5% by the end of the year).
• User requirements - a task of a user group (e.g., Quote an insurance policy).
• Systems requirements - the detailed specifications of the features and conditions needed in the system (e.g., The system shall invoice customers at month-end).

WBS: Define Your Scope

How do you eat an elephant? One bite at time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.

The WBS is a hierarchical decomposition of the work to be performed in order to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project. Learn how to build a WBS.

Use Prototypes to Analyze Requirements

Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.

Monitor and Control Project Scope

Project managers should meet with their teams on a regular basis to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.

Manage the Changes

Many project managers think their job is ensure that no changes occur. Make no mistake about it—change happens. Expect it!

Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don't get me—project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.

Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.

Your Turn

Project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user's needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.

People use the term "project" loosely. Someone may say, "I need to finish my filing project today." But what is a project and what's the difference between creating products, services, and results?

What is a Project?

A project is a temporary endeavor undertaken to create a product, service, or result. —PMBOK

Projects are Temporary

Projects are temporary. Projects have a beginning and an end. In contrast, teams perform operational tasks on a daily basis. Team members scan documents, handle customer calls, and pay invoices. 

This is a guest article by Dana Brownlee from professionalismmatters.com.

One of the most common questions I get when speaking to groups is “How do you deliver a difficult message to/push back on senior leaders – particularly the difficult ones?” I certainly understand the popularity of the question because that’s a sticky situation for sure. While project managers and others often find themselves in opposition to the boss’ ideas, recommendations, or preferred course of action, telling the boss they have an “ugly baby” is a different story.

One of my favorite suggestions for this unenviable predicament is using risk analysis. Indeed, I think risk analysis can be the secret weapon of managing up! Why? Because risk analysis provides an opportunity for you to focus the discussion on the objective (often quantifiable) facts and away from the more emotional opinions.

In my book The Unwritten Rules of Managing Up: Project Management Techniques from the Trenches I discuss the importance of using risk analysis to make your case for a particular point of view. Consider the following example…

Have you ever had someone torpedo your project? Did this individual have a motive to undermine your efforts? Or, did you make some stakeholder mistakes that gave rise to this event?

Either way, it's hindering your progress. Things are not going as planned. What can we do to manage stakeholder risks better?

A Stakeholder Story

The project manager formed a project team. Within days, the project team started making programming changes. The team worked evenings and weekends.

Most of us have personal and career goals. Our ability to achieve those goals is dependent on our risk management skills, that is our ability to manage opportunities and threats. We seek to make good things happen and to eliminate or reduce the bad things.

Through the years, I have captured my favorite quotes related to the art and science of risk management. I hope you enjoy the insights as well as the humor.

1. "The greatest glory in living lies not in never falling but in rising every time we fall." —NELSON MANDELA, SOUTH AFRICAN STATESMAN

2. "Nothing can stop the man with the right mental attitude from achieving his goal; nothing on earth can help the man with the wrong mental attitude." —THOMAS JEFFERSON, U.S. PRESIDENT

3. “People with goals succeed because they know where they are going.” —EARL NIGHTINGALE, MOTIVATIONAL SPEAKER AND AUTHOR

4. “A winner is someone who recognizes his God-given talents, works his tail off to develop them into skills, and uses those skills to accomplish his goals.” —LARRY BIRD, NBA PLAYER AND COACH

5. "The world is getting to be such a dangerous place, a man is lucky to get out of it alive." —W.C. FIELDS, COMEDIAN AND MOVIE STAR

6. “There is a myth that people hate change. Not true! What scares them isn’t change, it’s uncertainty. They worry about whether the changes are good or bad. People love change when it involves pleasant surprises. What they fear are the unpleasant ones.” —ALAN MULALLY, CEO OF FORD MOTOR COMPANY

7. “Character may be manifested in the great moments, but it is made in the small ones.” —WINSTON CHURCHILL, PRIME MINISTER OF THE UNITED KINGDOM

8. “The only limit to our realization of tomorrow will be our doubts of today. Let us move forward with strong and active faith.” —FRANKLIN DELANO ROOSEVELT, U.S. PRESIDENT

9. "A good plan, violently executed now, is better than a perfect plan next week." —GEORGE S. PATTON, GENERAL IN THE U.S. ARMY

10. “The man who comes up with a means for doing or producing almost anything better, faster, or more economically has his future and his fortune at his fingertips.” —J. PAUL GETTY, ANGLO-AMERICAN INDUSTRIALIST

This is a guest article by Elizabeth Harrin from GirlsGuideToPM.com.

Much of the time, risk management at the beginning of a project looks like getting the team in a room to review the whole project and work out what might be coming that could affect how the project proceeds.

The project manager writes up the discussion in the risk register along with what the team is going to do to avoid or amplify (in the case of positive risk) the risks. As the project progresses, more risks are identified, dutifully added and managed.

What’s happening here is that we’re looking at the work and impacts on the work. This approach to risk management is very task driven. We ask questions like:

• What might prevent us from hitting that milestone on time?
• What might mean we need to ask for a budget increase during this phase?
• What quality problems might we come across that would give the client an issue?
• Who might be a difficult stakeholder on the project?

These are all valid questions. But they miss one crucial area that massively affects everything on the project every day. Us. The project team.

Our skills, ability to work together as a team, or lack thereof, present the biggest chance of success for the project and also the biggest risk.

Here are some examples of how the people on your team make your project inherently more risky.

Your project team has just completed a major project or hit a significant milestone. The team members have worked hard and put in the extra hours to bring in another successful project. So, how do you thank your project team? What ways will you let them know you care?

Practical Ways to Thank Your Project Team

1. Send a hand written thank-you note. I recently saw a Thank-You card pinned to someone’s cubicle wall. The card was dated five years earlier. Why would someone keep a card that long? Hand-written notes are a rare commodity in our digital age. Furthermore, tangible notes may be displayed and savored.

You've just invested your precious time in a project management symposium, conference, or training class. Congratulations on being proactive in your project management development. But how can you take action after a symposium to obtain the full benefits of your learning?

Why You Should Take Action Soon?

Here's the problem we all face when attending a project management symposium. Things at work don't stop, do they? More emails and voicemails have arrived. New problems have popped up. It can take days to recover.

But, if we fail to take action from the symposium soon, we forget what we've learned. Our motivation to change wains. And our personal growth—that we so badly want—does not occur.

It's frustrating, isn't it? You've gained some new knowledge to advance your career. How can you review and reinforce your learning? What's the trick of transforming your newly gained knowledge into powerful skills?