Project stakeholders are key to the success of any project.  It is very important to identify them at an early stage in the project and try to find out what their expectations are.

To find the stakeholders of your project, you have to think of who is interested in the outcome of the project or who may have an influence (good or bad) in the development or acceptance of the project.  They will be within and outside your organization, and some examples are:

• Your boss or higher management
• The Customer
• The End User
• The Team Leader
• The Development Team
• The Test Team
• Quality Management
• Configuration Management

And even in each of the above, there could be different stakeholders.  For instance, the customer could have a Contract Manager, a Technical Manager and a Quality Assurance Manager, and their expectations would be different.

OK, you have listed the stakeholders.  That was the easy part!  Now you have to find out what they expect from the project.  In some cases it will be straight forward, and a simple question to the stakeholder will give you the answer.
But sometimes it is more difficult.  Let’s imagine an extreme case in which your company was awarded a contract against the recommendation of the customer’s technical manager and he wants the project to fail.  Of course he would never say that, but you have to find out to be able to manage him.

So now you have stakeholders and expectations, and that is where your day to day work begins.  You have to manage everyone’s expectations to bring the project to a safe port.  And of course there will be conflicting expectations at some point, and that is when you will have to make decisions and explain them to the affected stakeholders.  You should keep them informed, especially when things are not how they expected.

It sometimes happens that your are unexpectedly promoted to being a project manager, or you are already managing a project but you are moved to a much bigger one.  There is a range of different reactions you may have at first: excitement for the challenge, fear, boost of self-esteem, panic…

Whatever your initial feelings are, you have to make sure you think you are up for the challenge.  Different things may make you doubt you are the correct person for the job:  necessary skills, some people in the project may think you are not valid for the role, the customer may be difficult to deal with, big project risks…

Analyse it and be honest with yourself.  Don’t be too gentle or hard to yourself.  List the things you have to learn, the areas where you will need more help and the possible risks or conflicts.  After this analysis your feeling about the project may be different:  you were confident at the beginning and then realized the project was more demanding than you thought or you thought you were not ready for it and now you are confident you can perform the job.

After this process there are two possible options:  you think you are able to lead the project to success, or you don’t.  If you do, congratulations!  If you don’t, it’s time to talk to your boss about it.  He may have seen something on you that you haven’t and you are readier for the job than you think.  Or you may not, and in that case it better to let someone else to take over.  There will be another chance.

Don’t underestimate the power of the confidence in success of the project manager.  As a leader, he will transmit what he feels.  Lack of confidence can lead an easy project to failure and a strong confident leader can make a complex project be a complete success.

It might seem quite obvious, but can you answer the following question:

What is the scope of the project?  Or in other words, what do you need to produce to consider the project successfully finished?

I am sure you would at least be able to give an answer like “We have to develop (or upgrade, manufacture…)  a system (or component, SW program…) that has a defined functionality”.  And you might even be able to define this functionality as a set of requirements.  This is good, but it is far from complete.

Imagine two different projects.  Both have to deliver the same product with the same functionality.  Project A was contracted as a development project, and therefore the customer will ask for detailed requirements documents, design documents, blueprints and so on.  Project B was contracted as a COTS, and the customer is only expecting user level documentation, like user manuals or maintenance manuals.  Is the scope the same in both projects?  Not at all.  Project A will have to produce a lot more documents before considering it finished.

And the difference between two scopes could be subtler.  Only a change in the Quality standards or the Qualification methods could make a substantial difference in the workload required to finish the project.

So what do you have to do?  You have to write down:

• Project objective
• Deliverables (products, documents)
• Services (support, training, warranty…)
• Applicable standards (management, quality, configuration management, development life cycle…)
• Acceptance criteria

And when you have all this information, you have to communicate it to your team.  It is extremely important that everyone working on the project knows what the outcome of the project has to be.

A good definition of the scope will not automatically guarantee the project success, but a vague (or non-existent) scope will lead to misunderstandings within the team and problems in the customer acceptance.

You just were appointed as the new Project Manager.  You are full of energy and ready for action.  What should you do first?  The answer is easy: stop and assess what this new role demands from you.

When you get a new assignment, it is very tempting to move into action right away.  You may already know the project, or even are working on it and you think you know what you should do.  The first time I was in that situation I started doing what I knew I had to do, and I have to say that I was right most of the time.  The “only” problem is that I didn’t know all the things I had to do, and sooner or later those tasks that I had missed caused a delay in the project.  These delays were bad for my projects, but even worse than that was the frustration.  One day I thought everything was running smoothly and the next day the project slipped because I had missed something.

So sit down and start writing your job description.  If you are new to project management you will probably not be able to define all the tasks by yourself.  Get help:  ask other project managers in your company, talk to other people working on your project or on similar ones:  Quality Assurance Manager, Configuration Management Manager, Team Leaders, Financial Controller…  And last but not least, talk to your boss.  That has to be the last stop when you think the list of your responsibilities is complete.  Make sure your boss and you have the same understanding about your job.  It is very frustrating to work for months and then find out that your boss expected something else from you.  Try to avoid that from day 1.

Now you know what it is expected from you as a Project Manager.  You know what you have to do, and that makes you feel good, because you are now in control.  And if it is good for you, it will be good for your project members.  Yes, you guessed it:  Do the same with them.  Don’t forget to make sure they understand what you expect from them!