Search This Blog

29 April 2011

Requirements Complexity - Expurgated Version

If you didn't read my last post on requirements complexity, what's wrong with you???

Seriously though, here's a MUCH shorter version that says essentially the same thing, just with the audience of developers and not BAs and PMs. Best quote from the linked to article, given the ~1300 word blog post I wrote on simplicity earlier in the week:
It turns out that, much like it's easier to write a long blog post than it is to make the same point succinctly, it's difficult to write software that is straightforward.

28 April 2011

What would Tom De Marco know?

Tom DeMarco’s recent assertion (PDF) that a 5% return on investment suggest a project that shouldn’t be run. This omits the portfolio management approach of setting return targets within a weighted super-set of benefits. In this instance we aren't just comparing 5% with huge benefits, we are comparing a number of competing initiatives, and some of them may have only slightly different prospects.

In this instance where do you invest?

While I raise this strawman, I don’t personally buy into it.

I am yet to see a corporate environment that runs too few, or even an appropriate number of projects for their capacity. Most have too much going on at once, and as a result are churning and wasting energy where they don’t need to.

Why not adopt WIP principle at the portfolio level? Get more done and occasionally pick the wrong order or priorities, but still... get more done?

Naturally, he knows this as well.

Go read the article.

26 April 2011

Requirements Complexity

Back in December 2010, one of my stakeholders approached me with a feature request from our user community. As we talked through the request, we both realized that the system in question came close to meeting the request in several different ways, but did not fully meet the requirements with any of the different methods we tried. After an hour or so of brainstorming, we realized that being oh so close is still very far away. This was the beginning of what has become a four month escapade to finalize requirements for what appears to be the most simple of concepts.

Actually, the concept is very simple; its just easy to confuse, too. I remember thinking that it wouldn't be very difficult to make a few system tweaks to one of the existing methods and we'll reach the goal within a couple weeks. It just didn't turn out that way in reality.

Round 1

As a larger group of stakeholders began to assemble to address what needed to be done, a large set of competing options landed on the table. Some were significant in terms of system development, some were easier, but had very nasty reporting impacts. Another was simple development and had few reporting impacts, yet was essentially just hard-coding a band-aid over the system and praying nothing fell apart.

All of these solutions would meet the requirements, with different levels of risk and impact to other teams in our organization. The end question came down to, was it worth it to take the pain of a longer development time now (not to mention the business not seeing a return on its investment till much later) than to risk the whole system? Surprisingly, the answer came back as neither. We presented a list of options that didn't require code changes, but did not completely meet the business requirements, and suggested that the business area go with an imperfect, yet quick return. There were clearly defined caveats to this approach, but our stakeholders signed off and we were good to go.

Or so we thought.

A few days after sign-off was complete, several of my stakeholders came storming down the hallway in a near panic. What do you mean that the no code solution isn't perfect? Why didn't you tell us?

Well, we did tell you. You signed off on it, right below the big disclaimer stating that it wouldn't, 100% meet your requirements. In fact, during the sign-off meeting, we even read that section to you.


In our business area's defense, despite our spelling it out multiple times, we probably didn't do a great job of communicating the business impacts of our proposal. Yes, we covered it, but likely put them to sleep with a bit more technical jargon than we would normally use, all for the sake of being thorough. We compromised the clarity of the message with extraneous detail, lulling our stakeholders into a false sense of security. Not that this in any way absolves them of having not read and comprehended, just that we were all culpable in this situation.

Round 2

With that, we went back to the drawing board, working through all the scenarios yet another time. And another time. Eventually, my team and another team in the building put forth two different, yet complimentary solutions. The problem was, while they came to what was essentially the same outcome for both systems, integrating the two to talk to one another would be a nightmare for both teams.

By this time, over two months into the process of eliciting requirements for a project that literally takes six words to explain to anyone in the business, I had become pretty good about explaining the problem and what would eventually become the solution that the stakeholders selected. It was at this point that the contention between the developers and the analyst started. No fist fights or even strong language was used, just a passion for over-complication.

Developers live in a world of complexity and edge cases. After a decade in this business, I get that. We need developers as they force (in a nice way) us to think through the details as to how our requirements impact their solution. I ended up realizing that all these complicated scenarios I kept being hit with all came down to three rules, all of which were exclusive to one another. This epiphany was interesting when I started to explain it to others because, at first, no one wanted to believe it was just three rules. Even the lead BA for the other team didn't want to believe it at first.

So I did what I probably should have done before, I sat down with all the teams and, through many hours, explained my three rules. People would say, "Yeah, but what about if we..." to which I would respond by naming a rule. At one point I think one person even started trying to make up crazy scenarios just to find a way to break my rules. They failed in this pursuit, not because I'm necessarily so smart, but because clear, simple requirements win.

Making it Simple

Looking back on the situation, there are a few obvious things I did (and did not) do that would have made all the difference in the world to shortening what has now become a four month process to create requirements and design for an enhancement that, again, can be summed in six words. Here's the list:

First, make it simple. The second requirements document that received sign-off, the one we are now implementing, has four lines of business requirements. Those are the six word description and the three mutually-exclusive rules. That's it. There is zero ambiguity in what these mean. They are phrased in the business' terms; language my stakeholders understand. Its not in BA or developer-speak. Its simple, its focused and it is precise. In short, its all the things that I should have done the first time but, because I was focused incorrectly on a solution, one which did not totally solve the problem but, I thought, would cause me less work. I couldn't have been more wrong.

Second, never assume that by not meeting select requirements you make less work for yourself. You're probably fooling yourself. It may look in the short term like you have less to do, but your stakeholders will come back at you (rightfully so) time and again until you either completely meet their needs or they give up on you ever meeting your needs and go around you.

Third, simplicity for some is complexity for others. When the two development teams created competing and contradictory solutions, we all lost. In this case, we lost at least two to three weeks of time trying to haggle out a solution that would work well for both teams. Both groups were rightly protective of the integrity of their systems, but we failed to realize that our simplicity was nothing more than complexity for everyone else.

Lastly, never forget the power that comes from crafting a simple solution. Once both development teams understood, and more importantly believed in, the rules as I laid them out, we began to realize that while the development effort would by no means be minor, it was by no means the hair-ball of code everyone first thought it would be. Yes, for one of the two teams, it meant a significant departure from the way they usually develop and would mean a substantial increase in the processing needed to complete their algorithms, but they're smart people; they know how to do hard work.

19 April 2011

The Requirements Discovery Project

Requirements discovery, and resulting documents and communications activities can be defined as specific projects.  Should they be?  Possibly.  I have been thinking about this topic for years now.

Corporate projects, with a discreet discovery activity and deliverable should probably call out the requirements discovery work as it's own project.  Combining it with the solution delivery component becomes a programme.

I am just making a note for myself now, but this concept lines up with a lot of industry leading thinkers of the last few decades.  And it fits perfectly as a mental model for managing the contextual dependency for requirements discovery up front or parrallel to solution development.

Thoughts?  Should I elaborate further?

The Danger in User Surveys

One of the dangers, as pointed out by the BABOK is that surveys are not good at collecting actual behavioral information about our users. It seems to me that a large number of executives at Wal-Mart should have done a better job at understanding exactly when and why to use a survey.

If you're not familiar with Wal-Mart or their recent attempts to de-clutter their stores, its well worth looking into. Back when this was announced a couple years ago, I remember thinking to myself, why would they want to decrease the number of products they carry in each of their stores? There are many things I dislike about Wal-Mart, poor product quality, never enough cashiers, the other shoppers in the store with me, but the one thing I never complained about was how many products they offered.

Sure, it wasn't always the easiest store to find what you needed, but with the help of a sales associate or two, you almost always could find it. I can think of only a few times I ever shopped a Wal-Mart and was completely unable to find exactly what I was looking for or a close enough substitute that I left satisfied. Given that the number of options available was a good thing for me, I was astounded to find that management had decided to shrink their offerings.

Don't get me wrong; I was all in favor of wider isles and better organization, but not at the cost of fewer choices. I don't live at Wal-Mart, I just shop there. I can deal with clutter if I have to because at any time, I can turn around and leave the store.

This is a good lesson for those of us who work in projects to remember, that just because we think we know an answer and especially when we think we receive validation that our answer is correct, it doesn't mean anyone was really asking that question. Customers said they would like less clutter in the stores, but did anyone ask in the survey if the customer preferred clutter or choices? Obviously, given the outcome, customers choose clutter and options.

Have you ever used a survey in a project? Was the answer you received as faulty as the one Wal-Mart found?

18 April 2011

Working as a team

Yesterday I was reviewing a doc that I wasn't really happy with. On the way to the review meeting I realised I was about to make a stupid mistake.

I was thinking I was going to go in and explain how the doc failed in many ways and didn' follow best practices. Essentially I was going in with the mindset to be an obstacle.

Before I sat down I realised that I needed to approach this from a different perspective.

Was it good enough to work with? Probably. Did everything need to be tight and perfect for me to be able to move on? No it didn't.

And it would have harmed an already fragile team espirit de corp.

It's more important to be able to communicate openly and work together than to address problematic documentation.

Back to the concept of satsficing. Satisfy + sufficient.

Instead of looking at the shortcomings as obstancles or risks to manage right now, I decided to instead to assess whether it was good enough to work with. And then to highlight the risk areas and try to resolve them in a positive way on the room.

We still have a business case doc that has loose terms of refernece and ambigous staements about what needs to be done, but as a team we can work through these issues down the line.

What's the message here?

Put people ahead of processes.

Photo by jsgraphicdesign CC @ Flickr

15 April 2011

Giving Them All The Information They Need

A few months ago, one of my stakeholders told me what has come to be one of the most amusing stories I've heard in my career. I think about it often as I think it perfectly illustrates why those of us who work on projects do what we do. Let me share this one with you as I think you'll come to appreciate it as much as I do.

My stakeholder, who I'll call Trevor, owns his own small business. He has a series of locations spread out over a fairly large, fairly rural area. Much of his time is spent driving between his different locations to ensure that each business is being run exactly how he feels is best.

One Thursday, around 2pm, he happened to be at a location that has a few troublesome employees. The time and day of week is significant as his rule is that paychecks are distributed at 3pm on Thursdays. Its one hour before payday.

Trevor is sitting in the small office, reviewing the store's reports, when he sees one of the troublesome employees, who is not scheduled to work that day, walk in the store. The employee, who we'll call Steve, spends a few minutes talking with various people before he gets close to the office. Trevor asks Steve to come in to the office and sit down and chat for a few minutes.

As they talk, Trevor leans over to computer and pulls up Steve's timeclock report for the last week. What do you think Trevor sees? Seems that Steve has been late to work, sometimes by only a minute or two and sometimes by half and hour or more, every single day that week. The conversation went like this:

T: "Steve, what time is it?"

S: "2pm"

T: "You know, looking at your timesheet for the last week, you've been late every single day, yet today, when its pay day, you're here an hour early."

S: "Well..."

T: "No, its obvious you can tell time because you can get here early on pay day, so how is it that when you're scheduled to work, you can never get here on time?"

S: "Look..."

T: "Its this simple, you're scheduled to work, you show up on time. We've proven today you can do it and from now on, I expect you to be here and ready to work when your shift starts, not sometime after it."

From there, Steve beat a hasty retreat from the office, but Trevor's point was clear; if you're going to work for me, you have to meet my expectations. Steve, despite having worked for Trevor for some time, thought it didn't matter, but to Steve, it very much did.

But what if Trevor hadn't been able to look at Steve's time clock punches in a timely manner? What if he had needed to go rummaging through a file cabinet that was locked in the tiny office? What if the time clock had not been part of the computer system but had been a physical clock on the wall? Trevor would not have been able to have that teaching moment without the project that implemented that virtual timeclock.

Its nice to hear from stakeholders who see the benefit in what each of us do day in and day out. It is even better to know that you've provided your stakeholders with the tools they need to be successful at what they do best. It is days like the one where Trevor told me this story that make me glad I get up and come in to work each weekday.

13 April 2011

Project Initiation and Scrum

I gave a talk to a combined Melbourne Scrum Users Group/ACS Lean/Agile sig. It was an interesting and diverse group with a few experienced scrum users and a handful of old hand consultant/pm types interspersed among many inexperienced people.  As a result the talk had to accommodate some Scrum 101 stuff and shortchange the more difficult initiation content.

Overall, it went longer than planned with me talking for a bit over an hour instead of a concise 10-15 minutes.    I also got some good feedback regarding use of metaphors (Almost nobody knew Othello) and trying to close my narrative with a stronger finale.

In the end it went well, and I hope I get some feedback from the audience via the meetup site and ACS website.

Slide deck below, and you bloggers & commentators out there - remember it's all about the context, and there are no absolute answers.  I'd love to hear your stories about project initiation in all forms and shapes.

12 April 2011

People, Process, Today and the Future

Bob Marshall pointed at an article yesterday about how culture enables or disables organisational change efforts.  The article itself is by William Schneider (1998) “Why Good Management Ideas Fail - Understanding Your Corporate Culture”

Dr Schnieder's bottom line is that if you don't fit your change effort into something that aligns with culture it will be an uphill battle and it won't stick.  Change has to be managed at a total system level, including culture. This message resonates with me.

In the details of the article he goes on to explain some of the issues and characterize different organizational cultures. I have reproduced the concepts in a bastardized graphic here.

The model is a two axis, 4 box grid, just like the rest of them, so that's an alert to realize that this is a limited model and needs to be considered in a broader context as well (for example, what about organisational structure, or size?)  But for now it suits a purpose in enlightening our change efforts.

The first of the two axes is a focus on the current state or a focus on the potential future state.  This gives an organisation an inclination to either improving performance from existing operations or else changing operations to improve.  A subtle difference in phrasing, but substantial in it's implications.

The second is in understanding values about decision making - do we trust the system or do we trust the people.  Stating it like that probably gives away my bias, and you already know my thinking here anyway, but this is in my view, tightly linked to the today/tomorrow axis.  What are you making your decisions based on? The capability of your people and processes today or their potential?

Next are the four attributes of the quadrants.  I have formatted the font for each differently to help explain;
Competence - is the behavior of the culture
(Enrichment) - is what the culture values and the lens through which is views the world
Craftsmanship, Challenger - is the nature of leadership in the culture
Product Excellence - is the market strategy that the culture is likely to pursue
I have modified some of the terms to both simplify the ideas and to link them to conversations going on in industry today.  You can read the whole article to get a better explanation of the details here.

A last point before I sign off with a few questions; Dr Schneider reminds us that a change effort needs to align to the much more powerful forces of organisational culture.  Either pick a method that aligns with the existing culture or at worst, pick one that is from an adjacent quadrant in the model.  If you don't leverage the forces of culture your change effort is futile.

I partly agree with this.  I do think that you can go against the grain.  It's just that these change efforts are more disruptive, much harder and rely upon commitment from everyone top to bottom on the org chart (and probably customers and suppliers as well.)  I believe this because there are companies that have done this, often driven by market failure and catalyzed by new leadership.

As I said above, there is more to this  that the model illustrates and there are always exceptions to the rule, but it is a useful tool when considering consulting and change management work.

Now, before we go, here are some questions for you;

  • What do you value?
  • What are your colleagues like?  Where do they naturally fit into this model?
  • What sort of organisation do you work for today?
  • Where should you be working?
  • What will you do about it?

The BABOK and Requirements Reuse

One of the first things I learned as a BA was how to write requirements. I still remember the subject of my first two business requirements documents (using card payments for the purchase of extended warranties and using card payments for the purchase of out of warranty service) and I could probably recreate them today, nearly word for word, over nine years later.

Yet, in those same 9 years, not one time outside of that project have I ever needed to reuse those requirements. Despite having worked on an absurd number of projects over the years in similar and vastly different organizations and teams, the need for those requirements have just never come back up again. Even at the company where I did that first project, those requirements haven't once been used again.

A former development manager I used to work with was regularly heard preaching to his developers about the importance of code reuse, yet in all the time I worked with him, I never saw him or heard him speak of actually doing it himself. From what I've read in the blogosphere, it seems as if I'm not alone in thinking that code reuse is not as important as it sounds like it should be.

Its this focus on code reuse that I think has shifted over into the realm of the BA, possibly inappropriately, and reusing requirements. Yes, requirements can be reused, and if you come across a project where they can, great! In my 9+ years, this hasn't happened even once, even on projects that were very similar. Am I the outlier, the one guy in the industry who has had the spectacular fortune (or maybe misfortune) to never have been able to reuse requirements?

Understand what I mean by reusing requirements. I reuse lots of information and business knowledge from project to project. In fact, I spent a good amount of time earlier today explaining to a different team in my company the business rules and implementation logic of a set of functionality that my team implemented nearly 2 years ago. Why didn't I just give them the requirements documents? Simple, they were not actually reusable.

The requirements for the project my team did 2 years ago were actually written 4 years ago and were written back when my segmentation of requirement types was a lot more fluid (read that as 'poor'). I mixed implementation details with requirements. Shame on me! Yet, if you read a lot of requirement documents, this is what you find. Yes, these are probably poor requirements documents and NEVER would I write its kind again, yet its all I have from that project and its something that is meaningless to a team now implementing similar functionality in a different business area.

When I think about the problem of reuse, I figure that someone has to know a solution, or at least a better technique than what I know. I've heard every requirements management vendor under the sun promise such, but have yet to see one really deliver on that promise. Requirements are almost always tied with some project and not specific to the business.

If vendors can't get it right, what about the IIBA? Grab the BABOK and look in the techniques section for Requirements Reuse. What's that you see? Its empty? Look back at the prior few chapters and then forward at the next few chapters. None of them have a section without at least a couple techniques, yet requirements reuse is strangely blank. Why is this?

I'm not picking on the BABOK (I like it quite a bit actually, being a CBAP), but I'm using it as an example that even the most authoritative guide to business analysis can't provide any information on how to actually do this. Requirements reuse, just like code reuse, is hard and very possibly not worth our while.

The BABOK even talks about this when it says to "Identify requirements that are candidates for long-term usage by the organization." If you won't be using it again, and regularly, you might as well not bother. While well-formed requirements should be reusable, the amount of time, care and effort required to write reusable requirements could be better spent doing additional elicitation, analysis or validation.

So what about you? Do you regularly develop requirements with reuse in mind? Do you have a technique that the BABOK v3 should include? Let us know in the comments.

11 April 2011

Good luck. I hope your project goes well.

You have a project that is, quite frankly, a monster.

It's technically out of control. And by that I mean one month you might be tracking to plan against our goals, another you may be ahead, and the following we may well be significantly behind.

The reasons for this are pretty typical, possibly even classical:  Poor sponsorship, lack of clear goals, oscillating and poorly articulated requirements, lack of stakeholder management, and so on and so forth. In fact it checks every box in the doomed project checklist.

So, what is a smart person like you doing here?  It’s a combination of the challenge and the opportunities to experiment.

One the challenge front, You are sure many of us know the feeling.  You know it’s an almost impossible task, but you just can’t resist it.  Your personal measures of success and achievement are not exclusively about schedule, budget and scope.  They are more about the difference between your attempt at this project and the client's previous attempts, and maybe about growth in organisational capabilities, what your team get done versus what is reasonable to expect in these circumstances etc.

As for opportunities to experiment; this is your opportunity t test yourself and your ideas over a sustained period of time.  Maybe it will go on for a few years. After all, it has been in progress in one form or another for about several years before you got there.

Step by step you get to implement the tools and processes you read about here at the blog, at other blogs, in books and on forums and you get to see what happens. It’s a great opportunity to trial a wide range of different techniques on the one project and see what happens with each change. On a blank canvas. Given the chaotic nature of the environment you'll probably also get to trial some more radical ideas of your own and see how they work.

So far you've have been working at it for a few months and have learned several new things, not to mention reinforced some of your prior beliefs about how people work and how projects should be run.

Good luck.  Be brave and courageous.  Treat the people well.  And have fun.

Photo care of hosted cc at Flickr

7 April 2011

The Shopping Cart Quandary

Just down the street from my office is a very convenient Sam's Club that I frequent on a regular basis to pick up those necessary items you just can't get anywhere else. The most memorable trip I've ever taken there involved leaving with only two items: flowers for my wife (I buy her flowers regularly for no particular reason other than I can) and a case of Octoberfest. Watching the facial expressions of my fellow shoppers was hilarious and I carried out those two items in my arms.

On a more recent trip to Sam's I found myself in search of another odd item, a microwave oven. The one I had purchased from another retailer less than two years prior had already died and I had no desire to repeat that poor purchase again. I found a microwave at Sam's that would fit on my counter and underneath the very low overhead cabinets in my kitchen, put the box in my cart and headed to the front of the store to pay and leave.

It was a late night at work for me that evening, having been there until nearly 8pm finishing up a project. When I entered the store, there were many registers open and many had no line. There were very few customers in the store with me, but it seems as if my sense of timing is, as always, impeccable. When I made it to the front of the store, there were now only two open registers and about 10 people in each line. I was annoyed, but didn't have much choice in the matter as leaving and going to another store would only take more time than waiting in the line.

While I stood there bored, I remembered a blog post I had recently written about why the checkout line always seems to be so slow. About the time I remembered that post, along comes a store employee with a gadget that is known to retailers everywhere, but this time it was used in a way I did not expect: as a line-buster.

You may not recognize the term line-buster, but I almost guarantee you've seen one. Very busy fast food restaurants have been known to place an employee with a tablet PC or handheld device that connects wirelessly to the store point of sale to help place customer orders without the need for yelling into the microphone at the drive-thru. The concept in Sam's is similar; the employee scanned my membership card and then scanned the barcodes on the items in my cart. When I made it to the cashier, they swiped my membership card, the contents of my cart was priced, I paid for the order and left.

While this was a vast improvement to having a single person both scanning items and accepting payment, I can't help but wonder if a more efficient process would have been to have the employee with the barcode scanner open up another register and simply process customer's the 'old fashioned' way. Was the barcode scanner really faster in this situation? What feasibility studies were done to prove out this method? What metrics were produced to show that this method really was superior? If it is so much better, why isn't this the standard method for stores to use? Why not just have a bunch of people with handheld scanners and only a few people taking payment?

What options did the company think about, maybe even form an exploratory committee to review and then toss out instead of this option? Did an alternative come up for using RFID tags? Was a big scale to weigh the cart and then price by the pound/kilo seem just too crazy? What about having one of the industrial barcode scanners that UPS uses in their package sorting facilities that can scan all sides of a box at once?

I haven't (yet) come up with a better solution than the people at Sam's Club and I doubt I ever will. They're smart people and get paid well to think about these kinds of things. Still, it was an amusing way to pass an otherwise mind-numbingly long wait when all I really wanted to do was get out of there and get home.

What kind of tough, non-work problem have you tried to solve recently? Did you make it better or just hurt your brain in the process? Let us know in the comments.

6 April 2011

IIBA says Requirements Traceability is optional?

The BABOK says this about Requirements Traceability;
"Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to add value."  (Section, BABOK version 2.0)
I'm the most low doc guy you can get and still get a quality outcome and this is a clanger for me.  Requirements traceability MUST ALWAYS be done in one format or another on any project that warrants the name "project."

Traceability is an umbrella term for a number of auditing activities on requirements as they pass from concept to fulfilled, and one day potentially retired.  Here is what decent traceability auditing can do for you;

  • Maintain a focus on the mission of the project; if a requirement is not aligned to project goals, and is being shoehorned in by a stakeholder with a local agenda up-line traceability will give you a clear sign that there is an issue and a tool to defend your scope from the potentially contentions issue.
  • Monitor solution progress against goals; Traceability gives you the ability to monitor the progressive completion of requirements independent on the project management plan.  Traceability only measures things in black and white states of done, and not done.  You can choose in your local context what done means (So you could have testing layers as increments if you want.)  This gives you a real view of project progress and potential issues that another measurement model - say estimated effort expended/to go does not provide.

Now those two issues are enough along to afford them a seat at the Things you Must Do table.  But they also allow other benefits such as the ability to monitor cross team or feature dependencies, to spot when requirements are not sufficiently tested, and in my "Enterprise context" to help manage scope fallout - where the solution is going to fall short and so business process workarounds are going to be required.

Requirements Traceability is a MANDATORY activity in all serious projects.

Any questions?

5 April 2011

I'm taking one of these to my next Requirements Sign-off Meeting

This is, by far, the most useful tool I have ever seen to 'encourage' your users to approve a requirements document. Better Projects readers, I give you, the Pillow Mace. No word yet on pricing or availability, but the first meeting in which it is used will be LEGENDARY!

4 April 2011

Who approved the requirements for Google +1?

+1 icon
In a short word, no one. Ok, probably not entirely true; someone pretty smart came up with the idea, but it feels to me like no one really looked at how people use a search engine before the first version was released. If you're not familiar with Google +1, you can read the company's explanation, or you can use my shorthand as its really just Google's version of the Facebook 'Like' button.

Unlike the 'Like' button, +1 just doesn't seem to have a useful function in its current iteration. Don't believe me? Lets make a quick use case to explain why I feel this product just won't make it. The use case I'd like to explore is searching for the term 'user experience template'. I pick this as an example of something that doesn't quite fit (you can't template 'user experience') but its something that a complete novice to the field might consider. The case would go like this:
Look at the use case for a 'Like'... you see a big button 
  1. Open a new web browser window
  2. Go to ''
  3. In the search box, enter 'user experience template' and press enter. Google returns a list of search results.
  4. Click the first link in the search results in the middle of the page
  5. Review the page to determine if the result is useful for the query
In the list of search results returned in step 3, there is a +1 button to the right of all the returned results. This is where the idea of a +1 button fails. There are a few possible branches that this scenario could take, none of which result in a good use of +1.

First, the user could click the first link and find the exact right information they wanted. The page has everything: the right subject, the right level of detail, the right stuff. Sounds good, right? Let me just click that +1 button to rate the page up so anyone else who searches for this same topic knows that I already found the best page ever about the topic! Wait, where is that button again? Its gone!

Yes, that's right, the +1 button is back on the search page but I am already on the site that contains the content I wanted. For me to share my good find with the world, I must leave the exact place I really wanted to go. Does this sound right to you? It doesn't to me. It is rare when I search for a topic and find the perfect result (I'll get to other outcomes in a second), but when I do, what would motivate me to return to the search results, leaving the page with all the good information, just to click a button and then dive right back in to the page with the results I wanted in the first place? There is zero motivation for me to perform this action. None.

Second, the set of results returned by Google could have missed the point of what I was searching for entirely. This is pretty rare, but it has been known to happen. In this situation, there is no reason for me to ever press the +1 button as no link on the page deserves it. Here again, +1 is useless to me although the reason is different. In scenario 1, it was useless because it isn't accessible easily when I need it. In scenario 2, its useless to me because the content failed to return a good result for my inquiry.

The most likely scenario is that while my search terms made sense to me, Google likely only got close to what I wanted. The pages returned this time had some relation to what I really wanted, but either didn't hit the mark or the pages I look through (and its likely I had to look through many of them) are dated, have the wrong level of detail or are simply inaccurate.

This third case doesn't present a good use for +1, either. Yes, I could mark one or more of the results with a +1, as I return to the results page often in search of a better link. Yet, do any of these results really deserve a full +1? If the idea of +1 is for me to share things I really found useful, can I honestly say that any of these results were truly useful if I have to look at multiple links to find information that might come close to fitting my search query? Are they really a +1 or something like a +1/4?

Why 'Like' Works and '+1' Doesn't

Lets contrast the behavior of +1 with that of the Facebook Like Button. One argument might be that the Like button is simply a better detector of what is useful. I would dispute this. Go to your Facebook page, view your profile, scroll down to Activities and Interests and expand the Other section. This is a list of the pages you 'Like'. Do a quick count... of the ones listed there, how many have you visited more than 5 times? Now count how many you have there in total.
If you're like me, and according to some non-specific studies you probably are, then most Likes listed there are places you never visit anymore or you never really visited in the first place. Frankly, Likes are cheap, but that is exactly the point. The effort to use Like is simply click the button that is right next to whatever it is right in front of you. There is no backing up to a search page, no sifting through a list of results. No effort except a mouse move and a button click. Easy.

Requirements for a Usable +1

The idea behind +1 is sound, namely to get your users to help other users say what is useful; what is valuable; what is good. The problem is that doing so falls apart because of a poor workflow. What +1 needs is, frankly, its own button. When Facebook created a Like button that anyone could put on their web page, they understood that making their 'share' button accessible to users in the moment is the key to it being used.

Consider the grocery store to see this behavior in action. Where do they place the candy and trashy magazines? Right next to the register, right within reach. Sure, there's a dedicated candy isle for when you really need the big fix (the same as the location of the +1 button in Google search results), but the return on placing the candy right at your fingertips (Facebook Like button) is much higher.

Yes, I'm sure that, if it doesn't already exist, Google has an embedded version of +1 coming to compete with the Facebook Like button. Twitter and LinkedIn both have one, so why not Google, too? In fact, I would not be surprised if the +1 embedded button exists, but hasn't been rolled out yet simply because they don't want to be the forth entry into that space. It will come, but just not yet.

If Google didn't want to be forth in the list, there are a few things they could have done along side the search result placement of the +1 button. Google has a fantastic web browser in Chrome. Adding a +1 button to the toolbar, right next to the yellow star bookmark button, would have been trivial but infinitely better than +1 in the search results.

But a button in Chrome only gets them about 11% of the worldwide browser share.  For the other 89%, they could have done other more invasive, possibly destructive, methods to get +1 in front of user's mouse pointers. They could have done an annoying +1 hover over that embeds itself on top of the page that loads after search results are clicked. They could have loaded the linked page in a frame with a new toolbar at the top or bottom of the page that included a +1 button. These suggestions are worse than having an ineffectual +1 button as they frustrate users, but they are alternatives that could have made +1 more useful than it is now.

My preferred solution would be to combine +1 with the Instant Preview feature. They have, to the extent that the instant preview and +1 buttons are right next to one another on the page, done this, but Google missed out in making these two work well together. To activate the instant preview, you have to click the magnifying glass button, scan the preview and then move your mouse back to click the +1 button. The problem here is that my eye has been distracted from +1 because I'm now looking at the preview and not the buttons. 

Its the same problem as if I clicked the link and went to the linked page, just slightly less difficult because the button is still technically still available. What should have been done was to incorporate the +1 button into the preview itself, say in the '<' that points back to the selected link or again as some kind of translucent hover on top of the preview page.

Fixing +1

Will Google change +1 to make it really useful? Your guess is as good as mine. Google is known for putting out half (or 3/4) baked ideas out there to see what works. I actually like this about them; they're more than willing to fail many times to find that one thing that really works. I wish I could have been the analyst who worked on this project because I feel +1 has potential to be really useful, especially if I could see links my friends, those people in my Google Contact list, have found useful as well. Maybe when (if) Google's social network finally lands, we'll see the genius behind +1 that is currently hidden. One can only hope!