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.

Tips for engaging and keeping the interest of project sponsors

The project manager’s job of selling a concept or product does not end with the kick-off party. Throughout the life of a project, it is essential to keep the flames of interest and commitment burning in the minds project sponsors. And, that’s a challenge.

Software, in its development stage, is ethereal and vague.  Hours of work are performed to create designs, write code, and build use cases. However, much of that effort is not tangible. The sponsor cannot see or touch the software and must take it on faith that something worthwhile is being done with his money. Building that trust is the job of the project manager.

In the current technology and software industry there are several new “methodologies” that have been introduced to help with the “buy-in” from sponsors and clients.  You should have heard of agile, extreme and Scrum techniques and if you have been around for a while (like certain unnamed people), you have utilized spiral engineering, rapid prototyping, and rapid application development (RAD).  All of these methods and techniques have a common goal of either reducing the scope and/or the timeframe for the individual project or cycle.  While these approaches have proven to make it easier to get the sponsor/ client to participate, they will not do the job all by themselves.  There are still basic techniques and tactics that should be employed by the PM to assure sponsor, stakeholder, or client commitment and buy-in.

So to ensure project sponsors remain interested and committed the project manager needs to do more than provide weekly or monthly progress reports. They need to keep the end result—the vision—alive. Here are a few of the techniques I have found to be helpful in maintaining sponsor’s interest:

  • Context: in status meetings and progress reports show how accomplishments tie back to a function or capability required of the end product. For example don’t just say, “We completed the algorithm for buffer allocation”.  Explain that buffering impacts how quickly processing moves through the system, what trade-offs needed to be made to optimize buffering, and the advantages to the client of the approach taken.
  • Involvement: offer opportunities and encourage participation in team meetings. Give the client or his representative the experience of watching the team wrestle with options and make decisions.  If the sponsor’s representative is technically knowledgeable, ask for their feedback and encourage their participation.
  • Acknowledge expertise: the client or his/her representative has expertise about the effect of the end product on their business. Solicit that feedback and then show how the input from the customer is reflected in the resulting design and product. “You requested the ability to edit the output before it is incorporated into the report, here is how we are providing that capability.”
  • No surprises: there are many good reasons that as the detailed design emerges from top level design, there are changes. You may add a feature, delay a capability, or implement the movement of data in a different way. A task may take longer to complete than initially estimated or the world itself changes. The golden rule for keeping sponsors from losing interest or “going ballistic” is No Surprises! Tell the client as changes are being considered and why. Do not force the customer to find it out for themselves.
  • Communicate often: you do not have to wait for the weekly or monthly report to communicate with the customer. Use informal conversations or email to share (briefly) relevant information about the project or the team.
  • Show – don’t just tell: there are enormous advantages to showing the customer or sponsor the project as it matures. Design your schedule and your modules so that there are many opportunities to demonstrate— such as showing the user interface in pictures, prototypes or use cases; providing example or test cases using input and output of various modules, or showing the integration of the output of one function into the processing of another.

Gaining and maintaining sponsor interest and buy-in is essential to a successful project – no matter which software development method or life cycle is used. I have seen projects that corporate management was ready to slash until the sponsor came in to support the effort. I have also worked with follow-on projects that resulted because the sponsor / customer felt like part of the team and was personally invested in the outcome. And, I have seen projects die a slow and painful death because the sponsor lost interest and everyone involved was going through the motions of fulfilling the minimal contract requirements with no joy or anticipation of the resulting software.

So what is your experience?  Are you now being asked to use agile or Scrum in order to get better sponsor / client engagement?  Is that all it takes? Or do you think the PM needs to do some of thebasic techniques I have described in addition to one of these new methods?

Please leave your comments….

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site