Initiation is the first phase of the Project Management Life Cycle. In the initiate phase you define the project objectives, purpose, scope and deliverables, and get people and other resources for your project.
1. How will you know if your project is a success? Can you state the success criteria in a few words or sentences? In other words, how will you know when you are done?
2. 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.
3. If you’re project has no end in the next 3 to 6 months, can you split it into multiple projects?
4. Are you thinking about the triple constraint ?
5. 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.
6. Who are your primary stakeholders? Who are your other stakeholders?
7. 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.
8. Do you have a roles and responsibilities chart? Who’s on the team? Who’s not on the team?
9. Do all core team members understand their roles and agree to them?
10. Do you have a portfolio of templates? If not, start one.
11. Do you keep a collection of really good project documents written by you and others? If not, start one.
12. 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?
13. Are backups being done (documents, deliverables, code, etc.)? When was the last time you tested the backup? Try it today and see what happens.
14. What’s your approved budget? If you don’t know, how can you find out?
15. 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?
16. What’s your method for reporting spending against budget?
17. 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?
18. Is your budget up to date?
Planning is the second phase of the Project Management Life Cycle. You’ll set the plans needed to manage time, risks and issues, changes, quality and everything else that will be done during project execution.
19. Do you have a signed project scope?
20. Does your scope include what’s not in your project?
21. Is the scope written in language that anyone of reasonable intelligence can understand? Are all acronyms explained?
22. 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? (Email me if you would like a sample template of a simple excel based risk log.)
23. 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?
24. Are you communicating significant risks (high likelihood, high impact) to your stakeholders well in advance so that they are never surprised?
25. 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.
26. Have you identified all of your deliverables for the project?
27. Are you including your team in identifying the steps needed for each deliverable?
28. Did you use PERT (Program Evaluation and Review Technique) or another method to come up with your time estimates? Did you come up with time estimates? Did you validate them with the people who will actually do the work?
Projects in controlled environments defines the project management plan as, “a statement of how…a project’s objectives are to be achieved.”
29. How will important project information be collected? Disseminated? Email? Meetings? Wiki? Twitter? Casual conversation? This is sometimes known as a communications plan.
30. 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.
31. 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.
32. 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.
33. 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.
34. 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.
35. 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.
36. 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.
37. Do you have some sort of grouped requirements for your project?
38. Do you know when what you are expected to deliver expands? How do you handle this natural event?
39. Are these requirements used as the basis for design and testing? If not, why not?
40. Is the whole project team involved in and kept informed about the requirements? How can you involve development? How can you involve testing?
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).
41. Are you keeping your meetings as small as possible? Past a certain point, the more people, the less work gets done.
42. Do you allow people the right to opt-out of meetings? (Hint: use optional in the invite whenever possible.)
43. 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)?
44. Do you make sure everyone understands the purpose of the meeting?
45. Do you make it easy for people to participate?
46. Is there an appointed note taker for every meeting?
47. Is there a clear facilitator for every meeting? Few people are naturally good facilitators. If your meetings are generally less effective than you think they could be, what are your plans for getting trained?
48. 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?
49. Do you schedule meetings for 30mins?
50. Do you schedule (or change days and times) a week in advance except in case of emergency? (Emergencies happen once or twice a year.)
51. Do you always start on time? Starting late rewards latecomers and disrespects those who arrive on time.
52. Do you always end your meetings on time? If not, why not?
53. Does your status reporting communicate anything of value?
54. Is your status report read? How do you know?
55. 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?
56. If you expect reports from your team members, vendors or others, are you getting them?
57. 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?
58. Do you have weekly status meetings? Can you structure them such that people can be released without staying for the whole meeting?
59. 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?
60. Do your stakeholders know how to conduct user acceptance testing? What are you doing to facilitate a speedy UAT?
61. Can you outline the testing strategy and work with them to define exactly what will be tested?
62. Can you agree with your stakeholders as to specifics needed for a successful UAT before UAT testing begins?
63. Is your project susceptible to the terrors which come from the two fatal philosophical testing errors: (a) In search of the bug free release and (b) Good testing means finding the highest number of bugs?
64. 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.
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.
65. 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?
66. 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?
67. When was the last time you did a lessons learned?
68. Why not start on this project?
69. 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?”
70. 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?”
71. 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?
72. 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?
Who? What?, When? Where? Why? How?
1. Why have a meeting? What are your objectives and expectations?
2. What type of meeting do you want to have?
3. Who do you want to attend?
4. What kind of involvement and participation do you want?
5. How many people do you want? What size of meeting?
6. Where are you going to meet? How should the room be arranged?
7. What roles and responsibilities should individuals have during the meeting?
8. Who will have the power and authority to make decisions?
9. What methods and techniques of discussing, planning, problem-solving and
decision-making are you going to use?
10.How much time will you allow?
11.How will the agenda be determined? Can it be prepared and sent out in
12.Will there be presentations?
13.Will there be some kind of record?
14.What are the desired outcomes of the meeting?
15.How are you going to determine tasks, deadlines and responsibilities?
16.How will you publicize the meeting?
17.How will the meeting be evaluated?
1. If possible, plan the agenda ahead of the meeting. If very few agenda items areknown before the meeting starts, try to anticipate by thinking about the peoplewho will be there and what kind of process will be helpful for them.2. Agenda review: Have the agenda written on large sheets of newsprint or ablackboard so that everyone can see it. With the participation of the whole groupreview, revise, and list items in the order in which they will be discussed.3. Main items: If more than one item needs to be dealt with, set prioritiesa) If possible, start with something which can be dealt with easily. It will give thegroup a sense of accomplishment.b) Place the more difficult or lengthier items, or those of most pressingimportance next.c) Break a big item into several issues and discuss one issue at a time to make itmore manageable. It may be helpful to have a presentation of the item withbackground information and clarification, break into small groups fordiscussion, and then return to the main group.d) Finish with something short and easy to provide a sense of accomplishment.e) Leave time for announcementsf) Evaluation: can serve to provide a quick opportunity for people to expresstheir feelings about the proceedings and to learn how to improve futuremeetings.Estimate the time needed for each item and put it on the agenda. This will:
Copyright © 2018 NewtonGATE , NewtonGATE Solutions & Success Strategies Academy.
NewtonGATE & Success Strategies Academy with logo design are registered trademarks of NewtonGATE. All rights reserved.