10 DOs that we DON’T in Project Management

I recently led a team on a four-week mini-project to conduct an independent research study on the art of project and program management across four sectors within the African market.

I must say that the result of the study is both interesting and surprising.

The study uncovered many actions by project managers that don’t align with the best practices project management. I have compiled the top ten “DOs that we DON’T.”

1. Project Charter

The Project Charter according to PMI is the document that among other things announces the existence of a new project or project phase. The project charter identifies the project manager and sponsor and authorizes the project manager to commit the resources of the organization to project activities. Best practices indicate that projects should not start or commence without a Project Charter approved and signed by the sponsor, but I found out that 98% of projects have no project charter. Lack of formal approval for the project is saddening and begs the question, “On whose authority are you running the project?”

The Sponsor might have the time and competence to write the project charter, but the responsibility is delegated to write the project charter to the Project Manager in some cases. Either approach achieves the best practice outcome of having a formally signed project charter.

2. Project Governance Structure

As a best practice, having a clear project governance structure identifies the responsibilities of decision-makers, escalation paths for critical issues and risks, and change control. You can understand how dumbfounded I was, after analyzing the result of our study to find that over 90% of projects do not have a Governance Structure. 

Most Projects had no Governance Structure, Change Control Board or Steering Committee. Who then provides direction for the project? It is hard enough to get people committed to a course. Not having a leadership and governance structure will only kill the project.

3. Physical Sign-offs

People often forget things. Desires and needs change for a project because of so many different things happening on inside or outside of the project. Best practice teaches us to always obtain physical sign-offs on deliverables such as Design Concept, Requirements Document, Project Plan, Change Request, and other critical project management documents. Surprisingly, many projects used verbal approval even though historically verbal approval has been shown to be less effective than a physical sign-offs.

4. Proper and Adequate Scope

Project scope is the foundation of project planning. It informs all sponsors and stakeholders of the boundaries for the project. It includes deliverables, features, and final products. Our study revealed that many projects do not have an adequate and proper scope document. Even in the Agile methodology, there are user stories which outline the scope of the sprint and combined with the Product and Sprint Backlogs that detail capabilities that remain to be delivered. The lack of a specific Project Scope Document often resulted in scope creep which at the end of the project led to budget overages, unapproved product/deliverables, and schedule delays. Allowing an incomplete or missing Project Scope document to exist without challenging it is setting up the project for failure and akin to digging the project’s grave.

5. Project Management Plan

A Project Management Plan is like a manual, blueprint, and compass for managing the project. When asked for the Project Management Plan, a high percentage of the PM practitioners responded with a project schedule developed using Microsoft Project, Primavera or Microsoft Excel. A project schedule only speaks to timelines, tasks and resource assignments. A project schedule does not include a communications plan, risk management plan or other critical planning documents the govern the project, and its processes. A project management plan does not have to be bulky, but it must capture the approach towards managing all the components (scope, cost, communication, risk and issues, quality, resources, stakeholders, change, and integration) on the project. Lots of practitioners did not create a project management plan for their projects.

6. Risk Register Update

A risk register or risk log is similar to the project management plan in that it is a living document that is continually updated. Although few practitioners managed to create a risk register or risk log, they did not update it regularly. Good practice is to have an agenda item at every project meeting to review the risk register. It baffles me how the risk register becomes a one-off document that is created once and abandoned considering the highly unstable project environments.

7. Verbal and Written Communication

Best practice Project Management recommends that we explore and plan for both verbal and written communication with a strong preference for written communications. Our research indicated lots of practitioners do either and not both. Of interest was a category of people that responded by saying they usually utilize verbal communication via telephone calls or hallway conversations but never followed up those discussions in writing with an email. If you have spoken to a stakeholder and a decision was on a project, it is best practice to send an email after the verbal conversation to recap the decision.

Most people send emails without asking for acknowledgment, or without sending an acknowledgment. Communication on projects and in life is a two-way process. When sending emails with some information, always ask for acknowledgment and feedback. When you receive an email, endeavor to send receipt acknowledgment.

8. Deliverable Review

The lack of Deliverable Reviews is particularly worrisome. I recently completed a strategic project where an outsourced tech-related component was sent to a vendor for the component construction. I lost count of the number of times the vendor indicated the component was completed only to find on review many errors and defects. Moreover, at those times I was thinking to myself like “Didn’t these guys review these features before sending out communication?” You can imagine how embarrassing it would be for your client to point out a seemingly obvious defect out to you on your project. Unfortunately, most practitioners do not conduct adequate reviews (or testing if you will) on accepting deliverables before communicating to clients. Keeping error away from customers is a good practice to increase the trust in the project’s ability to deliver with quality.

9. Lessons Learned

As a best practice, the Project Manager conducts a Lessons Learned session at the end of every project. Expectations are a Lesson Learned session will identify what went well, what did go so well, and identify recommendations for the next project team. In our research, over 95% of practitioners did not conduct Lessons Learned sessions talk less of developing lessons learned document. “Those who fail to learn from history are doomed to repeat it” clearly defines the purpose of Lessons Learned.

10. Project Closure

There are three potential conditions for closing a project:

1. The project objectives have been met.
2. The project objectives cannot be met.
3. The project is no longer needed.

The Project Manager has little or no control over the second and third instances. No matter the conditions for closure, the project must still go through the closure process even though many practitioners in our research did not properly close a prematurely terminated project as stated in conditions 2 and 3 above.

Bonus: Project Celebrations

Celebrating project milestones is an important team building activity. Do not skip the planning of a project celebration. Take the time to plan for project celebrations. In our research, most project teams did not celebrate after a successful project leaving the team feeling undervalued. Gather the team, have a drink, go to the club or have a party and celebrate!

In Conclusion

The objective of this write-up is not to expose bad practices but rather to awaken us and remind us of the best practices that we as Project Managers forget. Let me know your thoughts in the comments below. Are there best practices missing? What DOs and DON’Ts do you recommend?