Many years ago, when software shipped on CDs and included printed documentation packaged in a big box, I was asked if I could fix a failing software release process. In spite of the fact that a group of people spent many hours in meetings allegedly planning for each release, it was a complete mess, and our competitors were taking advantage of our mis-steps. The problem wasn’t so much the way we developed our software, but rather in the way that we coordinated all of the other activities that had to occur to get it out the door–a process that was executed by the company’s mid-level managers. Expecting a slow, arduous effort to improve our processes, I first met with each department head and created a calendar that projected when each step had to finish in order to meet a specific ship date–essentially, I built a PERT chart, but instead of a chart, I just organized the steps and dates as rows in a spreadsheet. A suspicious-looking task caught my attention–why did it take 6 weeks AFTER the product was finished to complete the documentation? I had absolutely no idea, but the head of shipping gave me the answer almost before I could finish the question! The glossy documentation covers were took a long time to print. So, over to the head of documentation. I didn’t know the solution, and, as before, the solution was immediate. As it turns out, the glossy covers were the issue: You see, they had a long print time, and, because we used perfect binding (the cover was one piece for front-spine and back) you had to know the page count to order the correct size. We were waiting for the documentation to be finalized before ordering. The solution: the documentation folks could tell us very soon after feature freeze roughly how many pages the documentation would require. As long as we were willing to accept a few blank filler pages at the back, then we could order the covers much earlier and eliminate a major source of delay.
Rather than trying to fix the process from the outside, it’s much better to get input from those who deal with the issues on a daily basis. No, this doesn’t always work–sometimes the team is lost in the woods and needs help–but first trying to solve a process issue by tapping the expertise from within became my default strategy that day.
We had another delay in delivering updates to customers who subscribed to annual maintenance. Once again, solutions were quickly identified once the problems were clearly articulated. In this case, the symptoms appeared when trying to ship updates, but most of the underlying problems occurred elsewhere in the system. In particular, although salespeople received commissions for maintenance sales, they had no responsibility to keep their customer records current. That was quickly rectified by the EVP of Sales and Marketing (I don’t normally like to name names, but this particular EVP was Frank Cicio–who, coincidentally is easily the most effective executive I’ve ever worked with).
I don’t know if anybody ships documentation anymore, but this isn’t just a war story. How did this happen? How could a group of competent individuals fail so thoroughly? Or, perhaps more importantly, what does this story tell us about how to get teams to succeed? Well, from this story, the first thing is to make sure the team knows what they’re trying to accomplish. In my case, the missing piece was a shared calendar of commitments. The important milestones were public, and the calendar gave the team members something to point to. This was my second important lesson: A team can only be effective if it knows what it is trying to do at a sufficient level of detail for the team members to coordinate their activities among themselves. OK, that last bit might take a while, but I think its important for leaders to look for ways to put themselves out of business and help the team run itself. The second is engaging team members to take responsibility for the process and its results, and actively seek opportunities for improvement. This is something I like about the Scrum software development methodology. There are lots of tools and techniques for problem solving, etc., some of which I’ve mentioned before.