Should a Project Manager give new team members a document that defines the project?

Question

I have recently joined an existing large, complex project to deliver some specific outputs. The only information that the PM gave me related directly to the part of the project that I am responsible for, and not to the wider aspects of the project. I can do my part without knowing much about the rest of the project, but it would be nice to understand the whole.

What should a PM communicate to new team members if they join mid-project?

Just to clarify, my role is to bring in some temporary technical resources that will deliver short term support while the organization decides what level of permanent staff will be needed to fill the roles, and after a few months they will go into the market to recruit. This is a one-off piece of work that doesn't involve any development, coding, or anything of that nature.

Answer 1

I tent to believe that providing with a high level summary of the ultimate project's goal cannot hurt anybody.

I have joined mid-cycle projects with a specific responsibility and minimum interaction to the rest of the team members but I found very difficult to define certain specifications and implementing them because I was missing the overall project's objectives. Eventually I had to discuss this with my supervisor and he provided me with the high level Executive Summary that was delivered to the Project Sponsors containing key goals, business benefits and main components. Not too detailed but rich enough to understand the project and my position within it.

Have followed this practice ever since, in other roles, to bring up to speed new members of the team as part of an Induction Plan.

Answer 2

Bearing in mind that you want to deliver the maximal information with the least overhead, I would say educate them on what they need to know to get the project to delivery. Background and historical information is nice; more important is knowing where the project stands today and what work is left.

Also critical is the project vision and the business-case of "why" we're doing this project. This can make a huge difference in terms of motivation and buy-in from the team.

If it's a particularly large or complex project, you may want to train them with general background information.

Answer 3

Something I haven't seen mentioned yet - "a document that defines the project" is called a 'scope document', and it's critical that everyone that's in any position to effect a change or make a decision, to any of the deliverables, MUST know what the scope is. Not knowing the scope (project definition) adequately is where scope creep comes from.

Answer 4

Least amount of overhead is a critical thing here, I agree with ashes999.

I have frequently been given way too much information. This generally has three effects:

1. information overload leads to indecision (there's so much to handle, where do I start?);
2. reading overdose leads to sleepiness and therefore inefficiency;
3. in an effort to keep control over both overload and overdose, some documents get tossed to the side - some of those might be more important than those that made it through.

Obviously you don't want any of points 1 to 3 to happen if you can help it. I much prefer the "need to" basis. That said, it depends who the person you give it to is. If they are very business focused, the type to gloss over information anyway, then they may as well have the full story, they'll be just fine. On the other hand, if the person is detail oriented, meticulous, then refrain to the best of your ability from feeding them the full story. Give them what they need, otherwise you'll swamp them and lose them for months (speaking of own experience here).

Answer 5

You should be sharing most of the documentation related to the project with your team members when they come on board and continue to do so throughout the course of the project. As yegor256 alluded to, if you are doing it right, all of this is baked into the process. Project charters, plans, status reports, etc. should all be available on a shared drive, Sharepoint, Lotus Notes, Basecamp, etc.

Answer 6

In addition to knowing the why, knowing the scope of the entire deliverable will know prevent reinventing the wheel. Is feature X a 'one of' or similar to something already created? The answers to these types of questions mat come from the PM if you know to ask. Knowing the larger spec will help you ask the right questions.

Also, you will be expected to participate in status meeting at some level. Knowing how you piece ties into the rest of the project will help you communicate to the other team members.

Answer 7

The information has to be available for you. The responsibility of a project manager (part of "Distribute Information" process of PMBOK) is to make information available, instead of communicating to you.

Otherwise, imagine a project of 50 members, joining and leaving very often. The PM will be busy just with communications? Definitely not! The PM has to spend his/her time for establishing proper communication environment in the project.

Answer 8

Coming in mid-stream means that decisions have already been made on how the requirements are being fulfilled.

I'd say you only need information related to the specific task you need to take care of.

Answer 9

In the world of government contracting the first documents I ask for and read when joining a team are the scope of work (SOW) and the operations concept (OpsCon) documents. These are also the documents I hand to anyone joining the team.

The scope of work is part of the contract documentation and describes the work being paid for.

The operational concept document describes how the product is intended to work once delivered. It helps me understand the goals and overall picture of the project.

Answer 10

This is kind of strange question for me -- in my practice, each one of the team members receives a scope of project, design and prototype (this is for websites) at the beginning and basically based on these (especially the scope) I receive the reports for the progress.