Stakeholder & Customer Role Confusion in Projects
Projects are complex. They involve project customers, owners, champions, managers, consultants, sponsors, subject matter experts, IT personnel, and other stakeholders. The roles are supposed to overlap in their execution and implementation of the project and yet they often conflict and pursue different priorities. When the project customer is not adequately 
identified and documented, in advance, any of these roles may end up considering themselves the customer as the project progresses.
Consider the case of a widget. The project team has come together to build a widget together. As time moves forward the team decides that a project charter, Gantt chart, stakeholder matrix, communications plan, schedule, and risk register are not necessary. Everything reportedly has ‘run smoothly in the past’ on similar projects and so there is no reason to believe this project will run any differently. And yet it does.
Projects have requirements that are established by the customer. When other project roles begin to ‘take on customer attributes’ project scope creep (expansion or contraction) is inevitable. An IT team that has been accustomed to managing projects ‘by the seat of their pants’ quickly becomes self-identified as project as assumptions are left un-articulated, processes and strategies are standardized and become resistant to change, and the actual customer’s requests are increasingly denied. The widget’s requirements become increasingly shaped to meet the process and technical needs of the IT team instead of the customers who have both paid for the widget and will be responsible for using it once completed.
Most companies cannot afford this type of scope creep as customers are left unsatisfied and the ‘widgets’ designed are ill-suited for their purpose. Customers instead go elsewhere for their next ‘widget’ as the IT (project, etc.) team’s competitive advantage deteriorates and their competitors strengthens.
· Who is the customer?
· What are their requirements?
· How will the product/service be used?
· What problem does this product/service solve?
· What is not being included in the project scope/requirements list?
Companies cannot afford to confuse who the customer is. Other stakeholders may have a moral or social investment in the quality of the ‘widget’ developed but this should not override the needs of the customer. Identifying the customer’s role and their requirements up front can help your project avoid role confusion and the conflict and product requirement deterioration that often follows. Document these requirements clearly in your project charter, schedule, Gantt chart, etc.
Without these requirements specified in advance the opportunity for scope creep based on inaccurate assumptions and preferences, will likely increase.
Often a hierarchical approach is taken towards identifying what customer requirements, values or assumptions will be prioritized when other methods are better suited. Many businesses have moved away from the hierarchical approach in the pursuit of a more agile and flexible structure. These changes require an effort to break down the silos and the resistance to organizational learning that sustains previous ‘information islands’ and the hierarchical structures that support them. Otherwise the status quo, comfort zones, and outdated practices/business models will continue to drive the organization’s ability to flexibly pursue quality.
Travis Barker, MPA GCPM
Innovate Vancouver
Consulting@innovatevancouver.org
http://twitter.com/innovatevan
Innovate Vancouver is a business development & consulting service and technology startup located in Vancouver, BC. Contact Innovate Vancouver to help with your new project. Innovate Vancouver also gives back to the community through business consulting services. Contact us for more details.