001-The First 5 questions to ask whenever you start a new project (part 1/5)

001-The First 5 questions to ask whenever you start a new project (part 1/5)

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.

When I sit down for the first time with project sponsors or key stakeholders, especially in kickoff meetings, I like to start with one, simple question. The answer they give is the most telling statement about the project that your sponsor & stakeholders can give.  Learn what that question is – and how to ask it – in this episode!

 

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

Having done a lot of training and building a lot of processes, Kim developed a model for rapid onboarding of projects. He turned it to a 1-day training workshop. Now, he has made it to a podcast for the learning to become more accessible to project managers or those who want to become one.

Our topic is divided into five episodes and it will cover the questions you need to ask when you start a new project. You can use this as a guide whenever you receive a new project or when you take over with one that is in-flight.

First Question to Ask [5:47]

“Can you tell me what is the single most important thing that has to happen for you to call this project a success?”

If you cannot figure out the answer to this question at the very beginning, then you are probably setting yourself up for some trouble later on.

To quote habit number 2 of Stephen Covey’s book, 7 Habits of Highly Effective People, you need to begin with the end in mind. Knowing what you got yourself into is a good start. This will help you get an understanding of the problem you need to solve and how it can be solved.

There are instances when project managers get excited and they want to jump right into the project, look at the plans and deliverables. But it is important for you to stop, take a deep breath, and give yourself permission to ask deeper questions to put things in context.

Digging Deeper on Success [9:07]

If the goals are clear and the stakeholders are well aligned, it should take them 5 minutes to agree on the answer. You can then you move on. More often than not, though, it’s not so clear. In very contentious projects or in situations where the project is poorly defined, this conversation can take the rest of the meeting. This is not necessarily a bad thing.

You and your stakeholders need to sort out what success looks like for you to get there. As you work to define this parameter, be sure that everyone is aligned. The conversation can easily slip into a laundry list of success criteria. You need to keep the focus on what is the most important.

Here’s a sample statement that Kim use:

“Those are all important points that will lead to a successful outcome, and our project will be lacking if we hit those. But, if we could distill success down to the most important point, what would that sound like?”

You need to dissect what success means to each of your stakeholders and you also need to share your own definition to them. There are a lot of times that the meaning varies per person. It can be credibility and reputation for some, while others define it based on numbers, for example, bonus. If you can understand the personal repercussion of project success (or failure!) for your sponsor and stakeholders, you will be better off.

Considerations on SMART Goals [12:06]

Being well-trained PM’s, we often want to shape success statements in terms of SMART goals (Specific, Measurable, Attainable, Realistic, Time-based). Forcing the SMART format can muddy the success statement by introducing less critical parameters. What we want is a single dimensional measure of success that you can use to prioritize other decisions down the line.

For example, if the sponsors respond to this question with:

“Success for us is migrating to the new system with no end-customer impact.”

Clearly, minimizing customer impact is the most important goal. So, forcing the “T” in SMART may not be appropriate. If customer impact is most important, they might be OK sacrificing additional cost or time. Especially if it means ensuring there is minimal customer impact.

So, when there are major project decisions, you can bring the sponsors back to this point to ensure you are aligned. You can remind them of their definition of success to help them realize that it might be okay sacrificing a little amount of time to ensure minimal customer impact.

To drive the point home, you will often find that success criteria defined through this method are single dimensional, which is exactly what you want. You want to help your client define the single most important success factor.  You can use that for future decision making.

Answering Who and How [15:45]

The statement of success cascades down to the rest of the key parameters. But, there’s more to defining success –

“If this is success, who will determine that we have achieved it? And how will they do It?”

You need to keep digging into these questions until you get to the right level of depth. You may also find where you have more work to do. From here, it should be straightforward to ensure that those who need to confirm that you’re successful are involved in defining the project, or at least the acceptance criteria.

TIP!

If you are already well-engaged in a project, don’t worry. It’s never too late to go back and define, refine, or clarify the definition of success. If you haven’t asked this yet, even if you are well underway, you may be surprised to find it’s not exactly what you expected. It is better to find that out now rather than later.

TAKEAWAYS

Probing Questions to use when defining success

  • What does success mean to you personally?
  • What is your overall strategy in this area, and how does success in this project support that broader strategy?
  • Do all the key stakeholders feel the same way about this being success? Does it make sense to bring them into the discussion?

You may be in trouble if…

  • Your sponsor cannot describe project success in one statement
  • It’s not clear who will confirm that the project has met its success criteria. Also, how it’s going to be done
  • The sponsor and/or key stakeholders have changed and you have not revisited the success statement
  • You don’t know what the sponsor and key stakeholders have to gain or lose by project success or failure

Principles for Success

  • Begin with the end in mind (Stephen Covey, Habit #2)
  • If your success criteria are not solid, you are building on shaky ground
  • Have explicit success criteria, and use it as your guiding principle

Home Forums 001-The First 5 questions to ask whenever you start a new project (part 1/5)

  • This topic has 2 replies, 3 voices, and was last updated 5 years ago by .
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #4684
    Kim Essendrup
    Keymaster

    I'm sorry, you are not authorized to view this page. Why not sign up for a membership so you can get access to this and even more content!

    #5190
    Trent Nguyen
    Participant

    Hi! I know this is a super old thread…but I felt this was the most appropriate/relevant topic for my question. Please let me know if this should be posted elsewhere. I gave a lot of background information but this is a HUGE problem that my supervisor PM and I are struggling with…(and continue to struggle with)

    So I listened to the whole “First 5 Questions to Ask” series before the company that I work for embarked on its first HUGE project since I became a PM. The project is to transition the company from two, old-tech, proprietary order management systems (OMS) to a single, newer-tech OMS that we would purchase.

    In one of the first meetings that I attended, it was after I listened to your series, and had all of the questions (and similar questions) typed up and emailed to the company President prior to the meeting for him to ponder ahead of time. He did answer all 5 questions and all of his answers were mediocre at best.

    Specifically to this thread, I did ask him WHY we are moving to a new system and WHAT the definition of success for this project is and his answers: To unify the company on a single, better system and migrate 90% of the clients over to the new system within 6 months. Cool. We can count to 90% and we know how far out 6 months is (December 2018).

    My supervisor (senior PM) and I took this and ran with it anytime someone in the business asked us those two questions during meetings related to this project. Unfortunately, after hearing more than 3 times that VP level and up thought that the purpose of us moving to a new system was for a completely different reason: Execs had committed to one of our top clients that we would be moving to a new system to achieve SOC2 compliance. ALRIGHT…that’s enough of a red flag for the PM team to head back to the President and have him CONFIRM what the definition of success is. Is it to move this client over before the date that we had committed to them? Or is it to move 90% of clients over in 6 months? The President reassured us that the goal is the latter and not the former, and that we needed to make sure the special client would only be moved onto the new system once system/processes were stabilized. Phew! That’s good that he’s standing by what he said originally, and that he had a plan for the special client. The PM team proceeds, for the next month, to identify the system differences, figure out development requirements, establish development schedules (what gets dev’ed when before which clients get migrated), etc.

    Fast forward to July 2018 (1 month later) and the President has been saying in upper management meetings that the project goal is to process 90% of orders in the new system by Dec 2018. The PM team only finds out when VPs are mentioning it in project meetings. WHAT?! And WHEN did he decide this?! And WHEN was he going to tell the project team?! We spoke to him and reminded him what the original expectation was and he said 90% of orders is the new goal. Okay. Fine. That…we’ll just shift a couple of things around…we are only 1 month in…development hasn’t started…we’re fine…

    August 2018 rolls around. Development has started on some of the new system requirements. Management meeting and the President has changed his posture again. The new “success” criteria is that we will move the special client within the next two months. This…is going to be a problem. Our development plan was spaced out so that we would develop the special client’s requirements towards the END of the timeline which was what he had requested. We do not have resources to move the special client’s dev reqs up.

    The project becomes more and more compromised each time he changes his mind. We have had to cut out more and more of Operation’s “we MUST have this thing built or we’ll have to hire 5 more people or extend our turn-around time to the client 2 more days” system requirements to compress the timeline. Which the business blames the PMs for making them get rid of requirements that they need. Fine. Being the bad guy is fine…as long as the project stays on track.

    So far…the PM team has felt helpless. Every time he changes the success criteria, we remind him what the original was and it doesn’t seem to mean anything to him. We were able to shift gears once already because we hadn’t done a hard-commit on anything. The second time, unfortunately, we’ve already started weeks of dev work. How do we approach this now? Or next time? Will we have no choice but to just try our hardest to meet these changes in demands and just write this off as a failed project because management can’t get their crap together?

    There are actually a lot of other problems with this project…to the point where the PM Team is at the “we’re just going to do whatever they tell us to do because they clearly aren’t going to listen to us ever” mode. I know that’s not the way to go, but they just aren’t hearing us but are happy to hold us accountable…

    #5192
    Kate AndersonKate Anderson
    Keymaster

    Trent!  I feel you, this is a tough spot.  It’s really hard to deal with what feels like a ‘wishy washy’ sponsor.

    I’m curious – it sounds like there’s a disagreement between the VPs and the President?  I’d recommend listening to ‘Stage Direction in the Boardroom’ (if you haven’t already).  From what I gather, some one is influencing your sponsor in the background.  My personal attitude to this behavior is ‘If you can’t beat em, join em’. It’s better to become ‘frenemies’ than it is to have them be shapeless things in the background.

    It can be helpful on a project this big with this many impacts to talk to more than just your sponsor on success criteria.  It can be helpful to understand what success is to various parts of the business impacted by this change: eg, “The sponsor wants 90% of clients moved over in 6 months, what does success look like for you here?” them: “if we moved *this client* first”.

    Getting additional success criteria can let you bring those back to your sponsor and then have a discussion: Can we meet both success criteria?  Their requirement is driven by compliance, our requirement is driven by a desire to have a better internal employee experience.  Should we prioritize the compliance requirement?  If not, what are the consequences of missing it?

    This can be really challenging because your own office politics plays a role in it.  Perhaps the President doesn’t want to do what the compliance folks need (or whoever has the SOC2 requirement) because of a grudge, or needing leverage.  Sometimes, that can be a good ‘heart to heart’ moment where you have a crucial conversation laying out your view on how he might be sabotaging part of the company.

    There’s not a ‘right’ answer here.  As for what to do now, perhaps it’s time to have that heart to heart: does this project fairly take into account other team’s requirements?  Is it time to discuss this project with the other VPs and align everyone’s asks into a prioritized list of requirements so this doesn’t happen again?

    Let me know if this is helpful!

     

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.