Last month, Northern California was ablaze! 1200 wildfires burning – most due to dry lightning, some unfortunately from arson. We went out anyway, spending weekends dawdling on the delta, in an anchorage with our powerboat tied up next to our friends’ big new sailboat, the sky smoky, the sun reddish through the haze. We should probably have been inside a house with the windows closed for our health! It was apparent to everyone in Northern California that we have both smoke and fire here

But sometimes the smoke is hard to see even when there’s fire a brewing. Maybe the smoke is just a wisp or the fire is smoldering under wet ashes and everyone just thinks it has been extinguished.

It’s similar with software management. How can you be sure you aren’t missing the signs of your project going astray? Problems brewing under the surface.

The best way is to focus on your customers and how they perceive your company and your product. The old adage “The customer is always right.” is a good barometer for gauging how your company and your product are doing. Is there smoke spewing and you are not paying attention or is it smoldering and hidden but underneath the surface?

Almost every company “says” they are focusing on the customer and usually decisions are being made in what is perceived to be the best interest of the customer. But often we think we are working for the customer’s benefit but we’re missing some key points. Are we focusing on only one aspect of what they want yet not delivering what they really need?

For example, how often have you heard a project team say “The customer’s schedule for delivery is on July 7^th so we had to freeze the design last week to meet their schedule.” But is the design that was frozen going to meet their needs? Is the code that is being delivered going to best solve their problem? What if the design team was stymied with how to meet the requirements. Should the team just go ahead freeze the design, code and then deliver just to meet the schedule? Where is the trade-off between quality and schedule? Maybe delivering whatever we can in the required timeframe avoids the big explosion, the blow-up that would occur if the project manager had to tell the client that they can’t meet their schedules. But it doesn’t change the fact that there’s smoldering embers underneath the ashes and eventually when the wind blows (when the customer starts doing their final testing) those smoldering embers will erupt in flames. When the software is delivered but it doesn’t meet the requirements, there will be fire. The best managers will be willing to take the heat and tell the customer up-front if the team can’t meet the schedule. Of course, the underlying problem – why the team thought they could meet the schedule but then missed their target – needs to be examined and rectified so the problem doesn’t happen again. But if the team typically estimates well and is able to perform, but for one project there is a snag, then the customer isn’t served by focusing only on one element of the delivery, the schedule. Quality always has to come first. In this case, “quality” means delivering the software which meets the agreed-upon requirements, requirements that truly meet the need from the customer’s perspective.

Project Managers need to continually scan the horizon for smoke that indicates a fire about to erupt. A project manager that declares milestones complete without actually completing the work is always a sure danger sign. Schedule versus quality is just one example but one that seems to occur far too often in real life.