Top Ten Questions You Should Ask about Every Project You’re Managing

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.

Project methods – Waterfall versus Agile

I have been reading a lot of discussion recently regarding the use  of different methods for planning, implementing, and managing projects.  Many methodologies exist in the industry; two of them are:

  • Traditional Waterfall (some would say PMI PMBoK but not necessarily) model
  • Agile (SCRUM, Extreme, etc.)

I read a really good article last week in the Harvard Business Review Blog — A Better Project Model than the “Waterfall” by Jeff Gothelf. In this post he talked about needing a better model than the traditional waterfall model.

Here is a summary of Jeff’s post:

The main argument is that waterfall methodologies, which have been around for a long time, have a fatal flaw–they depend on accurate requirements. The problem with this dependence is that requirements are often wrong. He discusses giving teams the ability to work with clients to find out what the real requirements are. One of the quotes from his post that I really like was from Josh Seiden, who said, “In software development, reality bats last.” What he means is no matter how much planning or optimism there is about the software product being built, the only true project success is the reality of customers using it to solve real problems.

He goes on to share examples of Agile methods, in which teams use lists of features that are prioritized by product owners (not developers) to drive the project. In addition to prioritized lists, he suggests that each project team should be handed specific success criteria. These  criteria must  be quantifiable and directed to specific outcomes that meet customer’s needs.

My own opinion of this conversation is that it is not either black or white–waterfall vs. Agile.  As both as PMP, certified in waterfall methods, and a PSM, certified in Agile Scrum methods, I contend that a blend of both methodologies is often the right answer. Agile requires small, bite sized “sprints” with smaller teams in order to produce results. However, many projects are quite large, with as many as 300 people working at any one time. In these cases, running lots of small teams with sprints can become a project management nightmare. Using an approach that allows some portions of the project to use a more traditional waterfall method, and other parts of the project to use Agile, can make the overall project more management while still achieving the desired outcomes.

As I’ve stated in prior posts, requirements are not easy to capture, especially in complex software products. There are many techniques today (including Agile) which allow us to work with real users and discover the true requirements and needs and the measurable outcomes that must be produced. One such technique, Performance DNA, is used by my organization to ensure that all requirements are identified and linked back to prioritized outcomes.

In closing, as an experienced project manager who is certified in both methodologies, I am suggesting that “either/or” is not the right discussion.  Instead, I propose that a combination of waterfall and Agile is more likely to be the right approach.

Do you have experience using a blend of waterfall and agile, or do you prefer one over the other?


Get every new post delivered to your Inbox.

Join 577 other followers