Break Down Departmental Barriers in Pursuit of a Common Goal
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.
References and Resources
Managing for Quality and Performance Excellence
Deming and Goldratt
Out of the Crisis
The Deming Management Method
The New Economics
Four Days with Dr. Deming
Deming Route to Quality and Productivity
Deming The Way We Knew Him
About the author
Josh Nankivel is a Project Planning & Controls Control Account Manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. His academic background includes a BS in Project Management, summa cum laude. He can be found writing and contributing in many places within the project management community, and his primary project management website is located at pmstudent.com.
I totally agree! Hiding behind the requirements as an excuse for not delighting the customer is the coward’s way out. Professional project managers seek to determine how to create a win for their key stakeholders in spite of natural misunderstandings and mistakes in the requirements documents. Words are easily misunderstood. Commitment to doing the right thing can overcome the barriers of language. Let’s leave the excuses to the amateurs and helpless victims! – Kimberly Wiefling, Author, Scrappy Project Management Preview the Scrappy Project Management Book