Fear No Project Blog – Focusing on the Management Side of Projects

Have you ever been assigned to manage a project that seems like a shape shifter—you know, a character from a science fiction story that keeps appearing to different people in different shapes?  You already know that project success requires a clear understanding of what your project is all about, why you are doing it, who cares, and who is involved. But that doesn’t mean that the answers to these questions are clear on all of your projects.  You know you will have a much tougher time succeeding on projects where the answers to some pretty basic questions keep changing—or are unclear.

So this week as I get ready to watch the NFL Superbowl, I thought I would devote the post to the top 10 questions you should ask about every project you’ve been assigned to manage. I imagine you’re thinking, “Bruce, these are pretty basic and my project is very complex.”  And yes, they are basic questions – I call it getting back to basic “blocking and tackling” (Sports metaphor)! That’s why I’m shocked that on many projects these answers are not asked or well understood.  Take the time to ask them when you’re offered (or most times assigned) a new project.  Or if you’re already on one that’s not going so well, I suggest you gather the team and meet with your stakeholder to get the clarifications and answers you will need to succeed.

1. What are we doing? You’ve read the proposal and you’ve seen the statement of work. But what is the project really doing? Scope statements and Performance Work Statements (PWS) are rarely clear enough to know what the clients want done.  Are you doing everything you should be doing? Are you doing things you should stop doing because it’s beyond scope or will bog you down?  I love SCRUM and the fact that we use a guiding principle called “the definition of done.”  If you can get agreement on that definition then you have a better chance of doing the right things.

2. Do the stakeholders and project team members agree on what we are doing? Ah, that question! Does everyone see the project in the same way, moving toward the same goals? Or has the project become like the elephant in the room of blind men, where everyone describes it differently based on their perspective.  Some see a skinny tail, some see a large trunk.  If so, stop. Get everyone that matters together and facilitate a working session to get agreement before you do anything else.

3. Why are we doing this project? What is the real purpose of the project, and why are we investing our limited time and energies on it? Sure, we want to do a good job for the client. But are there other reasons for the project? For example, is the project of strategic importance to our company because it will represent an important qualification? Or, is the project important because some executive‘s reputation and ego is involved?  The why behind the project can drive the goals as much as understanding the requirements?

4. Who are the executive sponsor and the most important stakeholder(s)? Do you know the executive sponsor? Have you worked with him or her before, or do you know someone who has? The better your relationship and access to them, and the better you communicate with them, the easier this project will be.  In addition to the executive sponsor, make sure you have a list of all of the stakeholders and why they are involved. Some are involved because they need to be kept informed; others because the project is essential to their line of business or because they have invested resources and funds in it.  Build a RACI chart (I plan to cover this in a future post).

5. What is most important to the executive sponsor and the most important stakeholder(s)? What is their hot button? What does success (or in Agile we say done) mean to your executive sponsor and most important stakeholder(s)?  Is just building the product enough?  Is just delivering the service you have been contracted to do enough?  My guess is there is more to the project than just checking off the deliverables.  Just listen to the customers and stakeholders.

6. How was the project schedule developed (and by whom)? OK I have written many posts and articles on project schedules and making them useful and predictive.  Like me, you may have inherited a winning proposal only to find that the project schedule is confusing. It may seem incomplete, or too high level. Find out who developed it and meet with them, if you can, to understand the assumptions that went into the project schedule and any ‘unspoken’ factors that should be discussed.

7. Do I agree that the project schedule is realistic and feasible (or would you like another crack at it)? Once you understand the project schedule, how it was created, and what you are really doing (See Question 1), then you should take a hard look at the schedule as you consider Question 7. If it doesn’t seem realistic or feasible, do you have a choice—can you rework it, or at least flesh out subtasks so that it becomes more useful?  I don’t believe in wall paintings that are schedules.  A schedule must be predictive of what is planned and happening.

8. How has the project been communicated to the team? This may seem like a silly question, but I always ask it because based on who talked to each team member during selection or onboarding, the answers could be very, very different. Of course, YOU want your team members all on the same page. So, as a first step (if you haven’t done this yet), consider creating a project charter that spells out exactly what you are doing and why.  Then be prepared to over-communicate to keep everyone aligned.

9. How were the team members assigned or selected? Questions 9 and 10 are related, and very important. Did you inherit the team? If so, who selected them? Who assigned roles? How was this assignment done?  I’m still surprised that some people think we’re all square pegs—plug-play replaceable.  But having been a project manager for many years (maybe too many), I want to assure you that this is not so – every person id unique and has specific skills.  You may find that team members were assigned simply because they were available and not because they were right for the job.

10. Does the project team have the skills we will need to be successful? Finally, your project success will depend on whether you have the right skills in the right positions. Want to take your project from good to great? Then take a look at the skills on your team. Where are you weak? Where have people been mis-assigned to areas that might not be their strengths? I’m not saying that everyone on the team has to be an “A” player—but you need enough of them, in the right roles, to ensure success.  Interview each person and find out their strengths and weaknesses.

So what are your basics for managing a project to a successful completion?   Share your thoughts in a comment.