Project Manager Charactersitcs

1. Command authority naturally.

They don’t need borrowed power to enlist the help of others – they just know how to do it.

2. Possess quick sifting abilities, knowing what to note and what to ignore.

3. Set, observe, and re-evaluate project priorities frequently.

They focus and prioritize by handling fewer emails, attending fewer meetings, and generally limiting their data input.

4. Ask good questions and listen to stakeholders.

Don’t just go through the motions. They care about communication and the opinions of the parties involved. They are also sufficiently self-aware to know how their communication is received by those stakeholders.

5. Do not use information as a weapon or a means of control.

They communicate clearly, completely, and concisely. All the while giving others real information without fear of what they’ll do with it.

6. Adhere to predictable communication schedules

Recognizing that it’s the only deliverable early in a project cycle. All this takes place after very thorough pre-execution planning to eliminate as many variables as possible.

7. Possess domain expertise in project management as applied to a particular field.

8. Exercise independent and fair consensus-building skills when conflict arises.

9. Cultivate and rely on extensive informal networks inside and outside the firm to solve problems that arise. Resolve issues as quickly as possible.

They identify any critical issues that threaten projects and handle them resolutely (vs. ignoring them).

10. Look forward to going to work!

They believe that project management is an exciting challenge that’s critical to success. The truly great ones view project management as a career and not a job, and they treat it like so by seeking additional training and education.

---------------------------------------------------------------------------------------------------------

Questions to ask yourself in each project as a project manager

Starting the Project (Initiation)

Are you doing a project? A project is a temporary endeavor with a specific result or objective. If your project has no end in sight and/or no clear scope, then what ever it is you’re doing may be important, but it’s not a project. You’ll have a hard time showing your team that they’re being successful.
If you’re project has no end in the next 3 to 6 months, can you split it into multiple projects?
Are you thinking about the triple constraint? i.e. cost, time and scope.
Do you have a project charter/project definition? If not, write one for your own benefit. Having a charter can eliminate many opportunities for confusion during the project.
Who are your primary stakeholders? Who are your other stakeholders?
If you have more than one stakeholder, how will differences between stakeholders in regard to the project scope, timeline, budget or deliverables be resolved? If you’re not sure, then this is a good discussion to have with them.
Do you have a roles and responsibilities chart? Who’s on the team? Who’s not on the team? If no then just create it right now.
Do all core team members understand their roles and agree to them?

Organizing Yourself

Do you have a portfolio of templates? If not, start one.
Do you keep a collection of really good project documents written by you and others? If not, start one.
How are the project deliverables, documents and notes being managed on your project? Is there one master place where things are being kept? Does everyone on the project team know this?
Are backups being done (documents, deliverables, code, etc.)? When was the last time you tested the backup? Try it today and see what happens.

Cost and Budget

What’s your approved budget? If you don’t know, how can you find out?
Who’s responsible for tracking the budget? If it’s not you, can you negotiate access to invoices as they are submitted and payments as they are made?
What’s your method for reporting spending against budget?
How much have you spent? If you think you’ll be more than 10% over budget by the end of the project, what are you doing about it? Can you get more money? Can you trim scope? Have you told your stakeholders?
Is your budget up to date?

Planning

Project Scope

Do you have a signed project scope?
Does your scope include what’s not in your project?
Is the scope written in language that anyone of reasonable intelligence can understand? Are all acronyms explained?

Risks (and issues)

Do you have a risk log or register? This is one place where you are tracking potential events which would have a positive or negative impact on the project if they were to occur. If not, why not?
Are you spending a few minutes with your team every week or two identifying new risks and working to mitigate or otherwise handle the existing ones?
Are you communicating significant risks (high likelihood, high impact) to your stakeholders well in advance so that they are never surprised?
Are you keeping records of everything you and your team plans to do, is doing, or has done in regard to the risks and issues on your project? This is extremely valuable information for use on future projects.

Schedule and Work Breakdown Structure (WBS)

Have you identified all of your deliverables for the project?
Are you including your team in identifying the steps needed for each deliverable?
Did you come up with time estimates? Did you validate them with the people who will actually do the work?

Project Management Plan

PRINCE2 (Projects in controlled environments) defines the project management plan as, “a statement of how…a project’s objectives are to be achieved.

How will important project information be collected? Disseminated? Email? Meetings? Wiki? Twitter? Casual conversation? This is sometimes known as a communications plan.
How will risk be identified, quantified, monitored and managed on your project? Will you have a risk log? When will you inform others? How will they be informed? This is sometimes known as the risk management plan.
How will changes to the project requirements or scope be handled? If there is an overall change management process, how do changes to the project relate to that process? This is sometimes known as the change management plan.
How will purchasing decisions be made on your project? How will you identify potential sellers? Will you use a Request for Proposal (RFP) process? Does your organization have a set standard? This is sometimes known as the procurement or vendor management plan.
How will team members, clients and stakeholders be brought to competency level on project’s product? Do any team members need support to complete their project responsibilities? How will training be delivered? Online? Through printed guides or manuals? Train-the-trainer? Classroom training? This is sometimes known as the training plan.
How will the solution be moved to production or otherwise delivered? Will there be a go/no go checkpoint? What are the steps? Who does what? What other groups or organizations will need to be involved? Are there time windows which must be honored? This is sometimes known as the implementation plan.
How will ongoing support be addressed after the project has completed? Who will be responsible to maintain the project’s product? Who will help with any user issues or concerns? How will enhancements or fixes be reported and incorporated? What preventive maintenance will be needed? This is sometimes known as the maintenance transition plan.
What issues are likely to arise after the product is deployed? Are there any steps which can be taken to minimize likelihood and/or severity of these potential issues? This is sometimes known as the disaster recovery plan.

Requirements

Do you have some sort of grouped requirements for your project?
Do you know when what you are expected to deliver expands? How do you handle this natural event?
Are these requirements used as the basis for design and testing? If not, why not?
Is the whole project team involved in and kept informed about the requirements? How can you involve development? How can you involve testing?

Doing the Project (Execution)

Execution is the third phase of the Project Management Life Cycle. This is where the actual work of the project gets done. This is the longest and most costly phase (or should be).

Are you keeping your meetings as small as possible? Past a certain point, the more people, the less work gets done. Do you schedule meetings for 30mins?
Do you allow people the right to opt-out of meetings?
Do you have a clear agenda for every meeting? Do you send it out in advance, include the purpose of the meeting, intended outcome, expectations of participants, content and reference info (if needed)?
Do you make sure everyone understands the purpose of the meeting?
Do you make it easy for people to participate?
Do you take notes of each meeting for any needed points?
Are meeting notes sent out within 3 days. A week? Ever? Do they include all decisions reached and tasks assigned? Are they sent to everyone in the meeting and who will be impacted?
Do you always start on time? Starting late rewards latecomers and disrespects those who arrive on time.
Do you always end your meetings on time? If not, why not?

Status and Communication

Does your status reporting communicate anything of value?
Is your status report read? How do you know?
If you have one status report, is it aimed at the level to satisfy your project team, your active stakeholders, or executives? Would it make sense to create different reports for different groups?
If you expect reports from your team members, vendors or others, are you getting them?
If you’re getting them, do they tell you anything of value? If not, how can you change them such that they are of value to you?
Do you have weekly status meetings? Can you structure them such that people can be released without staying for the whole meeting?

Testing

Are your test cases completed prior to development beginning? This can greatly shorten the test cycle. If not, are you willing to try this on a future project?
Do your stakeholders know how to conduct user acceptance testing? What are you doing to facilitate a speedy UAT?
Can you outline the testing strategy and work with them to define exactly what will be tested?
Can you agree with your stakeholders as to specifics needed for a successful UAT before UAT testing begins?
Do your developers communicate with your testers? (This applies even if you have an outsourced test team.) In the least effective software shops quality assurance (QA) and development never communicate before testing begins. Don’t let this happen to you.

Closing the Project

Close is the last phase in the Project Management Life Cycle. Here you formally close your project and report the overall level of success to your stakeholders.

Do you look at lessons learned as a means to improve future project efforts? Or rather is it a way to get justice by beating up on the guilty parties?
Can you create an open, safe place for people to give honest and sincere feedback on the project? If not, is there someone else in your company or outside who could do the lessons learned for you?
When was the last time you did a lessons learned?

Customer Satisfaction Survey

Do you ask for feedback from your customer, client or stakeholder? An example question might be, “What could have been done better on this project?”
If you ask for feedback, are both basic and loyalty questions included? An example of a basic question is, “How satisfied are you with what the project team delivered?” An example of a loyalty question is, “How willing would you be to work with this project team again?”
Would you be willing to send out an anonymous survey to your project team? Some questions to ask: What went well on the project? What could have gone better? What would improve your experience on future projects? How could the project leader be more effective?

Project Closeout

A project closeout document is a formal, signed email or one page document which officially closes the project and releases the team. Have you ever seen one? What will you do to make sure that you use one on your project?

Jankit Shah - Important notes

21 June 2013