Who's schedule is it anyway?

Delivering new products on schedule is always difficult. At a recent Agile Software seminar, someone asked the crowd if they had ever had any home remodeling done. A lot of people raised their hands. Then she asked if it went according to plan; very few people raised their hands. The point she was making was: if something as well understood as remodeling can't go according to plan, what makes us think that we can do something that has never been done before, and predict the future outcome?

What can you do if your schedule is dictated? This happens in many or perhaps most organizations, and it's not going to change anytime soon. But you can manage it.

I remember an executive who once told me: once your organization gets to a certain size, you are expected to just figure out how to make the dictated schedules work. Whether this is successful or not depends on what percentage of your responsibilities has this attribute. If schedule is the number one requirement for 10% of your work, indeed, you should be able to manage it. Somewhere between that ideal and 100%, you will hit a wall unless you have a method to deal with the unsolvable problem.

I advocate for a highly transparent system to communicate the decisions you are going to have to make. Specifically, you really only have a couple of variables to play with to meet the schedule: resources and function (some people will say quality too is a variable -- depends on your environment). You may need to decrease function or adjust schedule in another area to free up resources to meet the schedule on a higher priority project. The transparency depends on your ability to rank the projects in a way that meets the corporate strategy. You will need to articulate and defend the priority of each; depending on the number of items, you may need a spreadsheet and a numerical method for ranking that can easily be explained. Once you have the ranking, you can justify hurting the lowest priority projects in function or time in order to fund the highest priority projects.

This seems self evident as I write this, but in practice it can be really hard to do when the project you are hurting is going to affect someone else's bonus. Once ranked, socialize the ranking before adjustments need to be made, so that your decision criteria has been vetted before you need to hurt someone's favorite project. To be really transparent, make sure the stakeholders of those lowest priority projects understand the risk involved.

Software Product Lines

I decided to cover this subject since the December issue of Communications of the ACM is dedicated to the subject matter. I first got introduced to the terminology last year when I was talking to a San Diego employer, who was looking for management talent with this skill set. I didn't find much information on it then, but bought a (largely boring) book on it.

If you haven't heard of it, it's kind of the holy grail of software development. What if we could stop re-implementing stuff, and use the stuff we have already invested huge money and effort into making correct? People talk about re-use all the time, but it really doesn't happen significantly in real life. So we pay our employees to solve similar problems over and over again. Extremely inefficient. I've long been a proponent of solving this problem... imagine what it could do for your quality alone. Can SPL really solve this problem?

I don't yet know the answer to that question. A significant amount of information comes from the SEI at CMU. In particular, check this out. Google of "software product line methodology" turns up a bunch of references. Maybe I didn't do it right last year, but it appears that the methods have a lot more traction now. CMU is even offering a certificate program in it.

The articles in the December Communications of the ACM were mostly written in academia. One was written by a leader at Nokia. I mentioned that a San Diego employer is changing their organization and development practices to embrace SPL. It must have enough evidence of success to be worth it, or maybe it's just another management fad. The challenge is that it takes additional work to break your products into product lines; different practices, organizations, processes, roles, etc. The initial change will be hard, and even after that there is an investment hurdle to get over when determining new product lines.

What the methods still seem to need in my mind, is a good grasp on the future. I am dubious about the abilities of the average organization to do a good job at that. I suppose applying it to the cash cows makes sense, except that by definition they already exist, are stable, and making money. So to change it you have to believe you need to make significant additional change, or maybe your current software inventory is too hard to change (either in development effort or product stability).

I believe this method is applicable to larger organizations with good Voice-of-Customer (VOC) data. If you really know where you have to go, you may be able to make the right investment decisions to create software product lines.

Sustainable Advantage

Because I am such a fan of innovation, one of my former bosses once chided me, saying: "The only sustainable competitive advantage is execution". The context of the discussion was about Apple Computer's innovations, and whether they were innovating or simply producing ... well .. art. This quote from fastcompany.com inspired the conversation:

If your cool new thing doesn't generate enough money to cover costs and make a profit, it isn't innovation. It's art.

That article, written in January 2004, may have to eat its words because Apple has proven to be an impressive execution engine. Two incredible examples in my opinion are completely switching over to Intel ahead of schedule, with great quality, and changing the way music is distributed and sold. These are really hard things to do, and they executed amazingly well. It didn't hurt that the products are world-class cool, but what gets lost is how those great ideas could have been simply ideas. The difference is they set audacious goals and then they executed.

That's a long introduction to what I want to talk about, which is taking a fresh look at your business from the standpoint of execution. We complain about how offshoring is making things so difficult, how technology and open source and infrastructure has enabled a lot of competition. Yet we rarely take a disciplined, open, introspective look at our value chain and ask "why" at each step. If we did so regularly, as part of strategic reviews, we could deliver better products faster to customers, increasing customer satisfaction and our brand's reputation. In the process we can literally crush the competition, and then we get to call the shots instead of constantly reacting.

You can use tools from six sigma and lean, to evaluate what you are doing today, where your value is created, where effort is expended for little or no value, and where inventory queues (not necessarily physical inventory) prevent faster flow of value creation. The objective is to get objects through the value creating engine faster, spending enough administrative oversight to ensure the process is working in terms of quality. To do this, you have to start measuring, and that might be difficult if your organization doesn't want to do that extra work. I advocate you start by creating a value chain map so that at least you know what you want to measure and have enough information to make a compelling case for why the organization should do the work to collect the data.

I want to mention, you don't have to fear six sigma. You can use the tools without making the whole organization embrace it as a normal part of their operations.

If you can get that far, and can ensure the integrity of the data, the rest should go a lot easier. You'll still need to involve stakeholders every step of the way, who may feel threatened if something they currently do is no longer necessary. In the end though, you should be able to bring everyone together if the improvements fit into your overall strategy. Using the data, the tools, strategy, communication, and change management, your company too can be a world class value producer.

Innovation and middle management power

Rosabeth Moss Kanter wrote an article for Harvard Business Review in 1982 that was reprinted in 2004, entitled "The Middle Manager as Innovator". She points out that middle management drives changes that increase organization capacity.

Among the many things she says that I agree with, she talks about how lack of power in these ranks can interfere with the innovative process, because it inhibits collaboration. When power is unclear, unfocused, or unevenly distributed, managers are more concerned about protecting their turf than collaborating for the greater good. The successful middle manager in these environments uses their power to persuade their peers to support their cause. This is the good side of politics, influencing others to accomplish the greater good. In order to be successful at doing things out of band, almost surely these managers will need extra resources, and that will likely come from the manager's peers, and he or she must have a little support from higher up to prevent a veto from stopping the project.

One of my coaches pointed out that in order to make things happen, you have to have the right combination of Power, Influence and Authority. The required mix depends on the particular objective. I think in Ms Kanter's article, some times she is talking about influence and authority rather than power. Influence is the ability to change someone else's direction based on a number of skills including communication, persuasion, trust, vision, etc. Authority is that property which is granted to you by someone who has higher authority - it is what the manager is officially allowed or expected to do. Power is the ability to inflict consequences, good or bad, on others.

I have worked for companies where collaboration was really difficult, and I think that it was the lack of power anywhere in the organization that was a key cause (when this is the case, authority and influence must play a larger role, leaving things unbalanced). Some of my peers an I analyzed what it was we were actually empowered to decide. It was almost nothing, limited to who gets promoted and how much to compensate them. This was an intentional part of the culture, Darwinism. One influential leader told a group of new managers, "If you want to get something done, don't ask for approval, just do it". This was felt to foster an innovative environment, and in older times it worked. But when power is fleeting and temporary, and everyone is trying to make their own project successful, you will see very little collaboration.

Collaboration is key, in my opinion, to long term success and market leadership with innovation that improves not only what is delivered, but how. To accomplish that, make sure your middle management is empowered.