Arrogance

I was discussing Arrogance last week with a colleague; we noted some really smart people who have changed professions, who think they know so much more than those who have studied the profession for decades.

Peter Drucker wrote, in an article entitled "Managing Oneself":

Far too many people—especially people with great expertise in one area—are contemptuous of knowledge in other areas or believe that being bright is a substitute for knowledge. First-rate engineers, for instance, tend to take pride in not knowing anything about people. Human beings, they believe, are much too disorderly for the good engineering mind.

For some reason I assumed Arrogance was on the list of "seven deadly sins"; Wikipedia says it is not. Generally, Arrogance is something you lose with maturity; in particular with a successful management career comes an understanding that you need the views and analysis of others to be successful. But I have observed in others that the reverse is true - they have developed Arrogance as a consequence of their success.

This to me is the ultimate failure of management; if you enable or tolerate the increase of Arrogance in your employee, you have failed. It is our job to teach, by example and by coaching, that others have something to offer and it is the employee's job to seek out and discover that offering. I believe this can be taught without damage to the ego. Humor works - and is a good teaching tool.

My assumption is that many potential teachers overlook this sin if the sinner is a high performer. I suggest you never do that. We don't have that luxury if we are to stay competitive. The world is different, incredibly complex, and changing; we must respect and learn from others. Creating leaders who don't have this property can only lead to failure.

Problems and Solutions

Dr. Arthur D. Levinson, CEO of Genentech, is quoted in the Wall Street Journal today:

I have a philosophy -- I invite criticism. But don't ever come to me with a complaint without saying, here is what we might do to make it better. I am happy to hear Part A if I hear Part B.

I have tremendous respect for the man; he's built a successful business in an industry he describes as the "biggest money losing industry of call time". But I think that the philosophy he describes is one that will lead to trouble, and in any case is not my philosophy.

First off, let's distinguish between problems and complaints. A problem is a situation deemed potentially harmful. A complaint is a statement about dissatisfaction with a situation.

I contend that all leaders want to hear about problems in their business; complaints are one way a leader will hear about them. If a leader requires that a person bring a solution to any problem, that means team members will be working on solutions that individuals perceive as problems. The leader wants to be able to distinguish between real problems that are worthy of finding solutions, perceived problems that are not problems at all but perception and communication issues, and problems that are real but not worth working on. If you adopt a policy like Dr. Levinson's, you don't get to make that distinction. Moreover if it becomes part of your culture, it gets pushed down to the next level and now management in general doesn't get to understand and make that decision.

I certainly understand where Dr. Levinson is trying to go with this; it might be a necessary policy in a company where people don't step up to find solutions. Given what he says about Genentech, though, I find it hard to believe that is the case. I can see adopting the policy on an individual basis when you have an employee who wants to put monkeys on other's backs instead of solving problems; but as a general policy, I don't get it.

Measurement of Innovation

I found a reference for developing innovation metrics that I find useful. It breaks down factors that one needs to be innovative and gives suggestions for measuring those factors. Specifically, how to measure the resources, capability and leadership factors that might collectively be predictors of innovation.

Is innovation easier to measure than quality? Typically we measure what quality is not, and we assume that in the absence of proof of low quality, we have quality. This is apparent in software's measurement of defects: rate, density, resolution time, severity: these are measures of non-quality. I'm sure you've worked at places where that assumption turns out to be false. Perhaps quality itself is not measurable. Or perhaps it is simply that we can't definitely state what quality is, but only what it is not.

Can we make the same claim for innovation? If we measured a failure to innovate, would a low rating indicate a good innovation environment? It hurts my head to think about that. But it shares with quality the property that it is easier to measure what is not innovative. Whether something is innovative is subjective; there is no quantitative measure for whether it is or not. The reference above measures some things that are pretty concrete, such as the number of innovative ideas that become successful products. And I definitely agree that if you do not have enough resources, the right capability and leadership (culture) for innovation, it won't happen. At it's core though, how you decide whether something is innovative or not will have a huge effect on that metric, so I don't think the benchmarks they provide in the paper are really useful. But what you can use this for is trending over time in your organization as long as you can find some consistent way to evaluate the "innovativeness" of an idea.

Emotions

I had a new experience this week. One I hope not to repeat. The simple version of the story is that I needed $200 in cash, and ended up at one of those non-bank ATM machines. I asked for $200, it only dispensed $100, and I managed to pull another $20 out that was stuck in the output slot. This isn't what we've come to expect from these machines... at least not after we've used them hundreds of times. This was at Costco, and it happened right next to the person at the entrance door, so she knew I didn't make this up. It took about 30 minutes to figure out what to do, none of which resulted in me having the $200 I needed.

I was chatting and joking with the Costco employee most of the time. She said to me "you sure are patient", and that is the inspiration for this post. I asked her, what would be the upside of me getting impatient? If anything that would result in people less likely to help. Moreover, that would simply hurt me; nobody else will care. She understood; the surprising thing was that she expected something else. My behavior was not the norm.

So I thought about emotional intelligence, and looked up some old articles. It turns out that the behavior I demonstrated is just one of many emotional competencies which make up "Emotional Intelligence": self awareness, understanding emotional influence on objectives, staying cool under stress. I found this reference at the "Consortium for research on Emotional Intelligence in Organizations". I'm not making this up. You'd think they'd call themselves the CREIO or something. In any case it lists a variety of competencies which is significantly larger than might be intuitive. It's worth taking a look at the list and then doing a self audit to decide where you might improve.

Speaking Up

Maybe I'm a consultant because I say things when I shouldn't. Frankly, that's what you want in a consultant - you pay them to tell you the truth. There are surely engagements where you get paid to tell someone something they want to hear - probably mostly as a subject matter expert in a legal proceeding (I'm sure I have offended a lot of experts now). But really, wouldn't the world be a better place if everyone just told you what they think and feel? Perhaps that is naive.... but it's what I think.

I'm not sure exactly why people confide in me; perhaps it is because people learn that if they ask me something I will tell them what I think. I won't be offensive or suicidal, but if it is relevant, I'll answer honestly. If it is different than the party line, I'll explain the party line and it's rationale, and I'll support it and commit to it, but I won't express a point of view as my own that isn't.

James Detert at Penn State writes in the May HBR that employee's failure to speak up is a result of their risk/reward perception. Perhaps this is obvious but it means that they have to believe that saying something might result in a positive change, and that they won't be harmed by it. You can reinforce their confidence by being a change agent on their behalf -- step out, take the arrows for them, and stir things up - make something happen, even if you burn some political capital along the way. If you are successful and you shield them from any consequences, they'll use you for their sounding board. As an employee in some organizations, you might get shot for doing this. But if the change is worth making, and it's good for the organization, how can you not do it? If your organization can't do the right thing, is it where you want to stay anyway?

The other thing Professor Detert writes is that organizations develop implicit untested assumptions. I have seen this as well and it is the leader's job to seek these out and be the "myth buster". I had a management coach, Alan Perey, who was particularly good at demonstrating how to do this. It kind of goes just like a behavioral interview - for each statement made by the person you are working with, you have to decide if it is fact/experience based or the output of a model or theory. In short, is it fact, or is it opinion? And ask additional clarifying questions to hone in on that: "What evidence do you have....".

Leading the seriously talented

In high tech, we can hope that through corporate reputation, good fortune, persistence, and good choices, we get to have people on our team that are really smart. Ideally, smarter than we are. Consider the alternative: a team of people who are not as smart as their leader?

The challenge with really smart people is they do not really want to be led. I have seen this. According to an article in the March 2007 HBR, they want their leader to be smart enough to appreciate and understand their contribution, but not to outshine them. This I agree with. The article also says that they feel they are part of an external community that transcends the current organization. In my experience I have not seen this (this may be because I have spent my career with engineers). Many really smart people unfortunately focus on what they are good at and don't network enough or desire to get better at what they aren't good at. In fact the article talks about rewarding clever people with perks such as getting out of assignments categorized as "organizational rain": those things which clever people view as non-value add but are necessary to support the organization. I'll go out on a limb here and say that I think that is really bad for teamwork, and coddles rather than develops the superstar. The article goes on to say that the leader should minimize the rain; but that is obvious irrespective of the organization's talent.

I'll add that I've met a couple of basic types of clever people: those for whom recognition is a reward and gives them energy, and those who really don't care about recognition. I think the former is more prevalent but have no data to support the claim. Both types, when functioning well, want to do well. It's just a matter of whether you can add energy with recognition. Recognition doesn't have to be sappy or public, it's far more important that the leader knows what they've accomplished and lets them know it. For those for whom that doesn't work... you are on your own. You may have to ferret out those who pretend they don't want recognition -- a defense mechanism against being manipulated. Overall, in such environments, you'll do a lot more damage failing to recognize accomplishments than the other way around.

Measurement is hard

I was going to title this post "ISO 15939", but then many of you would not be reading this. However, this last week I was introduced to a measurement world I am still trying to figure out. It looks compelling, and it is related to this standard.

One of our challenges is convincing people that they should expend the effort to measure something. One of the books on this subject I like is entitled "Practical Software Metrics for Project Management and Process Improvement", by Robert B Grady. In the book he describes how you use the "Goal, Question, Metric" paradigm to choose what to measure. Using this method you first state what it is you are trying to accomplish, then what questions you would ask to see if you are accomplishing that goal, and then decide how you would measure the answers. Very simple, in fact, practical. The book is full of lots of examples too, and it's dense, and to the point.

Fast forward to this week. I had the pleasure of listening to Rick Hefner, PhD, Director of Process Management at Northrup Grumman, talk about measurement and CMMI. He referred me to http://www.psmsc.com, which I'm still trying to wade through. It seems based on similar principles. PSM is a web site for Practical Software Metrics. The book by a similar title was written in 1992, and this organization has been meeting on a large scale since 1996; yet I had never heard of it; hopefully that's just me and this is old news to you guys. The book was written based on experience at Hewlett Packard. The PSM web site and group was sponsored from DOD and the Army (this may be why I haven't heard of it). But ... bear with me, it looks flexible, not DOD-ish.

I'm sure a number of you will react that we just need to use agile practices, work hard, and hire good people and forget measurement. I'm sorry, but I won't ever agree. You can't improve strategically without measurement, because you don't know what to improve, or if you actually did improve. If your product and work life is perfect, your customers are always happy, you never miss deadlines, you have more revenue and earnings than you can count, and you have fantastic work/life balance.. then fine, maybe you don't need measurement. If you have that environment, call me - I'll work for you. Otherwise I think you should check this out, just to know what it is and see if there are tools here for you. And by the way, eXtreme Programming advocates metrics - you have to measure the number of stories built in an iteration. So please don't tell me I don't get it.

There are a number of extensive white papers on the site, dealing with subjects such as how to measure your process improvement efforts, and measurement of security properties of systems.

They have a piece of free software (PSM Insight) that will help you with measurement that conforms to iso15939. I haven't run it yet, but was viewing their online demo and it looks useful. One could argue it's simply a graphical tool for your data, but it seems to also get you to conform your data in a way that uses industry standard metrics and indicators, so that others can understand you better. I would be interested in any comments from people who've used this tool.

Bottom line: check out http://www.psmsc.com

Praise is getting harder

The Wall Street Journal yesterday did an article on younger workers' need for praise. (You'll need an online subscription to read the article).

The article claims that popular self-esteem-building parenting and coaching techniques have created a generation for whom a lack of continuous feedback feels like rebuke. The abundance of praise may have led to the formation of a cadre of narcissists. Moreover, in the race to provide such praise, praise words get inflated - "nice" and "smart" are no longer complements. What you think may be praise might not have the desired effect.

The article mentions communication that many of us are probably more familiar with - if nobody is yelling at you, that's a proxy for communication of satisfaction with your performance. That strategy will fail with many 20-somethings and you will be burdened with filling a vacancy. On the other hand, inflated praise may seem disingenuous, even to the receiver. Bottom line, praise is getting harder.

The article talks about how to give feedback in such cases; a lot of younger people may completely ignore candid feedback, because they are used to being told they can do anything if they believe they can. Steve Smolinsky advocated using language like "It's not as good as you can do", a compromise with some lack of directness.

All of this language is counter to a lot of how I have been coached and treated in my career. I'm certainly not advocating being mean, but if you are disappointed, the discussion has to happen; you may not understand all the factors, and very likely your employee doesn't. Clouding this discussion with praise may fail to get the point across. With practice, you can give someone feedback and show that you want them to be successful at the same time, without confusing it with ego-boosting messages. What this article says though, is that may not be enough. Perhaps you can use another technique they mention for relationships - give five times as much positive as negative feedback (but do it at different times).

Bottom line, this probably isn't new - you should already be thinking about how different people react to different forms of praise and feedback. What is new, to me at least, is thinking about it as a assumption based on age; it will require observation to see if the theory matches your reality.

Develop, Support or Punt?

As a leader, having identified an individual's lack of skill in a particular area, how do you decide whether to try to develop the skill, simply provide support from someone else in the weak area, or move the person out of the role or team? After all, it's the leader's job to remove roadblocks and provide support, right? When does support stop being a good thing and start being a problem?

I don't think this situation has a general answer. The only sound bite I have is that if the lack of skill could demotivate the team, then unless it can be remedied quickly, the person lacking needs to be removed. For example, if a person simply can't tolerate their design being reviewed, maybe they shouldn't be doing design; that in turn might have significant consequences for the individual, but the leader must consider the health of the team first. This is hard to do if the person has some other skill that is very helpful to the team; but it's not enough if it could take the team down.

Another class of skills are those that are required to perform the minimum requirement for the job. In such cases, supporting the person rather than developing the skill will be demotivating for the team. So for example, if the person cannot write clear documentation on their interfaces, but that is a requirement for the job, then allowing the person to be weak in this area by assigning it to someone else is not supporting them - it's enabling them to evade responsibility. The person may be a superstar in some limited ways, but if they can't do all the required steps in the job, they need to be fixed or removed.

After that it gets a little fuzzy. What if your superstar designer and implementer just can't negotiate? She gets nervous and clams up when she should be discussing who should do what... and she really hates negotiating. Should you overlook the shortcoming, try to fix it, or let her go? (Assume that this is not an essential part of her job, so letting her go isn't the right solution). She might quit if you push her too hard, but you know she could be so much more if she had this skill. I advocate you tell her that; your opinion on how much more capable she could be might be enough to overcome the fear. If she's really not interested in fixing it, it isn't likely that she will be successful in developing the skill. So first create the motivation for her to try; it is amazing what people can do when they want to. Failing that, assign her some support.

Eco-Capitalism

This twelve minute video talks about how some large companies have made environmental progress and money at the same time. Not only is this a fabulous trend for business and the planet, but it shows that if you look for win-win strategies, you might find them. Conversely, if your model of the world believes that something can't be done, your bias may inhibit or prevent it.

Intuition

I love this quote attributed to Jack Welch (and I've probably got it wrong, sorry Jack):

If we are going to make this decision based on opinion, I prefer mine.

I like it because it is straight up - facts and analysis are credible scientific truth-seeking mechanisms. Opinions are based on all kinds of human biases.

I attended a meeting recently regarding a paper to be published soon, about studies regarding expert's ability to predict future success of startups based on business data presented by entrepreneurs. The study group was able to use neural nets and Bayesian analysis to "code" the startup team's properties such that it predicted success better than VCs. It's not published yet, so I don't want to spoil their thunder, but it looks fascinating.

What this says is that your "gut" reaction is undoubtedly worse than careful analysis. It might be really good for those life-and-death split-second decisions using that small part of your brain wired for preservation. The allure of the intuitive decision is strong; but there is no evidence that it chooses the correct direction, and there is some compelling evidence to the contrary.

A May 2003 HBR article called "Don't trust your gut" reported that in 2002 45% of surveyed executives relied more on instinct than facts and figures. That's a staggering and scary number. It's so much easier to go by gut reaction, but the article makes the case that we are such effective pattern recognition engines that we see patterns where none exist. The pattern recognition skills built into your most basic brain functions are fast but not particularly good at sorting through risk. It's biased for survival; I read somewhere recently where a man had been next to a window which blew in during a windstorm, and now he gets nervous whenever he hears wind... totally illogical, but the pattern is burned in his brain.

My dog is a great pattern recognition engine. She notices subtle movements, sounds and behaviors and can interpret with surprising accuracy what will happen next. Yet I wouldn't ask her to choose my stocks for me.

Bottom line? Do the math.

Focus and Innovation

In my experience, a major impediment to innovation is lack of focus. If your organization isn't clear on what it is trying to accomplish and why, you are likely to consume your resources on a myriad of time consuming projects that contribute little to the effectiveness of the current product, and leave no room for innovation.

So if you want to innovate, get control of your portfolio. It will take time for this to trickle through the organization so that engineers feel comfortable saying "no" to things they used to agree to. It is hardest when those things are also things they enjoyed doing. I've seen a dysfunction where there seemed to be a gleeful satisfaction in avoiding accountability because the system wouldn't let engineers work on what they know they are supposed to work on. You have to observe this and stop it. But in order to do that, you need a clear mechanism for establishing and communicating focus.

Steven C. Wheelwright and Kim B. Clark advocate for an "Aggregate Project Plan" which decides on the fate of projects before they begin:

Simply adding projects to the active list—a common practice at many companies—endangers the long-term health of the development process. Management needs to create a set of projects that is consistent with the company’s development strategies rather than selecting individual projects from a long list of ad hoc proposals.

Wheelwright and Clark used change in product and change in (manufacturing) process as a means to define different types of developments: Derivative (little change in either), Breakthrough (change in product and process) and Platform (the middle). They also added a bucket for R&D and another for Alliances. They then plotted circles in the boxes to represent the resources required for various projects - larger diameter circles represent more resources. Using this system they were able to get management to remove projects that weren't clearly aligned with the company strategy, and in just a few years improved productivity at a particular company by a factor of three. The graphs started as a mess and ended up being clear and compelling.

Fewer projects meant more work got done.

Bottom line: don't let the busywork prevent you from doing the important work. We all know this is good advice, but it can be hard to make it happen. Wheelwright and Clark provide a tool to help you manage up and out to hold capacity back for what it is needed for.

Acid test for secure development

The March 1, 2007 issue of CIO magazine lays out questions for customers to ask you about your software development environment, and how to evaluate the answers. The first 5 questions are in print:

1. Do you review security at each phase of the software development life cycle?
2. What methodologies do you use for security testing your products?
3. Do third parties conduct security assessments on your products?
4. Do you have security squads that attack your products prior to release?
5. Do you use automated tools for security testing or code review?

and they have another ten questions in the full online article here. I can tell you that most of the places I have worked would provide really poor answers to these questions even today.

For those of you out there with products products which have access to your customer's networks and data: get yourself a roadmap for developing the skills in your organization so that you can credibly answer these questions well. Educate your management to get the funding and time required. We've gotten away with some amazingly casual attitudes towards protecting our customers, but those days are rapidly vanishing.

Innovation Test

I'm not sure if this is ridiculous or interesting, but I stumbled over a tool, put together by IBM Global Services, which portends to assess your organization's innovation strategy and benchmark it against 750 other companies. I rated a former employer and ... surprise... we didn't score really well. The assessment tool raises more questions than it answers, in my mind; and no doubt this is a tool to get you to hire IBM consultants to help raise your innovation. Well... let me rephrase that... to create an innovation strategy.

The tool is here:
http://www-935.ibm.com/services/us/gbs/bus/html/gbs_ceo_iat.html?re=schome

but I'm going to make a broad claim here and see if it sticks. Innovation is less about a strategy and more about a culture. You have to look beyond the short term, make sure people are not overwhelmed with the day-to-day things, so they have enough time to think about making long term things better. And of course reward the behaviors that support innovating. Now that I've said that, maybe I'm doing the same thing as the survey. I'm just as trite... and I didn't have to survey 750 CEOs to get there.

Cool Change Management predictive metric

The October 2005 issue of HBR has an article called "the hard side of change management". They introduce a new metric called DICE, which stands for "Duration", "Integrity of Performance, "Commitment", and "Effort". In their study they found that by applying simple subjective scores to each of these areas, and then a simple formula to roll up a total score, they have a number which can be used to predict success or failure. They did the study on over 1000 projects and found correlation between these four factors and were unable to add additional factors to produce a better predictor.

Amgen used the tool in 2001 when they made a series of changes. At one point they used this metric on 300 initiatives (yikes!) and reconfigured resources on 200 of them based on the DICE framework.

The authors suggest that it be used in one of three ways: track projects, manage portfolios of projects, and force conversations. All three are really helping the organization decide where to focus time and energy.

The article gives specific guidance on how to evaluate a score for each factor. You can pay for and download the article here from hbr.com.

Root Cause (or, punishing the innocent)

An article in the Wall Street Journal yesterday reminded me of how easy it is to fire people up to solve the wrong problem. For those of you with an online WSJ account, you can view the story here. There is also this article in Information Week which anyone can read. The articles talk about a bill that republican Michael A Costello is sponsoring, Massachusetts House Bill 213, which would punish retailers for leaking personal data. Now, don't get me wrong, we do want to provide incentives for protecting personal data. But the issue here is stolen credit cards. The root of the problem isn't security practices at retailers. It is not possible to completely secure a complex system from hackers. There will always be ways to get such data. Holding the retailer accountable is just wrong. Similarly, holding the software, system, and database vendors accountable is also fundamentally flawed.

What is the core problem here? The main problem is that credit cards are embarrassingly insecure. The banks don't deal with the problem because it has been less expensive for them to pay the price of failure than it is to fix the problem. What this bill would do, if passed, is completely let the credit card companies off the hook. That is just so wrong it is offensive, and I hope people see this for what it really is: an attempt to remove the increasing risk of credit card theft away from the group who is really responsible, by taking advantage of the current emotional response to recent TJ Maxx theft headlines.

The credit card companies can solve this. If you've used a SecurID card from RSA, you know that a credit card sized object can provide a unique temporary number based on a secret PIN you provide. You must have the card and supply the secret to get a one-time authentication. Instead of the inane little three digit code credit card companies have us copy from the back of the card, you could use a dynamic generated code which is based on at least two factor authentication.

Using such a system, it does a thief no good to have the card in their possession unless they have also obtained the magic number. If that did happen, the person who lost the card simply reports it stolen and it is disabled. No break in to any system would divulge the personal secret, and the TJ Maxx problem would simply go away. Not only does this virtually eradicate the most prevalent forms of theft, but it provides the bank with non-repudiation and replay protection. In other words, customers can't claim the charge was made without their authorization, and someone can't later use the numbers to create another charge. This means the consumer and the retailer win, at some cost to the credit card companies relative to the current system; but how much more expensive is it, if most of the theft goes away?

There are other ways to do this as well, probably equally effective, and some which are easier to use (hosted on a cell phone for example). But the banks don't want to invest in the infrastructure, and now they are trying to legislate passing the buck to the retailer, which ultimately will end up being paid by either the consumer or the systems providers, while the credit card companies continue to make record profits with inferior technology.

So let's quit punishing the innocent and solve the right problem. The retailer and the consumer pay the 3% transaction fee - shouldn't we demand that they earn their money and fix this abomination?

Do the same in your business. When someone is pushing costs around, take a look at what the real problem could be. It's probably the one that saves the most cost for most stakeholders, and in particular respects your customer's costs.

A change tool: ADKAR

I was considering a potential assignment and rummaging through my toolbox, when I recalled an acronym: ADKAR. I don't recall where I originally learned it. It is a diagnostic tool to help you figure out how far along a change an organization is, and what remains to be done.

(A)wareness is present if people are aware that a change needs to be made.

(D)esire is present if people want to change the status quo.

(K)nowledge is present if the people know how to change it and get to the new state.

(A)bility is present if the people are actually able to work on making the change -- including but not limited to (for example) being given enough time to do so.

(R)einforcement is present if there are positively reinforcing reasons to keep the new state.

It's compellingly simple on the surface. The hard part is really who are the "people"? An organization generally will have some people with each of these attributes at any given time. A stakeholder analysis will help here, but I think there is a momentum factor as well. As you progress down ADKAR, you have to line the influencers up and gain momentum with everyone involved.

The requirements factory

I was speaking to some offshore development managers last week, where we were discussing what a challenge it is to get good requirements. This is not a new phenomenon, it has just gotten so much harder with increasing levels of technical complexity and the cultural and distance diversity of our current development landscape.

The May 1995 issue of Communications of the ACM included several articles about requirements for software products. One of them involves how Digital Equipment Corp redesigned their requirements process. Their challenges and learnings are still relevant today.

They first described a fairly traditional nine-step process that one might find at any major software development organization. It isn't "waterfall" since many of the steps overlap. Nonetheless they mention that many product development personnel expect that creative, knowledge-driven processes are similar in execution to deterministic, manufacturing style processes, and that it was that view that was correlated to dissatisfaction with the requirements management process.

[they] expected the process to do the creative work of contextualized data collection, interpretive data analysis and responsive design

The teams that were more successful allowed themselves more flexibility on the process. In other words they adjusted the process to the problem. This supports the idea that a process should not be over-prescribed; the team needs the ability to be creative not only in how to implement the solution, but in how to figure out what the solution is.

Then they did something very innovative and interesting. They incorporated creation of marketing deliverables into the requirements management process. Specifically the marketing and advertising messages, user information, pricing and competitive positioning and sales and support information. I haven't worked or consulted anywhere where that was done up front, but it strikes me as a brilliant way to engage the cross functional teams to work through the entire problem set and ensure that they understand all aspects of what the proposed product is and needs to do. It provides the right framework to help answer the questions which will inevitably need to be solved, and gets them resolved earlier. The result is lower requirements churn.

The challenge for most organizations is going to be the change in behavior required to get the marketing department to work in a fundamentally different way. That means you'll need a compelling vision or a painful execution failure, and support from the top.

A well written product quality article

I was part of an effort where we had a tremendous impact on quality in just a couple of years. We principally did it by turning the organization around from its earlier behaviors, and simply making it clear that quality is the developer's job, not the QA department's. QA's job is to measure and prove that the developers did what they were supposed to (or that they didn't). Development's job is to design and build a high quality product. A lot of development groups don't run that way; we got fantastic results by making the change. I found this writeup, by Karl Wiegers, which talks about how to specifically implement systems which support that goal. It is fantastically well written. Karl is also the author of a book I have used to set up review systems, called Peer Reviews in Software.

Effective Communication

I found this on Ronny DeWinter's Software Quality blog:

Communication levels:
Not everything that is said is heard.
Not everything that is heard is understood.
Not everything that is understood is agreed.
Not everything that is agreed is applied.
Not everything that is applied is retained.

That is a fantastic short synopsis of why communication is so difficult. It shows that just getting someone to understand you is not enough. Of course, getting further down this list is not always required. But if it is, you should test every step so that if a breakdown occurs, you know where it happened and how to fix it.

You may not need agreement in every case, but it is nice to know when you don't have it, and if you have trust, agreement is testable simply by asking. If you don't have trust you may have to test downstream.

One of the places I worked would appear to have agreement but often fail to actually practice what was agreed. Application or practice should be easily testable, you can build it into the original communication. For example, "When you complete this, send me a copy".

Whether something is retained or not may or may not matter. If it is important to you that it is retained, put a follow up action in your favorite planning tool to test future retention.