Why do people oppose standardization? Recently I’ve been thinking about the impressive experience I had at a client where the organization was staffed with people clamoring for process control and standardized tools. Such a different climate from other organizations I’ve observed. This one wanted change and process!
The other day, I had lunch with a friend the other day who coincidentally shared his own challenges in trying to achieve standardized tools at his organization. “Our company rewards heroes, but how can you be one if you’re using the same tools and processes as everyone else?” His words implied that people felt their ability to stand apart from their peers depended on their approach to work, not the end result.
At the beginning of my University of Arizona class this term, one of the early statistics I provided to the students was the poor success rate of projects. If success is defined as meeting cost, scope, and schedule goals, the percentage is abysmal. The Standish Group publishes the CHAOS report, an analysis of almost 50,000 IT projects, mostly in Europe and the United States. The 2012 CHAOS reports that 39% of all projects succeeded; “43% were challenged (late, over budget, and/or with less than the required features and functions); and 18% failed (cancelled prior to completion or delivered and never used).” With those rates, it seems that using standardized tools and processes would be welcome efficiencies; anything to operate effectively and to establish one’s self as among the 39%.
Project Managers (PMs) are smart, and must recognize the advantage of delivering to customer and organizational expectations. Nonetheless, I don’t doubt my friend’s assessment of the situation at his organization. My theory about what happens is that – at his company – it is rare for the PM who wins a contract to see it through to completion given the multi-year nature of the projects and the dynamic nature of the business. PMs may feel they will not receive credit for the end results they helped achieve, but did not see through to project closure. And so, we return to the need to distinguish one’s self through the approach to work. How can this be avoided?
Perhaps less turnover at the Project Manager position would help. However, it could also be the root cause of the resistance to standardization is the same argument against standardized tests: one size does not fit all. If your organization’s processes and tools are too rigid to enable tailoring depending on project size and complexity, then the opposition may have a point. The ability to “right-size” processes and tools – while still maintaining a certain level of control, visibility, and normalization – is, in itself, a tool of efficiency that means projects don’t have to spend time on organizational requirements that only add cost and subtract time from a project’s operations.
Another problem might be that each PM sees his or her project as somehow fundamentally unique from all others at the organization. This is true, to some extent. The very definition of a project is that it is a unique, temporary endeavor to create a product, service, or result. However, the processes used to successfully deliver the project tend to be the same, regardless of the project. For example, irrespective of the size of the project, a schedule and a budget are basic requirements.
Finally, another root cause could be that PMs feel the organization assigned them to a project that is unexecutable either due to unrealistic deadlines and/or budget. Therefore they feel compelled to break the rules, create their own processes and tools to support their ways of doing business – which may be substantially riskier than company-sanctioned approaches.
So if your organization faces opposition to standardized tools and processes, how can thinking about some of the above help address the problem? What have you found that worked at your organization?