Cheers!   Join us for our new podcast, the Project Management Happy Hour! In our first 5 episodes, we are going to look at the first 5 questions you need to ask whenever starting a new project, whether you are:

• Kicking off a fresh new project
• Taking over an in-flight project
• Scoping out a new project opportunity
• Assessing a project that may be in trouble

https://itunes.apple.com/us/podcast/project-management-happy-hour/id1251371805

JOIN TODAY, AND GET IMMEDIATE ACCESS TO TAKE THE QUIZ!

Members get unlimited access to take the quizzes for our podcasts. Not only, that, but you also get a certificate, we’ll upload your PDU’s to PMI, and you get lots of other great benefits – click here for details on becoming a member.  

JOIN US FOR HAPPY HOUR!

Come by and say “hey!” in our PM Happy Hour FB Page at https://www.facebook.com/pmhappyhour/

Show Notes for this Episode

Now we know what success is, it’s time to dig deeper and ask the obvious question:

What is the SCOPE of this project? What are we delivering, and how are we delivering it?

If you have read the PMBOK, PMI makes a good point that “Scope” is not just about the product or deliverable of the project. It is also about HOW the project delivers that product. Apparently, the HOW is too often missed.

Some key points that can trip you up:

• How do we need to test and validate the deliverables? Are there multiple phases of testing (performance testing, DR, integration testing, user acceptance testing) and what is involved?
• Is there a required delivery method or process?
• How will the ownership or maintenance of the project’s deliverable be transitioned to the ongoing owner after the project? What training, knowledge transfer, or documentation is required?
• What regulatory impacts or certifications need to be considered? PCI? Local labor laws?

Furthermore, projects don’t live in isolation. Every project will have dependencies and assumptions made, particularly for the scope. Hence, the importance of knowing not only what you are delivering as scope, but HOW you are delivering it.

Dig Deeper: The Problem or Opportunity [10:12]

While identifying a clear scope is standard fare, where we often fail is when we don’t stop to ask “Why this scope? Why now?”

If you always think of a project as a solution to a problem or a way to exploit an opportunity then this makes a lot more sense. Because even if you have the solution, you still need to understand what the real problem is that you’re solving and what opportunity you’re trying to exploit.

If you don’t know these, then stop and have the courage to ask your stakeholders if you’re looking at the right solution. Because sometimes you could be looking at a great solution, but it is not the right one for the project.

Here are examples of leading questions you can ask:

• What exactly is the problem or opportunity we are trying to solve or exploit?
• Whose problem or opportunity is it, and how does it affect them?
• Is this scope or solution the best way to solve the problem or exploit the opportunity?
• Is this the right time to address the problem or opportunity?

The bottom line is – feel free to ask questions and be empowered to do so. It is your project, and it is your responsibility as the project manager to understand the answer to these questions.

It may seem awkward to ask if you are coming into the project later in the game. But, go ahead and still ask. This applies even if things are going well because it will make you better prepared. And if in case you don’t get good answers to these questions, it will be much easier to course-correct early on than when the project is nearly completed and everyone realizes it’s a miss.

Unfortunately, too often we see PM’s take a project and charge ahead without asking too many questions and understanding why the project is there. Worse, we’ve seen projects “successfully” delivered only to find it was a failure because the customer’s needs weren’t actually met by the solution. Remember, a couple of questions can save you problems later on.

How Did We Get Here [15:23]

Even if the scope is clear and seems like a good solution to the problem you should also

understand how the solution was developed. This will help give you a confidence factor

in scoping diligence, fit, and likelihood for changes down the line.

Sample Questions:

• Was the process formal or informal?
• Were internal scope or business case reviews performed?
• Was the solution developed unilaterally by an individual, or in collaboration with stakeholders?

The less rigorous the scoping process is, the more likely it can change, or is not the optimal solution. Hence, it is important to figure out how the solution was developed and where the input came from with your stakeholders so that you can go back to them in case there will be a change of process and testing.

What to do with bad scope? [20:34]

Step up! PMs are professional and we are paid big bucks so we need to stand up

and deal with the bad scope. Project managers are responsible for sorting out differences between stakeholders, even if those are internal, external, or wherever in the management hierarchy. We are put in charge of the project to get it sorted out and not whine about it. We are the CEO of our own project and we have to hold people accountable including ourselves.

Here’s an example of a bad sold scope and how it could have been handled:

There’s a big strategic service project and its first project manager left the business. Apparently, the new PM who took the lead of the project was more concerned with pushing back on sales about the “bad scope” than in dealing with it. This is despite the fact that the delivery team had already engaged with the client – so, they were underway.

There was a leadership vacuum on the project in addition to very poor communication; tempers got hot and the delivering company nearly lost the project and the client. Surprisingly, the fix was not that big of a deal. It was to get immediately tactically engaged, open up communications among all parties, be open about the challenges with the scope then sort it out with integrated change control.

The lesson in this case study is – No scope is ever perfect. The important thing is that if you find a problem, stop and deal with it. If it is wrong, confirm it is wrong, fix it, and formalize the change. Using the standard integration change control processes, make sure there is clarity on impact to schedule, budget, quality, and risk. You need to have a plan to sort it out.

The key definition of projects as per PMI  is that they are progressively elaborated, which is why it is okay not to have all the answers at the beginning. You need to identify where any gaps are and what your plan is to close them.

TAKEAWAY [27:55]

Probing questions to use when defining “scope”:

• What is the problem or opportunity that this project is trying to solve?
• Is this the right scope to solve the problem or opportunity?
• Is this the right way to deliver the solution?
• Who solved this and how? Were the consumers of the project’s product involved?
• If I don’t have a quality or detailed scope, do I have a plan and phase gates in place to get us there?
• Have we identified all the assumptions made when developing this scope?
• Are dependencies on other teams identified clearly?

You may be in trouble if:

• You don’t know the problem or opportunity the scope deliverable is trying to solve
• You aren’t perfectly clear on the scope
• The scope is not understood or agreed upon by all stakeholders
• The scope was informal or unilateral in development

We hope you find value in this episode as much as we did. We’ll be covering the remaining three questions on our next podcasts.

You can also let us know your thoughts about this topic by leaving a review or comment to help us get the support we need in order to keep this podcast going.