Voices on Project Management

> Back to Voices Home

"Requirements" for Managing Your Project and Team

| | Comments (2) | TrackBacks (0)

Editor's note: The title of this post was changed on 9 December 2011.

Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?

It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.

For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.

When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.

When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.

Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.

Take time as the project manager to set your requirements for running the project. And do so as a high priority.

What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: "Requirements" for Managing Your Project and Team.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/778

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

2 Comments

When a project is on the fast track, it is easy to gloss over defining the requirements once the deliverables have been identified. It is NOT easy to define the requirements once the deliverables start coming.

So, I believe it's very important to take the time to adequately capture and define the requirements. Accurately defining the acceptance criteria for the deliverables is every bit as important as identifying the deliverables themselves.

I maintain that even when the requirements are well defined, they are still at risk. The chief influence on a project is people and people have unique perceptions that tend to "drift." I also maintain the amount of "drift" is directly proportional to the length of time and number of stakeholders involved.

If adequate time isn't dedicated to define the requirements out of the gate, the project is already "adrift." This can lead to gaps in understanding, delays, re-work, cost-overruns, and a very messy close. The requirements gathering stage should always get the high priority that it deserves.

The topic heading is bit confusing. I mistook the 'Requirements' as technical specifications or the 'need' of the customer.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories