Not all improvements require a fancy new development methodology or project management tool. Removing existing cultural and management inhibitors, while often not easy, can vault your team or organization to the next level of performance.

A couple of my favorite sayings include:

1. The problems are rarely technical in nature.
2. The product looks like management.
3. Just about any good technique will help your business, if you implement it with understanding.
4. If you have a good understanding of  your organization, there is less chance you will implement an inappropriate technique.

Phillip  Armour in his article “The Business of Software Contagious Craziness, Spreading Sanity” in Communications of the ACM, Oct 2009, tells the following story of a company president asking for a financial projection:

It is not uncommon that people in positions of power are strong-willed, opinionated individuals who are used to getting their own way. The president was no exception and his response to the figures presented was quite dramatic. After some blustering, shouting, and numerous derogatory remarks directed at the professional expertise of the financial forecasting group, he scratched out some numbers on a piece of paper and handed them over to the chief economist. “These are the numbers I want to see,” he said, “make these happen.”

Managing an organization or a project requires an individual to distinguish between which challenges are fixable by technology or new techniques and which require changing cultural or management attitudes. The first approach often appears easier. The second approach is often the most appropriate.

I’ve taken many organizations and projects and jumped them up to exceptional quality with on-time delivery by doing nothing more than helping them to do well what they were already doing.  However, to do that, I’ve often had to move management and cultural barriers out of the way.  Some examples of these include:

1. Management practice was often to have someone other than the original author of the work fix the work. It became a “common understanding” that the team was just too inexperienced and the software was just too complex, so management had a highly paid contractor check the quality of their work. (This same contractor, as it turns out, was the one telling management that the errors were because of team inexperience.) The nominal reason for giving the work to someone else to fix was that the original author had made mistakes, so someone else should be given the opportunity to do it correctly. Once we had the authors of their work become responsible for fixing their own errors, the error rate dropped dramatically. We then had many individuals who quickly became independent experts in their respective areas. The contractor went back to just being the liaison between the organization and her company’s contracts.

2.  Management expected that new products could be produced in less time than it was currently taking. While the organization had often admitted in the past that it was taking six quarters to develop a new product, management had consistently committed to new products in the four-to-five-quarter time frame. This resulted in an average delivery date of 3.5 months late, with none on time. Once we aligned our commitments with the current capabilities of the organization, we started to deliver on time with significantly improved quality. After we achieved a major delivery on time, just about all subsequent products delivered off that line were on time and got recognition from our customers for being on time with good quality. It was not the case that success required the shorter time as was assumed by management.  Instead, the ability to deliver when promised was most critical to our customers.

(For more on how we did this see Get The Project Management Tool Schedule Right!)

3. Management assumed that the adoption of a major organizational initiative would be accomplished by forming committees to write directives and processes that everyone would then follow. This had been going on in fits and starts for a particular initiative for about three years. We then substituted for this approach a small precision-guided team that visited each impacted development team. The small team rapidly educated each development team by showing them what they already did that matched the initiative and what they needed to do differently to achieve full adoption. The development teams could then implement the initiative as they saw fit for their teams. It took nine months for the vast majority of the organization to adopt the initiatives. Another nine months were required to fix the most difficult part of the organization and then to achieve official compliance.

(For more on this see Don’t Project Manage Change – Provide a Service.)

4. Everyone knew that security and operational effectiveness were inherently at odds with each other. There was a common cultural belief that we simply could not practicably follow all the military computer security requirements. The key technique we used to change this was to intercept new incoming folks who would handle security and show them what needed to be done. New people were much more amenable to doing what was asked. Over a fairly short period, due to the built-in high turnover of military personnel, we got a critical mass of folks verifiably following security procedures and still effectively accomplishing their mission.  Once critical mass was achieved and senior commanders saw that it could be done, the naysayers quickly made the conversion. The crowning achievement, spurred by another military command’s catching of a real spy, was being one of the few commands to pass a Pentagon security review conducted due to the capture of the spy.

5. Management over controlled their teams. I took over as the new manager of the IT organization. The previous manager had been forced out after a long political fight. The IT organization had a poor reputation for providing customer service and had a tendency to dictate to the internal customers what their needs were. After eleven months on the job, our most influential customer told us that he had better customer service in the last 11 months than he had in all the previous 11 years under the prior manager. I was a miracle worker, yes? Not at all.I simply allowed the IT team to do their job. The previous manager had over controlled what the team did. For example, no one on the IT team could talk with any external organization or vendor. All that had to be done by the IT Manager. Once we removed arbitrary barriers and gave responsibility and authority to appropriate team members, our customer service and relationships with external organizations flourished.

In every one of these real-life examples, the organization achieved their highest stated goals for those activities. In every case, excellence was achieved by removing barriers, both cultural and management, and allowing folks to understand and do the job as it was intended to be done. We recognized that our organization or team, as it was, could achieve a higher and often startling level of performance when significant inhibitors were removed (extolling people to work harder was rarely effective). The extra insight was that if these inhibitors were not removed and we adopted a new technology or methodology, then that new approach would often, if not always, suffer similar problems as the previously used approach.