Get the customers involved. Choose a pilot group of customers to work with. Agree with them that you will hear their needs and will accomodate requirements that fit within your production schedule and shows a real ROI. Have your folks sit down with them and work out the ROI. Sometimes when the customer sees what they will gain from the feature, it’s not really worth it. Sometimes, on the other hand, you believe that you know the customer’s business, but you find out that you’re dead wrong- the requirement they’re asking for is a major ROI coup.

This approach not only helps you do two things. First, you build products that include only the features that show real ROI value to your customers. You leave out things that seem cool, but in fact have little value. Secondly, you develop real numbers to back up why some features are good versus others. When questioned about why a feature matters, you can lay down hard numbers. You can also defend why some features were left out- and why those features in competitor products look cool, but in fact do not work out to the savings that they appear.

The end result? You build smarter products that match up with your customers real (not perceived) needs. You also build formidable marketing and sales data backed with ROI figures. When it comes time to knock on doors and sell, you aren’t armed with market buzz- you are armed with hard numbers, case studies, and hard facts from the real world. Not only is your product better, you can prove it.

Let’s begin by considering why uptime is so important. Users love reliability in computers. If their PC crashes, they get upset. If they do it too much, they’ll change operating systems, buy tuning products, hire service techs, even buy whole new computers. If local applications crash, they will get rid of them and buy a new one. The same thing applies to web applications and websites, even free ones. If it is unreliable, users throw it away. The logic is that if the service is worthwhile, someone else more reliable will provide it (and they’re right). Why on earth do users dispose of websites, computer programs, and even whole computers so easily over reliability? The reason is simple- computers are replacement tools. There is little that end users do with computers that they cannot do some other way. I can write by hand, do spreadsheets by hand, databases by hand (it’s called a filing cabinet), get music by hand (CDs), get video by hand (television), mail by hand (snail mail), talk to people by hand (telephone, face to face, etc), research by hand (books, libraries). Computers, for the most part, replace other processes because they are faster and easier. If it is not as reliable as the process it replaces though, then as a user I might just go back to the tools I had before. With more experienced users, if it’s not reliable, I just wait for something that is, because I know by now someone else will take the idea, run with it, and build something more reliable. Reliability is a major way that you can lose a customer/user.

This illustrates my first point- uptime in and of itself does not matter. Being up when the user wants it to be up does matter. So I ask this question: In today’s era of web analytics, why do we believe that our systems need perfect uptime? Using web analytics, I can see what times of day how many customers are on my site. I know that if there are five user sessions between 1 am and 2 am, I have five customers in that time. I should treat these as five seperate customers whether or not they are unique users because a repeat customer is, quite frankly, as good as a new customer. Anyone who uses my service five seperate times in an hour loves it enough that they not only represent themselves as a customer but also future customers that they will recommend my service to and bring me. This is especially true in a startup world where you are trying to build market share. I also do not want to base it on page hits over sessions. If one customer is a heavy user, I kind of hate to make him mad, but on the other hand, a heavy user is a dedicated user. He will more likely wait for the system to come back online. Better to annoy one dedicated user who clicks a lot than fifty customers who were just checking out the site. Unique customer experience sessions are the key to measuring customer service.

Using this knowledge of my users’ average habits over time, I can count sessions and project them over a 24 hour graph (or by week, or month, or whatever is best for your business model). Now that I know this, I can base my uptime expectations against that chart. Armed with this, I can expect my uptime to cover a specific percentage of user sessions, such as “The system must be available for 99% of average user sessions in a given day”. It doesn’t matter nearly as much if my servers are down for seven hours if I know that less than 1% of all user traffic logs on during those hours. I care a lot more about five minutes of downtime during an hour where 78% of my website’s traffic occurs. Using this kind of logic gives real meaning to my uptime planning. It also is very practical in a worldwide economy. I know people who think it’s okay for their website to be down at 2 am. It is if your customers are in the same time zone, but what if you have a sizeable foreign userbase? For that matter, what if your userbase happens to be a lot of night owls? You need to know when your site is getting hit, and be up during those times.

There is a second thing to consider in calculating ‘uptime’. Quality of Service must be considered as well. All bad customer experiences count against you. An unacceptably slow website experience can be said to be just as bad, therefore, as true downtime to an end user. I recommend setting a minimum response time for your website or web application and, if you have the capabilities, monitor its response times through automated tools. Poor response times should be counted against your uptime statistics equally to true downtime. If you do not have access to these sorts of tools (and they’re not simple to implement and can be expensive), then stick to pure downtime for your equations.

This system is, of course, not perfect. If you are planning a major marketing push, you must adjust for the increased web traffic and plan your marketing information releases against your server traffic. Don’t announce a major release of new features during peak uptime, for example, because the increased traffic may tank your servers, and if you plan a major release during a lull in your usage, you need to adjust your chart for predicting usage so that your admins realize uptime will be measured differently while the push is on. You also have no control over some press, say, for example, if Digg or Slashdot suddenly tells the world to go look at your neat new service and send you 10,000 hits in an hour.

This idea may need some adjustment and tweaking still. It’s somewhat of a shot from the hip right after inspiration struck. Please, if you know of ways to refine it, comment on. I’d love to see a discussion started that fleshes out what is hopefully a good alternative to the burdensome “five nines” way of doing web business today.

There is no question that word of mouth has done great things for Facebook’s adoption and in turn its value.  People have loved the application for allowing them to do a very simple thing:  talk about themselves, keep in touch with friends, and make new friends.  I daresay that items 1) and 3) there are the key driver of any social app; people want to talk about themselves, and people want to think that what they say about themselves is so interesting that people can’t wait to be friends with them.  It feeds all of our inner egos and/or self-esteem.  Their original target market is teenagers, who are, as we all know (particularly parents out there), all about trying to identify who they are and wanting acceptance from peers.

That same word of mouth recently bit Facebook.  Their Beacon program’s online tracking showed a gross misunderstanding of their customers by violating several important tenets:

1) Users in today’s internet are nervous about privacy

2) As any parent knows, teenagers (one of Facebook’s major markets) are really paranoid about their privacy

3) The way that Beacon worked, sooner or later it was going to show up as spyware in any number of security apps- and people were going to block the service anyway, and then they were going to fear Facebook as a result (my security software told me it was bad!)

Facebook broke an even bigger rule with this program, however:  at some point, they stopped thinking about their customers as people, and started thinking of them as sources of information.  Many companies have done this.  You know of a way to get information from your data sources, and you decide on a new feature or revenue source that you can generate from that information.  Too often in this situation, companies think of revenue rather than the customers.  Facebook did this when they decided to make people’s purchases public for the world to see without the ability for the customer to approve or edit the feed.

I am all about revenues and making money from customers.  That’s what free enterprise is all about.  Still, you must always remember what your customer’s core values are.  Evaluate them.  Write them down.  Put them on your wall.  Violate their core values, and not only will they abandon you, they will rebel.  Word of Mouth is the number one advertising method out there.  Don’t turn it against you.

So why does this matter to you?  “I’m not in sales and marketing,” you say.  It matters to you if you have a job anywhere, doing anything- or even if you don’t.

Word of Mouth spreads people’s opinion of you.  It spreads their opinion of the work you do, of your team, of your project, of your department, your company… it goes on and on.  Looking for a job?  If your friends and past coworkers do not respect you and your work, you won’t be getting help from them- even if they say that they are helping.  Networking has been shown to be one of the #1 ways of landing a new job, and if you haven’t painted a picture of yourself positively with those who know you, you’ve cut yourself off from that market- or worse, turned it against you.

How about your next review?  Expecting a raise?  Do you think that if you have a poor image with your coworkers or customers that’s going to help you?

Funding for your project?  If the buzz around the company water cooler is that project X is hot, but no one’s heard much about yours, you might be in trouble.  Funding for more staff for your department?  Not if word of mouth says your department isn’t contributing value.

You should care about your reputation no matter what you do for a living.  Even garbage collectors have bosses who have to listen to complaints- and who hear praise.  What they say about reputations is true, too- they take years to build sometimes, but they come apart in seconds.  People are more likely to talk about negative things because they like to complain.  If you are consistently bad, everyone will know.  People talk about inconsistencies because they notice them.  If you do a good job normally, but make a screwup, they’ll notice that (of course, if you handle your error well, they’ll talk about that- which can do you good).  Most of all, people love to talk about their problems- so if you cause people problems, expect the word to spread.

On the contrary, integrity is admired.  Help is appreciated.  Value your working relationships with others and try to bring value.  Act with integrity and be fair.  Strive to be not just ‘a good employee’, but the kind of person people want to work with.  You can’t afford not to.

For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.

Here’s some things to do to prepare for major version changes during your implementation:

1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.

2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.

3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.

Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.

Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.

Consider this approach for a moment in the light of the concept of technical debt.  Technical debt is to your IT workforce what credit cards are to your kid in college.  Increased features and new products mean more maintenance costs.  Increased speed to market means increased bugs.  Rising technical debt means that your team will be able to contribute even less in the mid-term and long run.  Contributing new, buggy things rather than increasing the value of what you have simply lowers your perceived value to the business.

Before deciding to add new projects, products or features, ask yourself this:  is it time instead to pay down existing technical debt?  What can I do to lower support costs?  How much better can I make what I have?  Do I have any open requests from the business to solve old problems?  Can I increase my perceived value by simply focusing on lowering overhead and getting rid of ‘old’ problems that have been lingering?  Turning your efforts inward to improve now will give you a stronger position in the mid-term and long-term.  You will have lower maintenance later when you ramp up new projects, and by clearing your backlog, you’ll be surprised at how much support you will garner from your business partners.

Let’s consider what this does for the business.

The pros:
*Abbreviations or shortened brand names enable easier communication for those in the know
*Better advertising- people ask “what is?” and you get the chance to sell them

The cons:
*If all employees are not in the know, it impedes communication. For example: everyone probably knows what the intranet is. Everyone probably knows the company has one. Everyone also goes to use it when they need to. It’s part of their jobs. Why does it need a different name in order to communicate about it effectively? Why do you need to sell it? If you need to sell it, then it isn’t doing a good job for the company at what an intranet does.

*Employees have to learn what all these terms mean. Managers have to learn what thousands of them mean. Wouldn’t the company be better off if these people were spending their time learning to do their job better instead?

That second con is a big one. Everyone has a certain amount of bandwidth for receiving, processing and understanding information. They can only truly learn so much per given day. This is what the whole “information overload” crisis is about. If you are creating product names for internal applications that don’t need one for the sake of branding, or you are creating abbrevations for things that don’t need them, are you helping the company by eating up employee bandwidth for learning?

Certainly, corporate culture can help you spread your abbreviations and internal brands. Is this what you want to use your corporate culture for? Wouldn’t your company better profit from the corporate culture spreading values and knowledge instead?

The bottom line is this: Abbreviations are for things you already know. Brands are for selling things for a profit. Use them in the right places, and at the right times.

This is a great idea for startups, but it’s also a great idea for keeping direction in general examples include:

1) Finding direction in projects
At some point early in a project, you must decide what question your project is answering. It could be anything from “how can we share spreadsheets better?” to “How can we get orders to customers faster?”. This is the core of your project. Never lose sight of this question. You will write a scope to your project that defines what you intend to do in your project. When you develop that scope, it better answer your initial question. When you write requirements, they better trace back to that question. When you build the prototype, it better offer an answer to your question… you get the idea. If your project ever reaches a point at which you aren’t answering that original question anymore, then you’re off-track. You better fix it or start over.

2) Finding direction in product lines
“The question” can also drive the development of your product line over time. How many times have you seen this: you’re on a project, it completes successfully, everyone is happy, then a thousand ideas pop up for how to ‘improve’ the product. You have manpower to do maybe five of these things over the next year. How do you choose what to do? Simple. Look at the question you set out to answer. Which ideas support that? Which ideas move you away from it? Ditch the ones that move away; if you follow those, you may undo all the progress you made. Go with the ones that support your original goal. Repurposing a product is very practical, but if you change the purpose of the product in the process, you’ve lost the solution to your original question.

3) Maintaining and marketing your Brand
If you have a brand, it means something. It answers a question. When I think “How do I find what I need to know?” I think “Google it”. The google brand answers questions for users. When I think “Where do I get coffee?” I think Starbucks. See? Brands answer questions. They become associated with very specific ideas in a customer’s heads. A customer can usually associate and recall about as many things with a brand as they can keep in short term memory easily- that is, five to seven things. Get outside of this, and your customer has to stop and think about it before they can decide what your brand means to them, and you’ve diluted your brand too far. Therefore, you should develop a question that your brand answers, and stick with that question. When you decide how to expand your brand, stay close to that question. Starbucks would seem like they didn’t do this with putting music CDs in their stores, right? Ahh, but no. When I think of Starbucks, I think of drinking coffee, sitting in a coffee house, reading, relaxing, and listening to good music- which begs the question: why doesn’t Starbucks sell books? Probably because they locate some shops inside book stores, and that would be biting the hand that feeds them. Book stores need more space than a Starbuck’s does, anyway.

See the point? A single question drives so many things in business. It brings focus. Find your question to answer, and it will help you keep focus in what you do as interruptions, new ideas and distractions pop up in your day each day.

It’s good business to make your client as prepared as possible for life without you.  That may sound counter-intuitive, but it’s true.  It will save them time and make their life easier.  This is likely that this will get you better references from them in the future, which is always a good thing.  The better their experience leaving you, the more likely they are to come back someday later on.  Insofar as word of mouth reputation goes, the impression you make leaving a client is probably the second most important impression you make on a client, right after the first impression.

It will also save you time and effort, as whenever the former customer hits the wall regarding anything you’ve worked on in the past, they are likely to call you.  In many cases, they’ll expect their questions to be answered pro bono.  A clean cut-off is in the best interest of everyone.  Also, prepared to leave you completely also means good choices for you such as easier to migrate to the next generation of your product, easier to back up their data, easier disaster recovery and business continuity, and other important things.

That said, here’s five things you can do to make life easier:

1) Have any and all client-owned project material boxed up and/or burned to CD. Return this to the client as soon as possible. You may consider keeping a copy for yourself, if legally allowed by your contract (if the customer loses it, they’ll probably call you).

2) Have any and all source code, scripts and whatnot also burned to CD and sent to the client. Be sure to keep a copy (again, if allowed) for reference, and be SURE to document everything as carefully as possible. You may have to reference this stuff later, the customer will possibly have to, and who knows who else. One thing is for certain- if anyone in the chain has questions, they’ll likely call YOU.

3) Have at least one (preferably more than one) different provider reference ready and provide it to the client. Try to be sure that the provider meets the clients needs- financial and otherwise. This may seem like a bad idea, especially if the client is firing you. It’s not- anything that you can do to help the client, in the long run, helps your company’s image with them. You may yet get a referral from them someday, and even if you don’t, you never know who is calling them to ask them how your service to them was. The better you are to them, the better off you are.

4) Have all customer invoices ready. Provide them in hard and soft copy. Try to set terms on them that are clear and concise, and bring the financial terms of your relationship to as clean, quick, and polite an end as you possibly can.

5) Document everything you can about the client relationship. Keep up with contacts, who did what, and any notes you can think of that will help you with relationships with these people in the future. Remember, you may not ever do business with this customer again, but people do change jobs nowadays, so you may do business with the individuals who work there later on. You need this info to help protect yourself, possibly build new bridges into new clients in the future, and maybe even know what bridges not to cross later on. There’s no end to the value of good notes.

Stick with these guidelines, and they will help you down the road.

How many of you have heard a developer say this at one point or another:

“Why on earth would they want it to do that?”

Waterfall requirements gathering has become a very sterile task- identify what must be done.  Don’t get into the weeds.  Describe the problem.  Let the developer solve the problem.  Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described.  They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst.  User stories can be the same way.  What you end up with is a flowchart of a process, but you don’t know necessarily really know what the user meant to accomplish.

A good business analyst can get at what the user’s intentions are.  The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems.  Or, worse, the analyst sees exactly how the current software is solving the problem, but misses the fact that the current system has already been determined to not be solving the problem in the best way (after all, that’s why you’re replacing it, right?).  What the business analyst usually has is how the user thinks the software solves the user’s problems.  There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.

What this leads to is the analyst documents what the user wants, the developer hacks up the system trying to make it act exactly that way, and the implications of that to the rest of the system or to other systems are not what the user expected or predicted, and in the end, you have unhappy users- because you did exactly what they wanted.
My point is that too often business analysts capture the “what” of the problem perfectly, perhaps even the “how”,  but not the “why”- and you need the “why” to determine the best “how” of solving the problem effectively.  Since we have started working on connecting developers to the “why”, we’ve seen massive improvements in our organization.  Software quality is up, software that does what the user wants is being built faster and better, we have developers whiteboarding new ideas and designing next generations of the software we have today that will clean up many long-standing software issues.  We’re quickly evolving into pitching solutions to the business’ problems to them before they’ve reached the point of deciding to ask for our help.  Why seems to be one of the magic bullets involved in spanning the gap between being an IT organization that does things when asked to being an IT organization that thinks.  All because we started explaining why to the people who do the work.
Agile programming is changing things somewhat.  Sprints are sometimes too short to understand the whole problem, but the fundamental issue is getting fixed- all the right people are getting in the room together and talking.  During my career as a project manager, I emphasized to people over and over one mantra:  projects have been done for thousands of years, and most of those times without our modern tools.  Provide good enough communication, use no tools, you still have a chance to get the project done well.  The tools support and help and should be used, but they are no substitute.  Use every PM tool in your toolbox, fail at communication, and the project has zero chance of success.  None.
The concept of appropriate communication can apply to your project management, your business management, software management, or anything else.  Explaining why engages people and involves them in the problem.  Why is powerful.  It can innovate.  It can bring up issues with the original design or process before it goes into place.  It creates a more team-oriented way of thinking about the solution.
My point is this:  bring why to the table when you engage people.  Include it in your project charter.  In requirements documents.  In meeting requests (how many times have you gone to a meeting with no idea why you were requested to be there?).   It’s a valuable tool.  Use it.