We've begun thinking about what is next for LDS.ORG. As we do this, we'd love to get your input.
Take a minute and answer the following two questions. Our team will read each response.
1) What is the Church doing well with the Internet?
2) What is the Church not doing well with the Internet?
Feel free to forward these questions. We'd love all the thoughtful responses we can get!
Book Club: Wikinomics
I just started reading this one and am loving it. It can be dry and redundant, but the examples of commerical entities using mass collaboration are worth wading through a few moments of drudgery.
Pleasing the Customer(s)
When I worked in the mobile devices division at Microsoft we had an ongoing discussion about who our customer was for our mobile device offerings:
So which are the customers? Answer: All.
Customer: Anyone who lays a legitimate claim to directing your software development work.
Imagine how difficult it is to develop requirements for any one of the "customers" listed above. Now imagine creating requirements which balance all of the needs of the competing interests. Ugh.
We face a similar, though not so extreme, challenge in I.T. We have internal customers (typically product managers) who work for the departments we serve. They have their own management chain who have opinions of what work should be done and how. We have our own management chain which has its opinions. And then, of course, we have the end-users for whom we're collectively building the software. Pile on top the fact that "knowing what one wants in the software" is not an inherent skill. It's something most people think they do well, but don't.
So what to do? Here are some suggestions:
Having multiple customers can be a great challenge, but when you mostly satisfy most of them (in priority order) you accomplish something which brings great satisfaction.
- The carrier (e.g. Sprint, Verizon, AT&T, etc.) upon whose network the device would run.
- The OEM who would make the hardware (Dell, HP, Motorola, etc.).
- The kid who would use it.
- The parent who would buy it for the kid.
- The department(s) within Microsoft which might profit from services sold through the device.
- The random executive or product manager who had an opinion of what features should be on the device.
- And of course: ourselves!
So which are the customers? Answer: All.
Customer: Anyone who lays a legitimate claim to directing your software development work.
Imagine how difficult it is to develop requirements for any one of the "customers" listed above. Now imagine creating requirements which balance all of the needs of the competing interests. Ugh.
We face a similar, though not so extreme, challenge in I.T. We have internal customers (typically product managers) who work for the departments we serve. They have their own management chain who have opinions of what work should be done and how. We have our own management chain which has its opinions. And then, of course, we have the end-users for whom we're collectively building the software. Pile on top the fact that "knowing what one wants in the software" is not an inherent skill. It's something most people think they do well, but don't.
So what to do? Here are some suggestions:
- Start with high level requirements. Make sure you understand what the goal of the project is. Stand firm on this point, and don't relent for any amount of begging, threatening or bribery. Get the value proposition documented in plain English and make sure your customers, all up and down their management chain, agree. Treat this with the utmost importance and respect. It will become your rock later on when disconnects occur between product managers and their management. The value isn't so much in having a tool to cover yourself. Rather, documented requirements help you help the customers get on the same page about what is expected.
- Always be an advocate for the end-user. It's your solemn duty. Whomever your customer is, they care about the end-user, even if they don't understand how to delight them. Use whatever tools you choose or have available: focus groups, usability studies, contextual inquiry, intuition, whatever. Just make sure you understand the user(s) of the system and that you champion them at every turn. Your customers will thank you (though maybe later).
- Use functional prototypes to narrow the "gap of misunderstanding" up front and get everyone on the same page about what is to be built.
- Prioritize your customers. Understand which is most important to satisfy and take care of the high priority features for the high priority customers first.
- "Just say no" to executive/management pet features. Executives appreciate those who "speak up." If someone in your management chain tries to get you to add or subtract features and you know in your toes that its the wrong direction, then push back! If you've said your piece with all vigor of heart and the answer is still no, then press forward--you've done the right thing by speaking up. If having done so becomes a "career limiting move" then you may have the wrong management anyway. I speak from experience. The people in our organization typically take great pleasure in pushing back on me.
Having multiple customers can be a great challenge, but when you mostly satisfy most of them (in priority order) you accomplish something which brings great satisfaction.
mormon.org Beta
The beta release for the new mormon.org was released this weekend. Have a look.
We started the revamp several months ago. This is a great example of using a high fidelity functional prototype to understand what we were building up front, thereby decreasing development time.
The key new features include video testimonies from actual converts of the Church and an online chat where people who are interested in the Church can chat with members to learn more about the Gospel. We've been pilot testing the chat feature for several months and have already seen several people join.
We started the revamp several months ago. This is a great example of using a high fidelity functional prototype to understand what we were building up front, thereby decreasing development time.
The key new features include video testimonies from actual converts of the Church and an online chat where people who are interested in the Church can chat with members to learn more about the Gospel. We've been pilot testing the chat feature for several months and have already seen several people join.
Tech Talk Last Night
We had another tech talk last night in Mountain View, CA. About 30 or so people registered--almost 40 showed up. We had folks from:
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
- Cisco
- Ebay
- Dreamworks
- Oracle
- Barclays
- The State of California
- Sun Microsystems
- Sprint
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
Tech Talk in Mountain View
Just a reminder that we're having a tech talk in Mountain View, CA this next week. If you have time, head over to the lds tech site and register so we know how many people to expect.
The Maintenance Monkey
Maintenance. Call it bug fixing. Call it "keeping the wheels on." Call it warranty. Call it whatever you want.
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Well, sure it's a bug! You promised me the ability to report and this is a report I need!"
"It's only a few hours, huh? I don't want to go back for approval. Just do it this once, wontcha?"
"Um. Hey Fred. Uh... Listen... I know you're working on a new project, but I was in the neighborhood and happened to have these tickets to the playoffs..."
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Subscribe to:
Posts (Atom)