When you’re boss doesn’t listen

I was recently approached by someone asking for advice dealing with a boss that won’t listen to the engineering team, and who doesn’t believe in methodology, testing or quality assurance. Statements such as “QA would just find a lot of bugs and keep us from making release dates” raised. This is a lousy place to be. The outcome is, more often that not, proscribed: The project will suffer horrible setbacks or outright failures and the engineering team will be blamed for writing poor software.

What our close-minded manager apparently doesn’t realize is that he’s got an incomplete team and, therefore, he should expect an incomplete result. You can’t build a house with just a few general contractors—you need licensed architects, electricians, plumbers, roofers. It’s the same with software—while engineering may know how to build the code, they won’t have the background in requirements analysis, architecture, project management, quality assurance, software testing, usability analysis and a host of other disciplines required for the project. Just as building a house requires a whole team, so does building software.

Unfortunately, there are no magic bullets for this situation. But I can offer some advice on a strategy that might work to open your manager’s eyes. It may not be the total solution, but perhaps it’s a step in the right direction.

When faced with similar situations (coming to a project as an outside subject matter expert, with the specific goal of “fixing” a broken environment) I often have to begin with the management team. The fact that things have gotten so out of hand is often because of an inadequate top-down understanding of what engineering really requires. The toughest battle is getting management to open their minds to the possibility that you can’t just “code it quick.”

1. Compile a significant body of statistical evidence to back you up.

You’ll find ample information available (horror stories and statistics alike) regarding “projects gone bad.” A common theme in the majority is the lack of planning and QA involvement from the start. This tends to lead, most significantly, to late deliveries and failed capability in the final product. Document a handful of projects that are similar in scope to your own, highlighting the problems and the consequences of those problems.

2. Build a cost analysis around the “projects gone bad” approach.

The most persuasive argument I’ve used with management is to show what it’s going to cost in the long run. Using your statistical information as a baseline, extrapolate what will happen if something similar occurs on your project. Figure out the cost in terms of human resources, lost market opportunity, customer attrition when a non-functioning product ships or has to be retooled, factor in the cost of re-releasing software, etc.

3. Make it concrete.

Using information compiled so far, select a few things that are going or have gone wrong in your project. Try to identify as much synergy between your project and these “projects gone bad” as possible. The goal is to demonstrate that it’s already starting to happen on your project and provide a reasonable conclusion that without a new strategy, your project is on a course to become a “project gone bad.”

4. Wrap up with cost savings.

Finally, demonstrate the cost savings if corrective action is taken immediately. If you hire the quality assurance team, carefully document and investigate requirements, invest in a task and issue management system, start taking time to follow good methodology, implement stringent unit and integration testing procedures and whatever other measures you feel are most beneficial, what will the results be? While there is often a small up-front cost, it is usually dwarfed in comparison to the cost of correcting a project that has derailed.

5. Provide a strategic plan.

Hopefully at this point your management will be open to a well-thought-out strategic shift. Now, make it even more concrete by providing a specific plan that implements the strategy. Document software, hardware and personnel acquisition costs. Itemize new procedures and outline the short-term and long-term impact to the project schedule (most likely, you’ll be talking about taking more time up front but dramatically less time in the long run). The net-net is almost always a win for management, because the long-term picture usually means lower costs and more reliable target dates.

6. Get behind the plan.

Finally, present the plan as a team. It’s important to agree, as a team, on the strategies and changes that will be implemented—and then present the plan as a team. Showing consensus and agreement goes a long way toward making your plan more credible (and of course, showing disagreement is almost guaranteed to derail the plan early). By presenting as a team recommendation, you are forcing your management to make a decision. If they disregard the recommendation, they are both assuming responsibility for disregarding their own team’s best advice and effectively stating that “management knows more than engineering.”

If you get to this stage, and management takes the “we know better than you” approach, there is probably only one thing left to do. Dust off your resume, and start looking for a better environment (and a better boss).