The Process of Communication, A Practical Guide for Project Managers
•Télécharger en tant que PPTX, PDF•
3 j'aime•3,823 vues
On October 14, 2015, Michael Gill gave a presentation entitled "The Process of Communication, A Practical Guide for Project Managers." Communication is not about knowing the process. Communication is about managing the process. A successful project manager communicates effectively by setting and managing expectations throughout the lifecycle of a project and, by doing so, creates redundancy in a fluid industry. The importance of a simple and redundant communication framework cannot be overstated. Referencing my book, The Process of Communication, I will focus on the role of pre-production and the importance of Requirements Gathering, establishing a teams Level of Effort, communicating Assumptions and through the development of these tools establishing a realistic Timeline. I will speak about how all of these deliverables are used to manage clients expectations as obstacles arise and requirements change.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (17)
Similaire à The Process of Communication, A Practical Guide for Project Managers
Similaire à The Process of Communication, A Practical Guide for Project Managers (20)
Plus de Harvard Web Working Group
Plus de Harvard Web Working Group (20)
Dernier
Dernier (20)
The Process of Communication, A Practical Guide for Project Managers
- 1. THE PROCESS OF COMMUNICATION A Practical Guide to Project Management Michael E. Gill
- 3. Communication is not about knowing the process. Communication is about managing the process.
- 4. Setting & Managing Expectations The Role of the Project Manager
- 5. Four Laws of Communication
- 6. Four Laws of Communication “Proper planning prevents poor performance.” Dale Carnegie
- 7. Four Laws of Communication “The quickest way to get from point A to point B is a straight line.” As the crow flies
- 8. Four Laws of Communication “Procrastination is the thief of time; collar him.” Charles Dickens
- 9. Four Laws of Communication “If you don’t learn from history, you’ll be doomed to repeat it.” Your 8th Grade History Teacher
- 10. Post Mortem Business Requirement s Proposal Developmen t Scope, LOE Assumptions , Budget & Schedule User Experience Site Architecture, Wireframes & Functional Requirement s Developmen t Design, Develop & Integrate, Content Creation Deployment (Go Live) Maintenance Pre-Production Post-ProductionProduction Post Mortem (If Need Be) Interviews, Creative Briefs, Brainstormin g & Strategy Sessions, etc. QA / Bug Fixing & UAT Training
- 11. Post Mortem Business Requirement s Proposal Developmen t Scope, LOE Assumptions , Budget & Schedule User Experience Site Architecture, Wireframes & Functional Requirement s Developmen t Design, Develop & Integrate, Content Creation Deployment (Go Live) Maintenance Pre-Production Post-ProductionProduction Post Mortem (If Need Be) Interviews, Creative Briefs, Brainstormin g & Strategy Sessions, etc. QA / Bug Fixing & UAT Training Set expectations
- 12. Setting Expectations Requirements Gathering Assumptions Level Of Effort (LOE) Timeline
- 13. Requirements Gathering Document early / Document often Facilitate the solutions Cornerstone documents Give them what you need Drive requirements to completion Don’t fall into the traps!
- 14. Trap #1 “We don’t have enough time to take a month to create a requirements document. Everyone will want to see it and give us their two cents.”
- 15. Trap #2 “We’ll gather the requirements during production ahead of development.”
- 16. Trap #3 “The client doesn’t want to pay for documentation; they want to see progress.”
- 17. Level of Effort Knowing the solution The time it takes for each person to build their piece The integration of each independent piece Effort put toward the QA / Bug Fixing Loop What Assumptions need to be made
- 18. Assumptions Assumptions help to mitigate the risk involved in the unknowns Constantly inform the client of the assumptions Voice your concern about not meeting assumptions Don’t cut resources or the schedule and keep the same size deliverable
- 19. Assumptions
- 20. Assumptions
- 21. Project Planning Delivery Date= Requirementsx Level of Effort+ Assumptions
- 22. Project Planning Be Present in the Moment Don’t Take Shortcuts Work Front to Back Forecast the Future
- 23. Capacity Plan
- 24. Capacity Plan
- 25. Rules to Project Planning Every project will have obstacles Distance equals time The LOE needs input from everyone Trust & Defend
- 26. High Level Project Plan 7/8 - 26 7/29 – 8/16 8/19 - 9/6 9/9 – 9/27 9/30 - 10/18 10/21 – 11/8 Set up Environments Biz / Functional Requirements Site Shell (Architecture) 11/11 – 11/29 12/2 – 12/20 ClientsResource Library Connect with Us Home Page Program Finder (Dynamic) ITR 7ITR 1 ITR 2 ITR 3 ITR 4 ITR 5 ITR 6 ITR 8 Program Page (Static Page) Program Detail Page The Experience Application Brochure Testimonials Participants Objectives Curriculum Demo Chinese Toggle FAQs Focused Programs Custom Programs Comprehensive Leadership Programs Global Curriculum Program Structure Program Participants Participant Engagement Employee Base Primary Navigation Testimonials The Experience About Us History Locations Life Requirements Application Process Fees & Payments About Admissions Chinese Translations Breadcrumbs Insets Related Programs Campaign Landing Pages Program Landing Page Program Comparison Featured Resource Info Graphic Contact Page Brochure Finalize Back End Admin Tool Analytics Video Migration 12/23 – 1/31 ITR 9 QA / Bug Fix Design Review & Updates QA / Bug Fixing Final Updates 12/16 Cut Over Final UAT 12/12 Code Freeze Demo Demo Demo Demo Demo Demo Administration Tool Existing Content / Data Migration into new design Existing Site Freeze Support Begin Release 2 Salesforce.com Admin Tool Training Develop Taxonomy for Program Details
- 27. Post Mortem Business Requirement s Scope, LOE Assumptions , Budget & Schedule User Experience Site Architecture, Wireframes & Functional Requirement s Developmen t Design, Develop & Integrate, Content Creation Deployment (Go Live) Maintenance Pre-Production Post-ProductionProduction QA / Bug Fixing & UAT Training Set expectations Manage expectations Main Meetings Review Feedback & Approval Loop Obstacles 5 most common 3 hip pocket solutions Change Of Scope
- 28. Manage Expectations 5 Most Common Obstacles 3 Hip Pocket Solutions Main Meetings Review, Feedback & Approval Loop Change Of Scope
- 29. Managing Expectations Expectations= Project Assumptions+ Status
- 31. 5 Most Common Obstacles to Project Success The requirements keep changing or are not approved in a timely manner
- 32. The requirements keep changing or are not approved in a timely manner The scope of the project keeps shifting or growing 5 Most Common Obstacles to Project Success
- 33. The requirements keep changing or are not approved in a timely manner The scope of the project keeps shifting or growing The Review, Feedback & Approval Loop is constantly delayed 5 Most Common Obstacles to Project Success
- 34. The requirements keep changing or are not approved in a timely manner The scope of the project keeps shifting or growing The Review, Feedback & Approval Loop is constantly delayed Deliverables, such as content or third-party assets, are delayed in delivery 5 Most Common Obstacles to Project Success
- 35. The requirements keep changing or are not approved in a timely manner The scope of the project keeps shifting or growing The Review, Feedback & Approval Loop is constantly delayed Deliverables, such as content or third-party assets, are delayed in delivery Communication is not consistent, it’s broken or is missing altogether 5 Most Common Obstacles to Project Success
- 36. 3 Hip Pocket Solutions to any Obstacle You can add resources You can push the project delivery date You can move this deliverable or another deliverable to a later release
- 37. Main Meetings
- 38. Main Meetings Kickoff Meeting
- 39. Main Meetings Kickoff Meeting Daily Team Status Meeting
- 40. Main Meetings Kickoff Meeting Daily Team Status Meeting Weekly Client Status Meeting
- 41. Main Meetings Kickoff Meeting Daily Team Status Meeting Weekly Client Status Meeting Iterative Stakeholder Status Meeting
- 42. Main Meetings Kickoff Meeting Daily Team Status Meeting Weekly Client Status Meeting Iterative Stakeholder Status Meeting Working Group Meetings
- 43. Main Meetings Kickoff Meeting Daily Team Status Meeting Weekly Client Status Meeting Iterative Stakeholder Status Meeting Working Group Meetings Milestone Meetings
- 44. Rules of Thumb for your meetings Your team can’t get anything done in meetings Keep your meetings short & to the point Don’t invite the entire world Schedule Milestones at the start of the project Facilitate conversation & broker information Send out notes afterward You cannot be everywhere at once, so don’t try to be
- 45. Post Lunch Depression The act of becoming a zombie or passing out altogether after having lunch.
- 46. Review, Feedback & Approval Loop(s) Create Client Review Feedbac k Client Review Feedbac k Update Client Review Update ApprovalApproval Approval
- 47. Tweak-land A world where only creative people go and when they come back they are usually very cranky.
- 48. Changes to Scope Changes occur because new ideas arise as the project progresses All changes can be accommodated All solutions must be vetted internally first All changes need to be documented
- 49. Tracking Changes to Scope
- 50. Tracking Changes to Scope
- 51. The Hammer Someone in a senior role and who holds sway over your team, your client’s team or another party responsible for a particular deliverable. The Hammer is able to get people to focus and get back to work.
- 52. High Level Project Plan 7/8 - 26 7/29 – 8/16 8/19 - 9/6 9/9 – 9/27 9/30 - 10/18 10/21 – 11/8 Set up Environments Biz / Functional Requirements Site Shell (Architecture) 11/11 – 11/29 12/2 – 12/20 ClientsResource Library Connect with Us Home Page Program Finder (Dynamic) ITR 7ITR 1 ITR 2 ITR 3 ITR 4 ITR 5 ITR 6 ITR 8 Program Page (Static Page) Program Detail Page The Experience Application Brochure Testimonials Participants Objectives Curriculum Demo Chinese Toggle FAQs Focused Programs Custom Programs Comprehensive Leadership Programs Global Curriculum Program Structure Program Participants Participant Engagement Employee Base Primary Navigation Testimonials The Experience About Us History Locations Life Requirements Application Process Fees & Payments About Admissions Chinese Translations Breadcrumbs Insets Related Programs Campaign Landing Pages Program Landing Page Program Comparison Featured Resource Info Graphic Contact Page Brochure Finalize Back End Admin Tool Analytics Video Migration 12/23 – 1/31 ITR 9 QA / Bug Fix Design Review & Updates QA / Bug Fixing Final Updates 12/16 Cut Over Final UAT 12/12 Code Freeze Demo Demo Demo Demo Demo Demo Administration Tool Existing Content / Data Migration into new design Existing Site Freeze Support Begin Release 2 Salesforce.com Admin Tool Training Develop Taxonomy for Program Details
- 53. 7/8 - 26 7/29 – 8/16 8/19 - 9/6 9/9 – 9/27 9/30- 10/18 10/21 – 11/8 Set up Environments Biz / Functional Requirements Site Shell (Architecture) 11/11 – 11/29 12/2 – 1/3 Connect with Us Home Page Program Finder ITR 1 ITR 2 ITR 3 Program Detail Page Request Brochure Demo Toggle FAQs Focused Programs Custom Programs Leadership Programs Admin UI Upgrades / Picture Imports (Framework) Testimonials What is Inc.? History Locations Campus Life Requirements Application Process Fees & Payments About Admissions Chinese Translations Campaign Landing Page Program Landing Page Program Comparison 2/3 – 3/5 3/5 Go Live Demo Demo Demo Demo Develop Taxonomy for Program Details ITR 7ITR 4 ITR 5 ITR 6 ITR 8 Program Finder Right Rail Program Finder Widget Search – Facets Program Finder Demo Resource Library The Experience Curriculum Data Migration UAT Begins (ITR 2 – 4) UAT (ITR 2 – 5) UAT (ITR 2 – 6) UAT (ITR 2 – 7) Program Finder Salesforce.com Static Pages Outage Forms 2/19 Existing Site Freeze Cut Over Process 2/17 - 28 Planning Activities & Collection / Restore Activities 10/29 Admin Tool Training9/30 Admin Tool Training 9/16-18 Photo Shoot 10/8-9 Photo Shoot Integration of taxonomy / metadata QC of metadata / taxonomy / search Implementation of new tagging tool QC Taxonomy / Metadata 11/4 Final Content Delivery 10/25 Final Photo Delivery Mobile Search Implementation Resource Library Bug Fixes on Program Details & Program Finder Data Migration – New Fields, Import Sub Pages & Migration Script 10/22 & 25 IT Backup & Restore New Requirements Program Finder 10/15 IT Backup Restore New Requirements & Updates Based on Steering Committee Clean Up & Implementation of Share -Point Best Practices 11/1 IT Backup & Restore 11/12 - All Staff Demo New - Existing & Additional Req’s - Detail Landing, Testimonials, Etc. Complete Program Finder 1/6 – 1/31 Ongoing Iteration QA / Bug Fix on all defined Browsers ITR 10ITR 9 Demo QA / Bug Fixing Final Content Entry Analytics: Integration of Net Insight or Adobe Code Video Server Implementation ? Final UAT (ITR 2 – 8) Existing Content /Data Migration 1/21 Admin Tool Training New - Additional Requirements from Admin Tool FAQs Employees New Page - Generic Content Page – Test., Podcast, Interviews, Video Forms – Opt Out & Custom Inquiry, Lead Gen, Download PDF 2/13 UAT, QA & Dev. Cut - Off 12/3 Admin Tool Training 1/31 Final Content Migration Adobe UAT = Work that has been added since the start of development FAQ’s Requirement Updates 2/11 IT Initial Planning Mtg 3/5 Fail Over & Regression 12/31 Content Migration 1/21 High Level Project Plan
- 54. Post Mortem Business Requirement s Scope, LOE Assumptions , Budget & Schedule Pre-Production Post-ProductionProduction QA / Bug Fixing & UAT Training Set expectations Manage expectations 3 Main Meetings Review Feedback & Approval Loop Obstacles 5 most common 3 hip pocket solutions Change Of Scope Deployment (Go Live) Maintenance Deliver on expectations
- 55. Deliver On Expectations QA, UAT & Bug Fixing Post Mortem
- 56. QA “You want QA on that wall, you need QA on that wall.” Jack Nicholson “A Few Good Men”
- 57. QA / Bug Fixing Loop QA Bug Fixing QA QA Bug Fixing Bug Fixing Bug Fixing QA ApprovalApproval Approval
- 58. Rules for User Acceptance Testing You can't go to UAT with buggy code UAT impacts the Client Relationship Not all code needs to have UAT UAT may have loops as well Train the Testers on how to conduct UAT
- 59. Post Mortem Contrary to its name, a postmortem is used to breathe life into your account or the next project
- 60. Post Mortem Questionair Planning Resources Project Management/Scheduling Development/Design/Specifications Test
- 61. Post Mortem - Before the Meeting Send copies of previous postmortem results for review Send out an agenda with a list of potential topics Ask team members to send ahead issues to discus Prepare the room
- 62. Post Mortem - During the Meeting A blame-free atmosphere What went right / what went wrong Review and rank all of the issues What went wrong - stop the discussion after five minutes and ask for suggestions about what to do differently All functional groups contribute to each issue
- 63. Post Mortem - After the Meeting Document the recommendations Send notes to all attendees and interested parties Use the recommendations on future projects
- 64. Learning’s Information learned during the project that you incorporate into the process on the fly.
- 65. Deliver on Expectations Success = On Time & On BudgetSuccess = A happy client who takes ownership of the final deliverable
- 66. Thank you www.michaelegill.com LinkedIn Amazon @ Michael E Gill
Notes de l'éditeur
- Some background What got me to this point Movies - importance of resource & budget management Broadcast - Learned scheduling and timing from, Black screen in broadcast is the deathnell Gore – invented the information super highway 1994, didn’t take hold until 1996 Advertising – began process development Dot com – companies without profits failed Mobile – realization – technology changes / processes change, but project management doesn’t 2012 – decided to put it down on paper No wiggle room in live TV New channel for information
- Could be called the 4 rules of Project Management The 4 laws that I keep in mind whenever running a project The 4 rules of project management They are those reminders of what is most important to communicate when running a project Maxim’s that I use to help remind me to stay on task when beginning, running and finishing a project. Just a few reminders that every PM should have when managing a project or an account.
- Requirements Document, LOE, Assumptions preproduction and the foundational role of Project Management. Get all your ducks in a row before you begin the project. It may take a little time up front, but it will save a great deal of time in the end. Manage your team and client to do the same. The time spent in understanding not only the problem but also the solution will keep you from changing course midstream.
- timeline & assumptions Take everything you’ve learned in Requirements, LOE and Assumptions feeds into your timeline Your timeline is always pushing the fastest, most efficient way from A to B while taking into account all of the possible delays in the process. Assumptions cover your ass. Vagueness spells death to all great solutions.
- Control it Changes of scope One thing is for certain on every project: it will end. Do not leave all of the effort until that point. Meaning, don’t keep pushing out discussions, deliverables, handoffs, and other integration points, thinking that you have all the time in the world. Eventually you will run out of time, resources and money. It’s important to note here, that eating into the time allotted for QA at the end of a project is not a viable way to make up for lost time in production.
- Post mortem On every project there will be things that go right and those that go wrong. Don’t forget either experience. Adopt process improvements, fix pitfalls, and learn how to discern potential future obstacles. Learning to forecast obstacles will help you to steer clear of them on future projects. If you stick to these four maxims half your job is done. All that’s left is to manage the process and communicate expectations.
- The Communications Framework does not replace the production methodology. Rather it sits on top. I like to keep this simple so I’ve adopted a process that comes from my days in film and video production. Simply Pre, Pro and Post. Different companies separate these tasks in different ways. Some use many more phases. I’ve seen prepare turned into Concepting, strategy, proposal development. We have all those here, but we keep it simple to avoid confusion.
- Document early, so that it doesn’t need to be often. The project manager needs to drive requirements gathering to completion before development can begin. These are the cornerstone documents that you can fall back on to ensure that the project is going in the right direction It is the PM’s job to facilitate the development of the solution (not to necessarily come up with that solution). Give them what you need. Help your client to articulate their needs. 6. Traps They are the excuses that are used for pushing off requirements gathering to a later date. It’s important to recognize these excuses for what they are, Trojan horses that can take down the whole project when no one is looking.
- That’s exactly what you want. Anyone who is going to offer their two cents today is going to do it three months from now as well. The only difference is that if you wait three months to get their input you can guarantee that they will have changes to what you’ve developed and will probably be a little cranky that you waited so long to get their thoughts. If this is the case you can kiss the budget and timeline good-bye.
- I’ve never seen this work. No matter how hard people try to keep the requirements gathering ahead of development it just doesn’t work. Remember Trap 1, “Everyone will want to see it and give us their two cents.” That takes time. More time than you’ll have when a developer or designer is waiting for direction to complete a task. This tactic will most certainly extend your timeline and, if you’re working in an agency, negatively impact your margins.
- This is a fun one. Translated, this means that the client wants to come up with requirements by way of tweaking development. It is your job to make sure that these documents are created, used, and updated. These are the cornerstone documents that you can fall back on to ensure that the project is going in the right direction and to keep the client honest.
- The biggest danger is that when you develop an LOE you don’t take into account all the steps each resource needs in order to complete their tasks. Also, you make assumptions about the amount of time each person can put toward the project without taking into account some key variables. nothing can begin without knowing what the problem is. To build a solid LOE (Level of Effort) you need to start with the requirements. A lot of the time you will be asked to develop this without much knowledge of the solution or even the problem. When building a Level of Effort there are two statements that rule the day. “Fool me once, shame on you. Fool me twice, shame on me.” and “Trust but Verify.”
- assumptions are contingencies, risks and obstacles – that need to be addressed in order to finish the project successfully. Assumptions help to mitigate the risk involved in the unknowns. If your project has contingencies, but you don’t inform the client of them, it is your fault when they hit. If you have a schedule that is too tight and you don’t voice your concern, then it’s your fault when you miss your deadline.
- Remember: Assume the living daylights out of your proposal, timelines, and anything else that has variables against the success of your project. Assume early and communicate often.
- We need to constantly track the changes to the assumptions and have a constant dialogue about them and their impact to the budget, the schedule or the deliverable. Note of Caution: We all want to do what’s best for the client and for the project and sometimes we make exceptions around deliverables, timing, and resources whenever possible. You don’t want everyone to become complacent and to think that the history of making concessions dictates the acceptance of future requests. Exceptions are not the rule.
- “Live in the present” - keep your team focused on the task(s) at hand. 2. Working “front to back” is all about the schedule. follow the project plan that you put in place. The timeline you have in your hands was created with the involvement of everyone on the project team. The project plan is set up in a way that handoff’s can happen seamlessly and in stride. We do this knowing that timelines shift all the time, but the overall substance of the plan usually stays intact unless you come across a major Change of Scope. The timeline is your canary in the coal mine. 3. If you keep your team focused on their tasks at hand and keep to the schedule, you will be able to forecast your status for tomorrow, next week, and next month, in short, the future. You’ll be able to forecast whether you are going to hit a handoff next week or a release date six months down the road. Based on this knowledge, you can adjust and communicate. Manage expectations! 4. Don’t take shortcuts. In production, shortcuts only extend the process. When I say shortcuts I mean to say, doing something half-assed, because you don’t have the time to complete the work correctly, or skipping reviews with the appropriate people. Shortcuts in any phase will throw a curveball at you when you least expect it.
- In Project Planning you will need to know the time capacity of each team member. Without this knowledge you are creating a false plan. I use a simple spreadsheet to help calculate the team’s capacity.
- It’s remarkable how much less time each resource has after you calculate this equation. Capacity drives the amount of work that each person on the team can handle for that project. Once my capacity sheet is complete, I take that information and use it to fill out my project plan False Plan
- Common Sense Every project will have an obstacle. Most will have many. The estimates you are given won’t take this into account. must also be taken into account when translating the Level of Effort into a schedule, which of course will be questioned and torn apart by everyone from the account rep to the client himself. Distance equals time, especially when it comes to scheduling, but also when it comes to waiting around for receipt of a deliverable by a guy who doesn’t get to the office for another four hours, which is when you leave. Down the line, the LOE needs to have input from everyone. Foundational doc
- Initial timeline based on reqs, loe & assumptions We’ll look again at the end.
- Now that we’ve set expectations in the form of requirements, loe, assumptions and timeline it’s time to move into production. A lot happens here, but I’m going to pull out a important steps that help with managing expectations
- What we do as Project Managers is set and then manage expectations. The assumptions we set are our initial set of expectations. Then we learn whether those expectations are going to plan in daily status.
- Hanging over my desk We as project managers need to understand that not everything is in our control There will be obstacles thrown at us on every project These tools help to control the obstacle – forecast them, as much as possible
- It will be very difficult to get the project off on the right footing Often a PM is forced to kick off a project before all the necessary information is gathered. This is a dangerous proposition that impedes your ability to set the proper expectations.
- You should go into every project expecting that there will be changes in the scope. There may be nothing a PM can do to keep a project’s scope from shifting. The first way to prepare is to build a solid proposal The second is to constantly manage expectations with the Three Hip Pocket Solutions to Any Obstacle. I’ll speak to these three standard responses in a few pages.
- The Review, Feedback & Approval loop is one of the most difficult processes to manage in all of Project Management. In order to combat obstacles you need to work intimately with your client to understand who needs to be involved and how many touch points those people will tolerate. You cannot set abstract meetings without purpose and you need to tightly manage every meeting. If anyone feels that their input is not necessary or they don’t see value in the meeting it will be hard to get them to come back for more.
- Often you will need to rely on your client or separate vendor for a third-party deliverable. Most often it’s something as benign as content, but it can be software, a decision, designs, or something else. Whenever a deliverable is outside your control it’s important to account for this potential delay in your timeline and assumptions. One of the biggest mistakes - is making the assumption that all handoffs will happen on time. You should always account for the eventual delays in third-party deliverables by scheduling them to be delivered at least one week prior to integration.
- Project managers own communication
- There are 3 simple solutions to all of these obstacle. This list is in your hip pocket, but not designed to replace any great ideas that your team comes up with. It’s there to start the conversation. You can add resources to help overcome the obstacle and to help the team get back on track with their deliverable. Throwing more bodies at the project only goes so far You can push the project delivery date out in order to make up for lost time. domino effect of how one missed deliverable pushes the next out and so on. It’s often not a day-for-day slip as it is often mistaken to be. You can move this deliverable or another deliverable to a later release in order to keep to the existing schedule you need to be careful about suspending a deliverable that may have an impact on another piece of functionality, design, or business need. An amendment to this solution would be to scale down the deliverable in question for the first release with an understanding that it will be enhanced post-delivery.
- An agenda is necessary for all meetings so that people know what they are getting into and what is expected of them. Creating an agenda will keep everyone on task and will keep you from biting off more than you can chew. If you’ve set a half-hour meeting with an agenda of ten discussion points, you can see that won’t work.
- The project kickoff meeting is a foundational meeting and consists of: Requirements, LOE, timeline, assumptions? The RACI, What are the next steps? After the kickoff you should be able to run your project with a set three meetings:
- What did you do yesterday? What are you doing today? Is anyone blocking or gating you? Don’t be a spectator during status. Each day take notes and send them to the team as a reminder of the expectations that have been set.
- Macro – daily status Discussion Points - Obstacles / Issues / Major Decisions
- 4. An iterative review with the stakeholders. More macro Project Status Recently Completed Work Demo Specific Technology, Design completed in the Sprint Discussion Points Work for the Next Iteration HLP Major Decisions Do you see a pattern forming? You are discussing the same information over and over, each time at a more macro level. Daily, weekly, and iteratively. It’s not rocket science and, more important, you are not reinventing the wheel for each meeting. As a matter of fact, there is less information as you go from day to week to month. Make sure that your communication is consistent across all media and meetings and that the level of information is appropriate for the audience.
- 5. If these meetings generate larger or more in-depth conversations, book a separate working group and make sure that the meeting has a problem or issue to solve. Determine if solutions can be made with a quick conversation in the status or if a separate working group meeting needs to be arranged. If an additional meeting is needed, determine who is in charge of the meeting and when it will take place. Don’t be surprised if you are asked to be in charge. That’s your job. Don’t schedule a working group meeting that covers more than one topic. Once the separate working group is scheduled don’t allow the team to rehash the obstacle. If this is the case, take control of the meeting or you might lose it altogether. Remember this is a status meeting not a working group, and it’s your job to keep it running efficiently and on time. You facilitate solutions and are not just a secretary, simply there to take notes. If you are in charge of a meeting, then you are the facilitator. An agenda is necessary for all meetings so that people know what they are getting into and what is expected of them. Creating an agenda will keep everyone on task and will keep you from biting off more than you can chew. If you’ve set a half-hour meeting with an agenda of ten discussion points, you can see that won’t work.
- Review approval feedback loop UAT kick off Post mortem
- All you’ll need is the trifecta of status meetings and you won’t need to add many other meetings to this list. and as few as possible and you will have a very happy team surrounding you. That is a mistake that junior managers make all the time; they don’t have the confidence or the desire to make decisions without consensus. Only include the few people who are necessary for a working group. However, you shouldn’t be involved in every meeting, decision, or deliverable. I’m a big fan of letting people communicate directly. There is less room for interpretation. Let your leads do their jobs and update you at morning meetings. Don’t set your e-mail to accept every meeting that you are invited to. If you can’t make a meeting, don’t let others think that you will be attending. Manage your calendar properly.
- No 9am No 12 noon No 5pm
- Miss-manage this a lot as PM’s We tend to schedule this as the best case scenarios They’ll want to give feedback on your interpretation of their feedback. it’s all about communication and setting the appropriate expectations. review and approval meetings should be scheduled in advance so that you can get on the stakeholders’ calendars. If your client takes responsibility for inviting the stakeholders, track the progress of this task like any other. Once in the meeting, make sure you set the expectation on how and when feedback is to be delivered. Creating urgency is the goal of this conversation, but don’t harp on it. In the end you should run a tight meeting. deliver the assets at least a day in advance. Ask the team to review the assets and bring questions and feedback to the meeting. Let them know that you respect their time and a quick prep will help facilitate discussion.
- You can see how the Review Feedback and Approval loop and spin out of control. This can be a client initiated, but also there can be an internal spin I like to call tweak-land.
- If you have: set & managed expectations kept the client & project team informed of status and kept your solutions hat on all the time …you should not be forced to burn your team out every time there is a change to the scope of the project. Resources Time trade deliverables
- Introducing a simple matrix may help the client to prioritize which new functionality is a necessary “must have” and which is “nice to have.” If the client decides not to include some of the requirements in the current release, the matrix will help keep track of anything that will be developed later on down the road. It helps with the convesation
- First, it helps to scope the additional effort by keeping all of the requested work in one place Second, it begins the conversation for the next project or Change of Scope. If you feel more columns are necessary for your project, then you can add them. The names of the Resources The Level of Effort for each resource The corresponding Assumptions Use the same Priority definitions used for bug fixing, It’s important to note that most of these tools are just that – tools – and are not designed to win a beauty contest.
- Post is often treated like the ugly step child of production
- Miss-manage this a lot as PM’s We tend to schedule this as the best case scenarios
- This is one of the many milestones in a Projects lifecycle client relationship management is magnified. UAT may have many loops as well.
- The most important step in a projects entirety is the post mortem. Most often overlooked step and I'll argue the most important meeting, you as a project manager run.
- Before the Meeting Send out copies of previous postmortem results for review, if there are any. Ask team members to send ahead issues they would like to discuss at the meeting.
- After the Meeting Send written notes on the discussion Be sure to refer to the recommendations in future project meetings. The key is documentation and follow up.
- After the Meeting Send written notes on the discussion Be sure to refer to the recommendations in future project meetings. The key is documentation and follow up.
- After the Meeting Send written notes on the discussion Be sure to refer to the recommendations in future project meetings. The key is documentation and follow up.
- When do we ever complete a project with the schedule that we started with or with the same scope as originally planned. PMP definition I look at success in a different way.