72 Project Management Tips

Lifecycle & Methodology | By Alec Satin | Read time minutes

Have you ever been in the midst of a project or task and thought to yourself, "There has got to be a better way?" If so, you're not alone. Leading projects is a complicated business. The longer you're at it the more you can learn and the better you can get.

Here are 72 project management tips designed to help you lead your projects with skill, authority and grace.

Starting the Project (Initiation)

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 endeavour 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?

Organising Yourself

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.

Cost and Budget

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

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.

Project Scope

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?

Risks (and issues)

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?

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.

Schedule and Work Breakdown Structure (WBS)

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?

Project Management Plan

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 organisation 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 organisations will need to be involved? Are there time windows which must be honoured? 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 minimise likelihood and/or severity of these potential issues? This is sometimes known as the disaster recovery plan.

Requirements

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?

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).

Meetings

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 30 mins?

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?

Status and Communication

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?

Testing

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.

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.

Lessons Learned

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?

Customer Satisfaction Survey

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?

Project Closeout

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?

Alec Satin is a organisational expert with a passion for fixing workplaces. As a trained therapist, entrepreneur and Information Technology (IT) professional, he seeks to infuse environments with order, process and sanity. Primum non nocere (First do no harm) is his guiding principle.

Copyright © 2009 Alec Satin. Used with permission. All rights reserved.