Projects change something and end. A good PM is simply a conduit for information. "A good PM never makes decisions and does no work" -
What do you have as a Project Manager to control the project How do you control the things you can't?
Identify "real" risks
Likelihoodand impact analysis
Management strategy - avoid, mitigate, accept, plan
Visibility - open issues only need be discussed
Move to resolve, through decisions or tasks
FAQs - for clients and project team
Issues per stakeholder
So, so important - identify your assumptions and the assumptions of others. Discuss a process by which you bring things in and out of scope.
Constraints and dependencies
Managing scope creep
Project executive / sponsors
Critical issue management
Delegated / managed authority
Day to day management of the project - daily happenings, reporting, analysis - are we tracking against what we said we would do?
A good PM never makes a decision - but identifies who should, and present them with the facts to make a sound decision that they can support.
PM makes no decisions
Identify decision makers present options
Format, type of information required - talk about it first with the people who want reports. Don't assume you know what they want... which can be anything from a chat by the water cooler to a 80-page trifold booklet.
Regular reports to direct report
Senior user / sponsors / Board
Coaching skills and the ability to clearly set out what you want is so important here
PM does little actual work...
Don't just meet for the sake of it - agree why to meet rather than when, and "meet by exception"
Effective meeting principles
Frequency - regular or by exception?
Starting and Ending - essential to any project. Why are we doing what we're doing? How do we know when we are finished? Was it a success?
Why are we doing this - no more than six points
Measurable business targets
Enduring change, Handover workshop, Documentation, Ongoing support
Engagement review, Success or fail, Lessons learned, Follow-ups
Tools and techniques to help plan; software such as MS Project helps here, but a word table can be just as effective.
PBS focuses on real things, tangible products - a server, a document, a piece of installed software. By doing this, we can assess what it looks like, and add success criteria.
Described products - nouns
Identify dependencies and order of delivery
Breaking the project into stages is common sense - even higher level 'phases' for larger projects.
Current stage plan
Key outline stages
Probably the most important part - who does what, and more importantly who is responsible for it. Even though they often carry the can - it should never be the project manager.
Who owns what? (different to does)
Who does what? What if they don't?
What will this project change about tomorrow? Next month? Next year? How does the organisation plan for and support people through this change.
Operational processes - what will be different?
Selling the benefits