Break Down Departmental Barriers in Pursuit of a Common Goal
July 24, 2007 | Author: PM Hut | Filed under: Project Management Best Practices
Break Down Departmental Barriers in Pursuit of a Common Goal (#9 in the series Deming’s 14 Points in Project Management)
By Josh Nankivel
Dr. W. Edwards Deming recently re-introduced to me in my Project Performance and Quality Assurance class. I have heard of him before and touched on some of his philosophy in other classes, but focused much more in-depth this time. The majority of his philosophy around quality and organizational management resonate with me. So, I’ve decided to do a series of articles on Deming’s 14 points, and how they relate specifically to the field of project management. I may decide to not touch on all of them or I may. I am not really sure at this point.
Many processes are cross-functional. The same is true of projects. This point is about dissolving the “us versus them” scenario that so often exists in one form or another within organizations. In most projects that I work on, there are individuals from departments such as operations, central services and other support functions, MIS, IT, Service Engineering, etc. The “us versus them” attitude comes about when project managers and project team members look at their own interests at the exclusion of others, and instead of working towards a common goal, work towards their own separate and distinct goals.
Although I have much respect for PMI and am a member of the organization, there is a statement in the PMBOK to the effect that a project is successful if the written requirements are met, regardless of whether or not the actual customer needs are fulfilled. To me, this is lunacy and reality avoidance. Project management within any organization can not be successful in the long-term if the only goal is to meet the written requirements. The goal should be to help the stakeholders and sponsor flesh out their true requirements fully, and then meet those needs. The objective of any project is to add value to the organization, period. I have been a team member on projects where the ‘requirements’ were met, and yet the end user was thoroughly dissatisfied with the results. This is not a successful project, regardless of what PMI says.
I have begun using SCRUM at my company recently, and although I was at first frightened because of the paradigm shift required of such a technique, I am beginning to like it. The general premise is that stakeholders really don’t know what they want until they can see it and work with it. SCRUM (a light version of Agile) is a way for the stakeholders to actually use incremental versions of a working prototype software, and I have already seen it’s power in fleshing out true requirements. I completely understand and realize now the hardship that stakeholders bear when trying to visualize a future state and properly articulate the requirements to get there. So far it appears SCRUM is specific to software development, but I am starting to have ideas that elements of it can be applied elsewhere to better understand the true stakeholder needs in an iterative manner.
I encourage everyone who is a project manager to not take the CYA route of “well, if they don’t put it in the requirements, it’s their fault” and instead be proactive and engage the stakeholders. If any doubts exist, do not throw responsibility over the fence, take it on yourself. A truly great project manager holds themselves accountable for stakeholder satisfaction.
Josh Nankivel is the Vice Chair of Special Projects for the Students of Project Management SIG of PMI, and a project management student/enthusiast. His website is http://www.pmstudent.com.
Related Articles
No comments yet.
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.










