Is Your Project Environment Sin Free?
July 20, 2012 | Author: PM Hut | Filed under: Project Management Musings
Is Your Project Environment Sin Free?
By Ty Kiisel
Whether you know them as the Seven Deadly Sins, the Capital Vices, or the Cardinal Sins, the final version of the list consists of wrath, greed, sloth, pride, lust, envy, and gluttony. The “Deadly Sins” are not seen as a separate category of sin, but rather the origin of the other sins. The same could be said of the Seven Deadly Project Management Sins—most of the struggles we face as project leaders originate with them.
Here’s the list:
- The Squeaky Wheel: I like to call this the, “stakeholder who screams the loudest gets what they want just because they are a noisy stakeholder” sin. Projects should focus on initiatives that provide the greatest value to the organization, not the personal or pet projects of powerful stakeholders. Organizations who spend valuable resources on projects of limited or suspect value tend to struggle.
-
Dogma Dominance: The “My dogma is better than your dogma” sin makes it difficult for project teams to approach project planning with the “best” methodology for any “particular” project. There are times when a waterfall approach to managing projects might not be the best approach. The same can be said for Agile. When a project manager’s personal preference for any particular approach dominates how he or she creates a project plan—time and resources can be wasted. The simplest approach, depending upon the requirements, is often the best. The best project managers I know are able to function in any environment, depending on what’s needed to deliver the most value to their customer.
-
Lack of Vision: It’s important that everyone involved in the project have an understanding of the ultimate goal of the project. When the vision of a project is not communicated to everyone or worse, non existent, it’s difficult for project teams to become engaged. If project leaders expect the team to treat their project like something more than “just another project,” the team needs to understand why the project is valuable to their organization. (Refer to Deadly Sin #1)
-
The focus group of “one”: As a project leader you may be smart and may really know your stuff, but let’s face it, those closest to the work understand it the best. Ignoring the input of individual project teams members is NOT a good idea. I am not advocating making decisions by committee, but I am suggesting that it’s easy to make a stupid decision by yourself. Most of the time, two heads really are better than one.
-
Seagull Supervision: I’ve seen this type of management style in numerous organizations. Have you ever had a boss who swooped in, made a big mess, and swooped out, leaving you to clean up the mess. I sure have. It’s a real morale killer for project teams who are head-down trying to get stuff done.
-
Crappy Communication: Project leaders need to be exceptional communicators. They need to effectively collaborate with project teams, stakeholders, and other executives in a style that is adaptable to each group. A one-size-fits-all approach to project communication doesn’t work. Giving a detailed project plan to the executive team is neither appreciated nor appropriate. And in reality, the project team doesn’t care about what the Gantt chart looks like either. They need to know what their contribution is and how what they are doing fits into the context of the overall project goals. Effective project leaders are exceptional communicators.
-
Forgetting Value: Ultimately the goal of every project is to provide value. In terms of either making money, saving money, or providing some other value. For some organizations ROI might not be as important as governance issues—depending on the organization and what they want to accomplish. If we forget that projects provide value, we’ve lost before we’ve begun.
I’m on a roll now and could probably keep going, but I’m going to stop at seven. What other project management sins would you call “deadly?”
About Ty Kiisel
Writing about project management for @task gives Ty the opportunity to share his personal experiences as an “accidental” project manager along with the lessons learned from conversations with customers, hopefully demonstrating that it really doesn’t matter what industry you’re in, the rewards of successfully executing project-based work are universal.
About @task
@task helps organizations focus on being more effective, innovative, and more competitive with a rich project and portfolio management solution that enables decision-makers to maximize their resources by implementing those initiatives that provide the greatest business value. @task helps align the strategic goals of objectives with the implementation and execution goals of project teams.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.





2 people have left comments
Great article. The one thing I’d add specifically regarding point number 6: I find it very true that a one-size-fits-all approach to project communication doesn’t work–within the project teams–but one thing that definitely needs to be addressed is that a unified communication method among project managers towards sponsors is a very valuable effort.
When multiple project managers overseeing different teams are communicating their project’s information differently, especially where cross-departmental projects are not managed by a single project manager, it often creates poor communication between PMs and executive teams or sponsors. In effect, two PMs, reporting differently, on two facets of the same overall project can cause a lot of problems if they aren’t at least unified in their message and method of communicating upwards. How they communicate to their teams may differ, and differ per project, but how they report upwards on multiple projects and joint projects should echo consistency and unified voices.
Great article!