Thoughts of the Eternal Bachelor

Embracing Constraints

2012-01-24T17:00:00.000-05:00

This post originally appeared November 18, 2011 on BetterProjects.net

Whenever you hear the word 'constraint', your mind is probably like mine and you picture a set of handcuffs. You want to do something for your stakeholder, but because of some limitation, you are unable to deliver to them what they really need.

If you're passionate about what you do, this likely frustrates you. What you really want, more so than anything else, is to exceed their expectations, delivering them the most perfect solution in the world. When you are unable to do that, you probably feel some resentment, not toward your stakeholder or yourself but to whoever imposed that constraint on you.

But it occurred to me during my drive home today that maybe we've all got the wrong image of constraints in our heads. Maybe, instead of bemoaning the limitations that constraints put on us, maybe we should learn to embrace constraints as a good thing. Don't believe me? Lets think about a couple types of constraints and see if a shift in viewpoint could change the way we approach a situation.

Lets say that one of your company's rivals just released a spectacular new product that has instantly made your company's products look obsolete. The finance team has done a few calculations to show that revenue projections will slip by 25% by the time your next new product is released that will return the market to its previous parity. Your product development team has started on a project to create that new product, but is months if not more than a year away from completion.

At this point, you've got a problem. Marketing suggests changing the target market. The sales guys are in favor of slashing prices and moving more units. The production group screams in protest; that they can't keep up with orders now, much less at larger volumes.

You're asked to figure out what could be done to keep the company going until the next big product is done.

First, you recognize a time constraint. The project team needs a year to get a totally new product out to market; one that will, you hope blow away your competition... but your company doesn't have a year to wait. The right question to ask in response to this type of constraint is what can be accomplished quickly that can, if not return the market to parity, to at least get your product to be more competitive.

Its time to start looking for easy options: change the product's color, add in cheap bundles to increase the value of the product, look for opportunities to co-market the device with related products. In short, its time to start thinking of what you can do within a reasonable period of time and not what you can't do with all the time in the world.

Next, you recognize a cost constraint. If finance is projecting such a dire sales slump and your company doesn't have the free cash to keep running at the current cost structure until your new product can turn sales around, its likely you won't have the staff or budget to finish that project in the projected year. If your company cuts staff, the project will take longer. If the budget gets cut, your quality is likely going to suffer.

One way to combat a cost constraint is to figure out ways to mitigate the loss in sales. One way to do this is to offer incremental improvements in your current product that can be delivered in a very short time frame. Change that analog display to a digital one. Reconfigure your site layout to remove confusing features so the user can focus on what is really important to them. Put together a list of the things consumers most dislike or would most wish to see included in your product, prioritize them into a list and determine a strategy to make those things happen.

Last, what about a resource constraint? What if your company's huge project is pulling in all resources while other products of lesser importance fall by the wayside. What do you do when what you are responsible for is having all its resources pulled into a big resource black hole?

You can look for other resources, but you're not likely to find them as the company has already realized its not going to have the money for the big project, much less your small one. You know you've got customers using your small product daily, but they're not getting the support your sales team promised them.

It can be painful, but sometimes your best option is to simply embrace the constraint. Maybe the more time you give to the big project, the faster it reaches completion and the sooner it is your resources come back to working on your project. There are times when all you can do is give in to the constraint.

So what constraints are you dealing with in your organization? How are you dealing with them? Let us know down in the comments!

My love/hate relationship with 'Being Busy'

2012-01-18T18:50:00.005-05:00

This post originally appeared November 14, 2011 on BetterProjects.net

To say that my job has been chaotic over the last 3 months would be a mild understatement at best. I think the late, great Douglas Adams can best sum up the last few months for me:

I love deadlines. I like the whooshing sound they make as they fly by.

Back about 3 months ago, I went into a meeting with my department's VP, expecting to walk out with 1/3 fewer team members and 1/3 less responsibility. I was overloaded as it was and had been told my job needed additional focus on a single, strategic project. What really happened was I walked out with 33% more team members, 50% more responsibility and an entirely new reporting structure. Needless to say, I was a bit surprised, but pleasantly so.

This role has been a lot of fun and includes a lot of additional challenges, all of which are in the direction I want to be taking. Its kind of funny that the things in my job I least enjoy (although I do enjoy all parts of my job, its just that I enjoy some parts more than others) are the ones that are most related to my old role. Nothing bad there at all; I just really enjoy the new stuff I'm getting to do.

But along with all those additional challenges come the realization that I can't do it all; that I can't be everywhere at once. Not that I could before, but the realization is just more obvious now than before. I'll be the first to admit that I'm stressed out, often frazzled and in major need of additional sleep. My mind is racing all the time and my focus is fractured more than a glass vase dropped from the Eiffel Tower.

Which is why this blog post, about the effects of being 'busy' rang so true to me. There were a few lessons that popped out at me from reading this:

First, if you're going to be the best at what you do, be prepared for a LOT of repetitive work. That doesn't necessarily mean filling out forms or shuffling paper, it means spending the majority of your productive time being productive, not just going through the motions. This is hard; it requires drive, determination and all kinds of overused and poorly understood buzz words.

Second, you've got to focus on that work. This is the part of the article where I realized that my analysis skills were atrophying from lack of use. I've spent the last few months in meetings 75%+ of my days. That's not necessarily a bad thing, but it does mean I have less time to spend in focused practice on my actual role.

Yes, much of what is accomplished in those meetings is also part of my new role. One of the things that I enjoy about my organization, especially compared to some really dysfunctional former employers, is that we actually seem to accomplish things in meetings. Wasting every hour of the day in useless meetings really stinks, so I know I'm fortunate to not spend the majority of my time that way now.

Which is where I come to the next lesson of this article: attitude. There have been times, especially during those meetings I feel are rolling around in circles, where nothing really gets accomplished, that I just want to storm out and 'go get some real work done'. This rolls over into my non-work life as well. My evenings have been filled up with processing email that wasn't even looked at during the week. I'm a firm adherent to the Inbox Zero philosophy, so a box with dozens of unread emails makes me twitch like crazy. Its something I just can't help but comb through, no matter how much I would rather be reading a good book (or writing on this blog).

And this brings me to the last point, one not brought up by the authors of the study, namely that being great requires sacrifice. If the 'average' players in the study practiced their instrument 2 hours per day and the 'elite' players spent 6 hours in study, that's 4 hours the 'elites' could have spent elsewhere, but chose not to do so. Being great, or at least doing great work, means not doing non-great things.

I think it is this last point that is what is the hardest thing for me personally about my job. I am thankful that I get to spend my time doing a lot of good things; I just wish I got to spend more of my time doing great things.

So that, in a very wordy nutshell, is exactly why I haven't been spending time on this blog in a couple months. I've missed you all, Better Projects readers. I've missed discussing topics near and dear to the hearts of those of us who do projects. In short, I missed trying to work out how to be great with you all. Lets not be apart so long ever again. I won't promise not to stray for short times, but I do promise to always return.

Jobs on Generalists

2011-11-18T17:00:00.000-05:00

This post originally appeared September 29, 2011 on BetterProjects.net

One of the things I look for when hiring a business analyst is a good grounding in liberal arts. That might seem odd, given that business analysis regularly lives at the intersection of business and technology. Yes, those skills are vitally important and it is difficult, but not impossible, to be a good BA and not have both. But a great BA is something else entirely.

You know how to put together the most perfect requirements document? An administrative assistant could probably fill out the template if given the words.

You know how to interview people to find out their problems? Yeah, a psychologist gets paid to do that as well.

Can you follow someone around the office, watch what they do and report all that back to a developer? Its called a video camera.

We prize hard skills in a BA. Its difficult, if not impossible, to do the job with at least some rudimentary understanding of these skills. Some of them seem to the outsider to be nothing more than basic problem solving skills, and when practiced at the entry level, really are not much more than just that. As we progress in our career, we recognize that to really be great at what we do, we have to move beyond just problem solving.

That's where it pays to be a generalist. That's why this quote resonates with me:

It comes down to trying to expose yourself to the best things that humans have done and then try to bring those things in to what you’re doing. Picasso had a saying: good artists copy, great artists steal. And we have always been shameless about stealing great ideas, and I think part of what made the Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to be the best computer scientists in the world.
—Triumph of the Nerds, PBS, June 1996

One of the best ways to become great at being a BA is to shamelessly steal from everyone. The more knowledge you have packed away for a rainy day, the more likely you are to have the necessary nugget of information that is the only solution to the given problem.

So that's the secret sauce, a wide and varied experience. The more you travel, the more you read, the more you study, the more you experience, the more likely you are to have the foundation for a killer business analyst. Open your mind, broaden your horizons and reach beyond your grasp.

NoSQL and the impact for System Analysts

2011-11-15T17:00:00.000-05:00

This post originally appeared September 26, 2011 on BetterProjects.net

I love Ars Technica. Its a fabulous site. For what is the first time I can remember, they actually used the words 'business analysts' in a post, so I was naturally drawn to this post about Teradata combining SQL and NoSQL databases into a single product.

In all fairness, the article really isn't about business analysis, but it does bring up some interesting points for those of us who are business analysts that stray over into the system analyst realm. I've been curious about NoSQL in the past and done a small bit of reading about Hadoop and Big Table in the past, but really didn't know a lot about how either system really works. SQL is something I get, and while I am by no means up to the caliber of a qualified DBA, I can write some mean select statements.

My day job captures a lot of 'little' distributed transactions. Our back-end database servers aggregate that data and I am on occasion called upon to do some research, either to find a problem or to figure out what to do for the future. To do this research, I always use SQL. I realized that 'NoSQL' systems obviously didn't use SQL to find data, but I had no idea what they used instead.

This is why the Ars article was so enlightening to me... there really isn't an alternative to SQL, except code.

That's disheartening to me. Yes, these large data structures make it possible to store a lot of data in a lot of places, but it clearly is a step backwards in allowing anyone who is not a developer to freely access that data. These products require me to either learn a programming language or use programming-like syntax to find the data I need. There's a reason I'm not a programmer and requiring a programmer to give up time to help me find information is a really terrible option.

The Teradata solution, while a bit light on the documentation details, seems to provide a translation layer that either converts SQL into a map reduce language or vice versa. I expect that there is likely some performance degradation in this type of translation, but given that business analysts are unlikely to be performing a large number of searches repeatedly and overlapping on a single data set, I expect that the translation would be fairly minimal.

When companies come out with tools like this that allow developers to maximize the potential of an application but enable analysts to still perform their duties, I can't help but applaud. While I don't know if I will ever have the opportunity to work with this product, I like that business analysts are considered to be important enough to organizations to have tools created that enable them to be more effective in their work.

How a BA is like a print newspaper

2011-11-11T19:59:00.001-05:00

This post originally appeared September 19, 2011 on BetterProjects.net

One of my favorite bloggers right now is Timothy B. Lee. Several months ago (yes, I'm working through my backlog of articles to write about) was about how the online news business had caused major disruption in the business model of traditional news media. If you've watched any media in the last decade or so, you can't help but see this as true. 10 years ago, I had already started consuming a large portion of my fairly small news consumption online. Its been 6 years since I disconnected my cable TV service (but kept the cable internet service) and now, the entirety of my small news consumption is done online.

What makes me interested in this, despite it being about news coverage which I am almost completely uninterested in, is the way in which I think it parallels the work I do as a BA. That might seem like quite a stretch on the surface, but hang with me a minute and think about my logic. First, lets look at a couple quotes from Lee to see where I'm going with this:

It’s only a matter of time before somebody figures out how to apply the low-costs tools of the web to high-value reporting. And the nimble, collaborative nature of the web means that successful models will be copied rapidly... But that was a misunderstanding of the economics of disruptive technologies. They always start at the low end of the market, but they rarely stay there.

One of the things (but by no means the only thing) that BAs do really well is to help our business users relate to technology and how it can help our businesses thrive. In a way, our jobs are dependent upon technology being a 'black box' to people forever. When our customers no longer need us to explain technology or how technology is created to them, then we'll not be in the jobs we've been in for years now.

Don't get me wrong, I think this will be a long time coming, probably 2-3 generations at the least, but I believe it will come. Lee gives us the reason in that quote above; disruptive technologies always start at the low end of the market.

The last decade has seen a large amount of work done on helping the consumer become more acquainted with and accepting of technology in their everyday lives. In some areas, cell phones, music players, the change has been striking. The mp3 player as it existed a decade ago held very few songs and did little else than play music. Now they're so large you can hold not only your music collection, but movies, pictures and even create digital content on a device that fits in your pocket with room to spare.

These consumer devices are the low end of the market. Remember the first time you had to show someone how to use an mp3 player? Now look at an iPod touch and you'll realize that one of the things that is great about the progress of the last decade is that we don't have to show someone how to use the device (at least for the common things).

Disruption has been tracking in the low end of the market for sometime; now its starting to move up the chain. For this, look at all the project management apps that are eating into Microsoft Project's territory. Tools like BaseCamp allow less knowledgeable PMs a tool that, while it may not have all the bells and whistles of Project, can help them successfully manage a project without needing to attend weeks worth of classes first.

But so far, we're not really into the territory of what BAs do with technology, namely when it comes to enterprise applications. While the trend isn't quite yet as encroaching on us as it is the lower segments of the market, it is coming up fast.

I used to work with ERP and CRM applications when I started out almost a decade ago. Those apps I worked with then look largely exactly the same today. Sure, engineers added some backend functionality, updated for modern browsers and tacked on a few modules, but the apps themselves are largely unchanged. What is different are the applications that are their main competition. 10 years ago the only competition these applications had were other enterprise applications. Today, anyone with a Kickstarter account and a good enough idea can take the large, incumbents on head to head.

The thing is, I don't have a problem with any of this change. If my role as a BA disappears in 30-40 years, even if I am long retired, I'm good with that, so long as whatever replaces it is sufficiently better. If we get to the point where children born around the time of my 80th birthday can 'get' technology as intuitively as kids born 600 years ago 'got' farming, that's great.

In the end, its the skills of a BA that will live on, even if the role itself is eventually discarded. Technological change happens, no matter if we accept those changes or not. If we don't, someone else will and they will eat our lunch. In our role, we are uniquely equipped to not just deal with change, but to cause it. As long as we continue to do that, our skills will always be needed.

Daring Fireball: Universe Dented, Grass Underfoot

2011-10-06T20:38:00.000-04:00

By far, the best tribute I've read.

Daring Fireball: Universe Dented, Grass Underfoot:

Why wear this grass-stained pair for the keynote, a rare and immeasurably high-profile public appearance? My guess: he didn’t notice, didn’t care. One of Jobs’s many gifts was that he knew what to give a shit about. He knew how to focus and prioritize his time and attention. Grass stains on his sneakers didn’t make the cut.

'via Blog this'

The Cult of Done Manifseto

2011-09-22T17:00:00.000-04:00

This post originally appeared September 15, 2011 on BetterProjects.net

I love finishing something. Being able to check that item off my list is an awesome feeling. I'm a huge fan of the Inbox Zero concept because of this. This is why items like the Cult of Done Manifesto makes me so happy. For those who don't want to click the link (although I suggest you do for the cool poster), here is the short text of the manifesto:

There are three states of being. Not knowing, action and completion.
Accept that everything is a draft. It helps to get it done.
There is no editing stage.
Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
Banish procrastination. If you wait more than a week to get an idea done, abandon it.
The point of being done is not to finish but to get other things done.
Once you're done you can throw it away.
Laugh at perfection. It's boring and keeps you from being done.
People without dirty hands are wrong. Doing something makes you right.
Failure counts as done. So do mistakes.
Destruction is a variant of done.
If you have an idea and publish it on the internet, that counts as a ghost of done.
Done is the engine of more.

Point #2 is by far my favorite of this chart. Its freeing. I know my PM friends get frustrated with me when I say a task is 'pretty much done'. This isn't a situation where I'm trying to get them off my back about the status of a task, but a way of saying that its as done as I know how to make it. It is an acceptance of the large amount of ambiguity in life.

Point #4 just makes me laugh.

Point #10 is so true. That doesn't mean that you don't have a new task that looks exactly like the one you just failed at, this time to do it correctly, but it does mean the original task is done.

Point #12 is pretty much this entire blog. :-D

BLS Outlook for BA and PMs

2011-09-19T17:00:00.000-04:00

This post originally appeared September 12, 2011 on BetterProjects.net

One of the bloggers I follow on Twitter, who has nothing to do with our chosen field of work, pointed me towards the website for the US Bureau of Labor and Statistics. While there, I spent some time reviewing the job prospects and salary ranges for BAs and PMs (which I am going to assume fit into the Computer and Information Systems Manager category).

Some interesting quotes and takeaways, first from the BA page:

Employment is expected to increase much faster than average.
Excellent job prospects are expected as organizations continue to adopt increasingly sophisticated technologies.
Employers generally prefer applicants who have at least a bachelor's degree; relevant work experience also is very important.

Its good to be a BA in today's world.

analysts are increasingly working with databases, object-oriented programming languages, client–server applications, and multimedia and Internet technology.

It seems as if the BLS feels BA jobs are becoming more technical instead of less.

Computer systems analysts held about 532,200 jobs in 2008. Although they are employed in many industries, 24 percent of these workers were in the computer systems design and related services industry. Computer systems analysts also were employed by governments; insurance companies; financial institutions; and business management firms. About 30,300 computer systems analysts were self-employed in 2008.

Those job numbers are obviously for the US, so your mileage may vary in your country. Still, that means there are a lot of BAs out there in the world. I would bet there are even more doing the work, but just don't have the title.

Lastly, some salary info:

Median annual wages of wage and salary computer systems analysts were $75,500 in May 2008. The middle 50 percent earned between $58,460 and $95,810 a year. The lowest 10 percent earned less than $45,390, and the highest 10 percent earned more than $118,440.

We won't, generally, get rich from this job, but will do pretty well for ourselves. Not bad.

Now lets look at some points for PMs.

Employment is expected to grow faster than the average for all occupations.
A bachelor's degree in a computer-related field usually is required for management positions, although employers often prefer a graduate degree, especially an MBA with technology as a core component.
Many managers possess advanced technical knowledge gained from working in a computer occupation.
Job prospects should be excellent.

As with the BAs, PM roles seem to have a good future to them. But there is a bigger downside for PMs than BAs.

Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week.

The number of hours worked for PMs seems to be higher than for BAs.

Computer and information systems managers held about 293,000 jobs in 2008. About 16 percent worked in the computer systems design and related services industry.

When compared to BAs, there are fewer in the management field, but those jobs seem to be spread out over a wider set of industries.

Median annual wages of these managers in May 2008 were $112,210. The middle 50 percent earned between $88,240 and $141,890.

In return for those longer hours and additional responsibility, it seems that PMs do command a higher salary.

There was one thing I noticed that were not discussed in either of these profiles. In the education section, there really wasn't any mention of professional certifications (CBAP and PMP). While there was a significant amount of discussion of college, graduate and technical degrees, the role of certifications was largely ignored. With the popularity of the PMP and the growing popularity of the CBAP, this did surprise me.

What do you think about these articles and what they say about our chosen professions?

We are losing our listening

2011-09-15T17:00:00.000-04:00

This post originally appeared September 6, 2011 on BetterProjects.net.

Great tips here, but best quote is this:

Many people take refuge in headphones, but they turn big public spaces like this, shared soundscapes, into millions of tiny little personal sound bubbles. In this situation, no one is listening to anyone.

Unlocking Project Achievements

2011-09-12T17:00:00.000-04:00

This post originally appeared September 2, 2011 on BetterProjects.net.

As I've talked about in the past, I'm a pretty big fan of social media and especially the ways it can be used as a driver for projects. One of the areas of social media that has always seemed a bit silly and frivolous is the concept of 'badges'. Foursquare was my first experience with them, but now it seems every social media site (except the juggernaught of Facebook) has them. Even non-social sites, like Google News, has them.

But what about for those of us who work on projects? Should we get badges? Over at the Red Earth QA SIG blog, they seem to think it might not be a bad idea. The post lists some badges that QA analysts could earn, some of which are pretty funny...

Dead Parrot - You have an extremely difficult time convincing the developer that their ‘fix’ does not, in fact, fix the issue. After several hours of showing all the ways that the issue still exists, you are offered a slug.Jar Jar - Every bug you submit requires clarification. For this, you are made team lead.

I've been kicking around ideas for this post for a while, trying to find some awesome badges for BAs and PMs, but I'll be honest, my funny-bone doesn't work well with lists (or at all, if you believe most people). So here's what I've come up with. Use the comments and add your own!

General Badges

Newbie = Congratulations! You just landed your first project. Here's a helmet and a yo-yo. Go forth and conquer!
Old Hand = 25 projects under your belt. Most people never make it here, but you're a survivor.
Grey-beard = You're the person who makes Old Hands quiver in fear. With well over 50 projects down and still not retired, you serve as a warning to others what can happen when you've been doing this way too long.
Wide-load = Working more than 5 projects at any given time? That's an average of 8 hours per week or less devoted to any single project. Do you feel that anything is being neglected (besides your personal life)?
Extra-wide BC = Your business card width had to be specially sized due to the number of titles you included after your name.
Social Butterfly = You've checked in at 5 or more industry events in the last month.
JetSetter = You've traveled for business at least 5 times this month.
Home Office = You performed at least 1 hour of work from home every night of the week.
Drop the iPhone! = You answer emails between the hours of midnight and 4am.
Name Dropper = "This one time, when I worked at XXXX company, we did..." is heard from your mouth at least 3 times in the same week.
Dirty Harry = You're a hired gun, brought in for your specific expertise... in killing projects.

Business Analyst Badges

Smarty-Pants = You have your CBAP or CCBA.
Verbose = Your requirements document is 5 pages or more in length to change the label on a field.
Buffy, the Requirements Slayer = Your 'stake'holder analysis charts are so comprehensive they include the cell phone #s of the company's janitorial staff.
Scope Creep = Can only be awarded to you by a PM. Occurs when you slip in additional requirements on 2 of the last 3 projects after sign-off has occurred.
Cartographer = You've created flowcharts for everything, including one on how to decide if you need to go to the bathroom.

Project Manager Badges

4-Eyes = You have your PMP, CAPM, PgMP, PMI-SP or PMI-RMP.
Under Pressure = You are the king of schedule compression. At least 50% of your resources on a given project have tasks on the critical path.
Braaaaaains = You've been the PM on this same project for 5 iterations. Its a zombie. It won't die, it keeps coming back every time you think you've killed it even if you removed its head.

Two articles that have inspired me

2011-09-08T20:03:00.001-04:00

This post originally appeared August 23, 2011 on BetterProjects.net.

Been a busy couple weeks at the day job, so my writing time has been dramatically reduced. To tide you all over until I can return to writing (hopefully this weekend), I thought I'd share with you a couple quotes from articles I've read recently that have inspired me.

First up, Alan Cooper, who I've shared with you guys before:

You can't save your way to creativity. Creativity isn't necessarily expensive, but it's a human rather than industrial activity, and when you put external cost constraints on it, you put it in an artificial box that simply kills it. Creative people need unfettered time and attention to solve difficult conceptual problems.

Remember this quote the next time you're told to 'think outside the box' and then are told 'we need this by tomorrow morning'. Sometimes the 'spurs' can get an answer, but it is hardly likely to be the creative one you really need.

Next up is another designer, this time a new person to me, by the name of Craig Grannell.

Only by embracing new technology and then seeing what we can do with it can we ensure we don’t remain stuck in the past. And for everyone moaning about the lack of obvious utility in tablets, people once said the same thing about computers—and look where that got us.

I was the first person to roll my eyes when the iPad was announced. Nice toy, but it will never replace my laptop. I just don't have a use case for it, I would say. You can't create on it, pundits would scream.

Guess which computing device goes with me to 90% of meetings now? You guessed it, the iPad. The only time I take my laptop is when I need to host a webinar or display a secondary screen while taking notes.

People, and I, myself was at one time included in that vague generalization, misunderstand the point of using tablets to create with. We're concerned with creation as it is defined today, not creation as it will be defined 10 years from now. Tablets are ushering in a completely new way to be creative; they are not intended to compete with what we call creation today. Its been less than a year and a half since the first non-PC tablet was introduced and the ways people are using it to create blow my mind. I can't wait to see where it is 10 years from now.

A Bicycle for our Minds

2011-09-05T17:00:00.000-04:00

This post originally appeared August 29, 2011 on BetterProjects.net.

This is exactly the same reason I enjoy being a BA that works with technology.

Warring Against Organizational Failure

2011-08-22T17:00:00.000-04:00

This post originally appeared August 11, 2011 on BetterProjects.net

I'm not a fan of Michael Arrington of TechCrunch. Leo Laporte, famous face in technology circles and all around really nice guy, doesn't think very highly of Michael, either. (Warning, a small bit of NSFW language included).

It takes a lot to make someone as nice as Leo get that mad. Still, even a jerk like Arrington can, on occasion, really get something right. He did so recently with this piece on why the expense reporting process at his parent company, AOL, is so terribly restrictive.

Last night, for example, I was cleaning up my desk. I have an envelope I keep business expenses in. There was a hotel bill for a trip when my AOL issued credit card was turned off for the day. Some taxi expenses and a restaurant bill. I looked at them, thought about the process for turning those expenses in and then having to defend them via a phone call (Heather would probably save me from this, but there goes an hour of her time). So I did the rational thing. I shredded those receipts – around $1,500 – because it wasn’t worth the pain.

I don't feel much sympathy for a guy who has enough cash on hand to just toss out $1,500 worth of legitimate business expenses paid for out of pocket, but were I in that same situation with those kinds of bills for a single day, I would have moved heaven and earth to get that reimbursed. What did get me was why AOL has such draconian policies:

Then today I was talking to someone at AOL about nothing in particular, and he brought up his own troubles with expense reimbursement. I asked why the company is so crazed about it.

Enter Gregory Horton. This guy was head of HR at AOL a decade ago when the company was still part of Time Warner. His story is amazing. He apparently set up a dummy consulting corporation and was billing AOL $100,000 a month for made up work. All in all, the company lost over a million dollars to Horton, or so the story goes.

This reminded me of one of my former employers who had policies as absurd, yet in a different way. I once had an expense report worth about $6,000 (three weeks in France) rejected causing the payment to American Express to be late, resulting in a late fee. Did it get rejected by the hundreds of dollars of wine purchased at multiple dinners? Nope. What about the multiple hotels I had to stay at because rooms were hard to find (and expensive) for those weeks? Nope. Surely it was the last minute purchase of an airline ticket! Nope.

A $2 parking fee was missing from the receipt packet. No, I am not kidding.

At some point, you have to just wonder about what rule someone broke 10 years ago that would cause so many process controls to be put in place that would reject an entire expense report because of a receipt that was completely immaterial to the larger goal of my project. So when the late fee came in, that I was responsible for, what did I do? Its called inflating costs on my future expense reports to cover the late fee caused by idiotic processes.

Was that underhanded of me? Most assuredly. Yet, if you look at how poorly the rules were instituted, they were giving me incentives to monkey with the system. If someone had bothered to think about how trivial that parking ticket was when compared to the total of the expense report, there would have been a 'minimum % rule with a maximum value rule' instituted that would weigh the time it took to fix the missing data and the potential late fees against the value of the receipt. Its an adaptive rule that recognizes people's time and that some things simply are not worth arguing about.

Its situations like this that we, as project people, need to remember. We're the ones who are looked to as trusted advisors by our business partners and its our job to make sure bad rules like this are caught before they are institutionalized. Work with me to fight for the rights of our users and fellow employees. Down with bad rules.

Eating Rotten Fishheads

2011-08-18T17:00:00.000-04:00

This post originally appeared August 8, 2011 on BetterProjects.net

I've blogged a couple times about Alan Cooper in the past, and will likely do so again in the future. One of his recent posts, from his company's blog, had a really great quote I needed to share with you all:

I do not believe Microsoft's assertions that the ribbon is easy to learn. If you feed someone rotten fishheads for a while, then switch them over to a diet of fresh fishheads, they will be happier. You can then tout the statistical "fact" that "users prefer fresh fishheads," even though the truth is that they HATE fishheads. That, I believe, is how Microsoft gets its rationale for UI changes.

Cooper is discussing his recent switch from Office 03 for Windows to his new Mac. He hates Office's ribbon interface, his point being that Microsoft's claims of it being easier to use than the old interface is bogus. I agree.

His broader point though is that if you're changing something from bad to merely less bad, you shouldn't go around telling everyone about how great the new is. Its not. The cognitive friction you force on your users with a completely revamped interface is not worth it when your improvements are so minimal compared to the learning curve.

This came to mind as the meeting I sat in all day today spent a significant amount of time discussing the look and feel requirements for a new application we're considering having a vendor create. Our current system uses a series of accordion menus down the left-hand side of the screen. Last summer, when that system received an upgrade, the new version allowed for pull down menu navigation across the top of the screen. Assuming that people were likely more familiar with that type of navigation, the default was switched to the pull down menus.

It was resoundingly hated.

See, the new navigation style really wasn't any better (or worse) than the left-hand menus, it was just different that what people were used to using. Had the new navigation system been substantially better, maybe with large icons that can expand out into sub-folders, such as is seen with the iPad, then maybe the user outcry would have been much less.

When you're looking to change something that is a known quantity for your users, always make sure that the change is really worth it to your users prior to making. But how do you know the change is worth it?

First, ask around to see if anyone is up in arms about it. Don't ask subjective questions like, "Do you like navigation?" but ask more focused questions such as "Do you like left handed navigation or menu bars?" You're more likely to reduce the 'noise' in answers and get to the real meat of the discussion. The flip side of this advice is to make sure you really do touch on areas that could be of real concern. If you miss asking about the real problem, you wasted everyone's time and are no better off than before you started asking questions.

Next, place a value on the change. Does it save your stakeholders a lot of time? A lot of money? A lot of frustration? Define what 'a lot' really is! If you have 10 users and your change will save them only a few seconds a month, it probably isn't worth making the change UNLESS it removes something that is so incredibly annoying that you build a lot of good will. On the other hand, if you have 10,000,000 users and it saves each of them a few minutes a month, then the value of the change is very high.

Now, determine the cost of the change. There are lots of costs here. If its a system change, you've got to calculate the cost of the stakeholders to explain the desire, the analyst to figure out the best way to fit it into the existing process, the developer to code it, the testers to test it and the Ops team to deploy and support it. Your users will need to be trained on the new function, that will add to your cost. If the process change is significant due to a vastly changed process, will they be able to learn it and do so quickly? Don't forget about the opportunity costs, either. While you're making this change, what other changes are you forgoing that could be less costly?

Finally the hard part... determining if the change is really worth it. You take the value, subtract out the cost and see if you've got anything left. Even if you come out with a positive value here, remember that if the value is very small, then it may still not be worth it. The goal here is to provide your stakeholders with a significant positive value, one that is large enough to overcome their fear and reluctance to change.

The US Postal Service... Reloaded.

2011-08-15T17:00:00.000-04:00

This post originally appeared August 4, 2011 on BetterProjects.net

Part of me feels bad, picking on an organization like the USPS. Then the rational part of me steps back and realizes, who better than to take on than an organization with so many problems. Who else is in more need of some new ideas?

The organizations issues are numerous:

A large debt load in the form of 31,000 local offices
A large pension fund to maintain for retired employees and future retirees
A declining revenue stream
A mission to serve all parts of the US, even those that are extremely remote and vastly unprofitable.
A workforce that works more days (six) than most citizens (even if their days are often shorter than the standard 8 hour day)
Increasing direct costs in the form of increasingly expensive gasoline
Declining usage due to many of its core customers moving away from print and to digital distribution

I could go on, but I think you get the idea. So now I would like to float a few ideas that I think might help the postal service survive, or even thrive, in the future. I'm definitely not an expert, although my day job does give me a lot of knowledge about the economics of delivery, but that's actually kind of the point.

To structure my ideas, I'd like to focus on a coupe classes of ideas. First up is cost reduction:

Restructure your pension fund. Take a lesson from the automotive companies and pay out a lump sum to some other entity to pay for retirees. Its painful in the short term, especially since you are already deep in debt, but it frees you for the future.
For decades, you've invested in OCR technology to help you sort mail with less human involvement. Progress has been slow, but you're getting there. Make it better; partner with someone who has done a lot with OCR recently, namely Google. Yeah, their email application is part of what's killing your business, but if anyone knows how to interpret the chicken scratch we call handwriting today, its probably them. Yes, they will exact a price from you, most likely in terms of access to wire up your delivery vehicles with tracking devices for multiple purposes (traffic patterns, better street maps, whatever), but you've got to make a deal somewhere and these guys are the least of your bad options. In the end, get your sorting process up to an unbelievably high standard.
Don't like my OCR idea? Fine, kill stamps. Make all postage required to be digital. Make people enter the delivery address on your website (or self-serve kiosks in your retail locations) and print postage on demand. Make them 3D barcodes. Do whatever you need, but kill stamps.
Speaking of kiosks, add more to your retail locations and make the software not suck. I can figure it out myself if you guide me through it. I figured out the self-serve checkout software on the ATM and at the grocery store, I'm pretty sure I can do it for my package as well.
One area I can't really fault you in is package routing efficiency. Sure we could all do better, but you're pretty good. Learn from the Japanese car companies; make small changes, continue to tweak and drive out costs.

But cutting cost is only half the battle. What about revenue?

You've got great retail spaces. Use them. There's a reason FedEx purchased Kinko's and that UPS purchased Mailboxes Etc. Learn from your younger siblings; expand your vision. Don't make the run to digital like your failed attempt to be an email gateway in the 90s.
Two words: premium services. Which ones? I have no idea. Maybe have Lady Gaga lick envelopes for anyone willing to pay $1000 to mail a letter. I'm leaving this one up to you because frankly, I'm drawing a blank. Doesn't mean it isn't a good idea, just not one I have a good grasp on. You've got smart people, I'm sure you'll figure it out.
Partner with those who are competing against you. Carry packages for UPS and FedEx, especially in those really remote areas they don't want to service but you are required to. Charge them through the nose for it, too.
Win some sales deals. There is a reason amazon.com delivers at least once per week to my house. When I polled my coworkers, my number of shipments was pretty much average for the group. Yes, you already deliver a good number of their shipments, but do more.

Yes, many of the things I suggest are outside of your mandate or outside of your traditional offerings. That's the way of the market. You've stood still too long, doing what you've always done, but times have changed while you have not. There is one more thing you need to think about... what happens after your mission is over?

Don't get me wrong, people will always need to move physical goods from one location to another without making the trip themselves. But your mission, delivering mail everywhere, will end, if for no other reason than everything ends at some point. What plans have you made for your organization when that day comes?

The time is now to invest in the future. Innovate. You can do it; you've got the people and the history, you just need to make it happen.

The Ultimate Productivity Blog

2011-08-11T19:46:00.005-04:00

This post originally appeared August 1, 2011 on BetterProjects.net

I give you all, The Ultimate Productivity Blog.

Now that you've read it, how do you respond to it?

I ran across this reading Jeff Atwood's Coding Horror blog. He went on to say:

Reading self-help advice from other people, however well-intentioned, is no substitute for getting your own damn work done. The sooner you come to terms with this, the better off you'll be.
Get out there and do stuff because you fundamentally enjoy it and because it makes you better. As a writer, as an analyst, as a techie, whatever. Learn to love practicing the fundamentals and do it better each time. Over time, quality does lead to success, but you have to be patient. Really patient. Turns out, "overnight" success takes years. Maybe even decades. This is not a sprint, it's a marathon. Plan accordingly.

I couldn't agree more.

Subconscious Information Processing OR How I Think About Problems

2011-08-01T17:00:00.000-04:00

This post originally appeared July 25, 2011 on BetterProjects.net.

When I was in 8th grade, I participated in an program called Future Problem Solving. Teams from many different schools would gather in a room, the proctors would pass out a short description of a problem and each team would have a couple hours to come up with a set of solutions, weigh pros and cons of each, then recommend a solution for implementation. We would write all of that up into a two page summary, turn it in and wait a couple hours for the grading to come back to see which team won the round.

Given that I'm a Business Analyst by trade, it probably isn't surprising to any of you that I really enjoyed Future Problem Solving.

What had never occurred to me until I started this post is how much the habits I learned doing Future Problem Solving really fit into how I work today. See, what I haven't told you yet is that in the months prior to the sessions, the team was given high-level categories from which our question for the round would be selected. During those intervening weeks, the team spent its time researching and studying anything we could get our hands on about those subjects. I even remember our coach going so far as to figure out ways to get copy protected material that couldn't be sent through a copying machine to work on one anyway, just so we could all share the material.

But after we studied our heads off, we did something interesting... we did nothing. That's right, once we read and memorized all the information we could, we took a break. For the days just prior to the event, we really didn't do that much work. We just let the information percolate in our minds, ideas quietly bouncing off one another, marinating just long enough to produce something of quality.

So when I read about the idea of subconscious information processing, I realized that while the term might be relatively new to me, the concepts went back to some of my oldest memories. I do this all the time, for just about every project. Its routine to hear me say, "That's interesting. I'm not sure what to do with it or how to tackle it, but let me think about it a while and get back to you."

See, I'm all about up front research. Let me give you an example that happened just today. About 7 months ago, when I was given charge of our company's QA functions, I started doing a lot of research about testing processes and automated testing tools. During that research, I ran across the concept of writing software that gathers a large, some might say obscene, amount of metrics data from your application. The idea is to capture and measure everything, then to graph it so people can interpret it easily. When you start, you measure everything you can think of. Then you go back and add the things you never thought of measuring. Once you hit your stride, even modest sized applications can be measuring thousands of data points, everything from user interactions to system performance to usage duration.

I spoke of the idea of using this type of metrics data for an upcoming project, but only dropped the idea to my boss, our VP and one other manager, but I kept the idea in my back pocket all this time, just waiting for the right time to drop it. Today was that day.

Because I had 7 months to plan out how to bring up this idea, I had determined the best way to convince everyone of how useful this would be. Sure enough, as I laid out my vision for usage, everyone in the room was convinced within minutes it was the right approach to take. It was something no one in the room had considered. Most were like me of 7 months ago, they didn't even know that tools existed to do this type of analysis. The team immediately saw its value and started asking what other projects this might be used on!

What made this work, besides it being an idea whose time had come, was that I had done my research and the idea had time to grow in my mind. If someone had come to me 7 months ago and asked how we could better understand what is going on with our application, I would not have had a clue. Even 3-4 months ago, I would not have the full vision of what is now in my head. A year from now, after I've had time to tinker and play around with the ideas, it will be even better.

Its all about subconscious information processing. The idea of a robust analytics suite, not just for business metrics but for system and user metrics as well, was not created by me but it was one whose time has come for our organization. As I've been saying for months to anyone who will listen, "if we keep doing things the way we do them now, we'll continue to fail in the same ways." Its not that we fail a lot or fail badly, but everyone fails at some point. Keeping to the same processes only ensures that you'll continue to fail in the same way.

So what ideas have been rolling around in your head? Drop them in the comments for us all to spend a little time performing a little subconscious information processing on them!

(BTW, I am considering writing up an eBook on my experiences with what I'm tentatively calling "Metrics-driven Analysis" so everyone can understand the vision I outlined to the team, along with details on how to determine what metrics to track. Anyone interested in this?)

Innovating Requirements in the Office

2011-07-29T17:00:00.001-04:00

This post originally appeared July 19, 2011 on BetterProjects.net.

My last couple posts have talked about what innovation is and is not, from a fairly high level. Before you asked, yes, I do know this is a blog about projects. :) While both of these posts were somewhat relieving an annoying itch that had been bothering me for some time, it also was setting the stage for this post and the one after it that will discuss innovation in the work of a business analyst and in business analysis.

Today we are going to discuss the work of a business analyst. Having been doing this for a decade now, I have to say, in most ways, the job really hasn't changed. People have problems or have recognized opportunities, they bring these to me and expect miracles to be done, all before lunchtime. Sure, the last decade has seen my accuracy in requirements elicitation and analysis increase dramatically (I still shudder at some of those early requirements) along with my ability to document those requirements and relate them back to my stakeholders.

But that, frankly, isn't innovation. That's process improvement. This isn't a bad thing in and of itself, but it has its limits. If it takes me 2 weeks to elicit requirements for a medium sized project, with enough business and technical knowledge, I could maybe shave a few days off that timeframe, but its not likely I could decrease it to mere hours. There are just too many things outside my own control to make that happen.

Similarly, given enough knowledge and forethought, I could probably increase my accuracy in requirements analysis several percentage points. This suffers from the law of diminishing returns; the more accurate I want to get, the longer its likely to take me to get there. At some point, its probably better to go with what we know now and adjust later than it is to hold up resources who are waiting on work.

So how do I innovate in my job as a business analyst?

First, you have to realize that you do need to innovate. Staying the same really isn't an option. I'm not suggesting you go out and create a whole new methodology, but maybe its time to add into the mix segments from other methodologies into your own personal work. For example, even though you may work in an organization that is purely waterfall, maybe your run your tasks in an agile manner. Maybe you pick a backlog of tasks for the next 2 weeks, create a stack of those and then have your own, personal stand-up at your desk every morning. Work through the items, see what you've accomplished, decide on what you'll do today and figure out if you need to escalate anything.

On the surface, that probably sounds like looking at your to-do list as soon as you sit down in the morning. Truth be told, you're probably right in that assessment. The difference is that you're doing it deliberately now instead of just because you have to. You are adding an element of planning and forethought to a process that was formerly ad-hoc. Doing this may help you flush out ways in which you were previously unproductive, just because you took a little time to organize what you did naturally.

Next, add something totally new to the mix. Have you been focused on large requirements documents with lengthy implementation details included in them? Grab Visio and create a process flow instead. How about creating some wireframes and using them to help your stakeholders visualize requirements before they attempt to put them into words.

Now get rid of something; the more painful the better. The best thing to get rid of is email. I'm not an email hater, but its so convenient that sometimes we lose ourselves in it. Declare an email bankruptcy, wipe the inbox clean and start again. Let your stakeholders know that you're doing this and that if they need you to respond to something they sent within the last week, they need to do so again. Stop replying to every email just so they all know you're out here working for them.

Lastly, produce something. Do it early and often. Don't wait till its perfect to put it out there. Create a rough draft, something that has all the right ideas (and maybe a few wrong ones) and push it out for review in hopes that it creates at least one new spark of information in your reviewers. That one great idea may come out of being utterly disgusted with all the bad ones that rough draft contained.

There is a lot of risk in what I'm outlining here. I don't deny that; in fact, I'm glad of it. Many of us (myself included) work for organizations that have well established processes in place for good reasons, but we often (myself included) forget why the processes are there. They were put in place to fix a problem in the past, not in order to create a better future. Sometimes the world changes, and that rule that worked so well 10 years ago is hampering our ability to grow.

Embrace innovation in your job. Do it today.

What 'Innovation' Does Mean

2011-07-26T21:07:00.002-04:00

This post originally appeared July 11, 2011 on BetterProjects.net.

Last week, I did a post that catalogued a list of things innovation is not. I put this list together for two reasons: first, you hear all the time about what innovation is, but rarely about what its not. Second, having recently been asked by someone to 'get creative' when, if you know any thing about my work at all, I generally have to reign in my creativity for most people to keep up. Its not that I'm some genius (ok, I am, but lets leave my Mensa paperwork out of this), but I do get a lot of ideas. Most of them (ok, nearly all of them) suck, but on occasion, just like the picture to the right, one of them works. It may be the wonky one that fell over, but it does work.

With that in mind, I sat down and thought about what I really believe innovation is and does. As you'll see from my list and short descriptions for each item, being and doing are inseparable when it comes to innovation. So without further adieu, here is the list. Read it, then go out and do it. I'll do the same.

Innovation...

...must be nurtured. If you're not feeding it constantly, like one of those tamagotchi that were so popular in the 1990s, it will die. You can't ignore it. It is like that unruly child that needs more time than you think you have to give it.

...thrives on new experiences. You can't sequester it in a dark room (or a carpeted cubicle) and expect it to produce miracles. No, surfing the web is not a (good) substitute for experiences. It needs to be around others who can provide it with new stimuli. Consider it your inner toddler.

...is equal parts creation and destruction. Remember that project you did that rewrote your company's mission critical application from a mainframe dinosaur into a web-based cyborg? Remember that row of old gray-beards that soon found themselves out of a job once the power switch was flipped into the off position on those old green-screens? They were yesterday's innovators. You are today's innovator and some day soon, you'll have that gray beard when the next technology revolution occurs. Your innovation today was creative for you, but destructive to someone else's world. That isn't a warning that you shouldn't innovate, only to be aware of the consequences of your innovation.

...is disruptive. It breaks up the status quo. It turns the world upside down. It knocks people down. It uses lots of overused cliches (not really; just making sure you're paying attention). When innovation happens, people either change with it or they don't. Processes, technology and products fare no better than people.

...is more than just about product; it is also about process, form and service. Sure, we all hear innovation and think about the new, shiny product from Apple, but sometimes that product isn't something that's tangible. Innovation in process changes the way people work and play. Innovation in form changes the way we interact with the world around us. Innovation in service changes our relationship with people and organizations.

...produces. Ideas are not innovative. Innovation contains ideas, but is not just an idea. If you're innovative, you produce and do so in abundance. You can have the best idea in the world, but until someone actually can use or follow it, it isn't innovative. A person with a good idea for a movie is not an award-winning director or producer; they're just a person with an idea.

...leads to growth, but growth does not always lead to innovation. This one is tricky. When you innovate, you are specifically, intentionally, doing something that is better and different than anyone else. You will, sometimes organically and other times with a little marketing help, draw people to you simply because of what you're doing. This leads to growth, and as more people become aware of what you're doing, to more growth. But just because you're growing, does not mean you are in any way innovating. Your one, original great implementation may be stagnant for years while people slowly become aware of how great it is, but it doesn't mean any of the dozens of ideas you've had since then are in any way innovative.

...builds upon prior innovation. Innovation isn't a lightning strike (at least not usually); its more of a slow boil (usually). Innovation takes innovations of the past, tweaks them, recombines them with different innovations and creates something novel and useful. Don't worry that your innovation is nothing more than a compilation of stuff other people thought of; that's exactly what those other people's innovations were as well.

...embraces failures, both of commission and omission. There are two ways to fail: doing something and it failing or not doing anything and failing. If you build something novel, but not useful, its probably going to fail (commission). If you had the idea but implemented nothing while someone else had the same idea, implemented it and succeeded, you also failed (omission). Both processes teach you something. The first teaches you not everything is really innovative. The second teaches you to seize when it comes to you; not to wait for someone else to create it first.

...is hard. Not everyone (in fact most people) can be innovative. There are lots of reasons for this. Some people don't give themselves time or space to be innovative. Some don't believe its possible for them. Others blame someone else's stifling influence on their own failure to innovate. There are as many reasons as there are people on this planet (and probably quite a few more) to not be innovative. In the end, innovation is about choice. If you set out to be innovative, I can't guarantee it will happen. I can guarantee you won't be innovative if you choose to not be innovative.

What about you? What is on your list of ways to be innovative?

What 'Innovation' Doesn't Mean

2011-07-14T17:00:00.001-04:00

This post originally appeared July 6, 2011 on BetterProjects.net

It doesn't mean 'Not Invented Here'
It doesn't mean 'New is always better'
It doesn't mean 'Build for the sake of building'
It doesn't mean 'Winners finish first'
It isn't a way to filter good ideas from bad ideas
It isn't a way to 'think creatively'
It isn't a way to 'think out of the box'
It isn't a means to an end
It isn't sold by any individual company
It isn't the domain of any type of consultant
It won't ensure you make money
It won't ensure your company or project survives
It isn't the birthright of a single country or culture
It can't be contained within a pithy slogan or on a t-shirt
It isn't housed in the private conference center across town
It isn't something that is for sale on an eCommerce site
It isn't something you can find on amazon.com
It can't be mandated by management
It can't be put on a schedule
It can't be bought
It isn't measured by patent filings

It really irks me, if you didn't realize it by now, when someone tells me to 'get creative' or 'be innovative'. It isn't a light switch. I wasn't being not-innovative yesterday and suddenly decided, because you told me to, to be innovative today. I'll be doing another one of these lists, hopefully soon, about what innovation really is. Stay tuned.

Minimally Viable... Project?

2011-07-11T17:00:00.004-04:00

This post originally appeared July 5, 2011 on BetterProjects.net

As I'm checking through my news feed, I ran across this great post from 37signals about what happens to user experience in a minimally viable product. This started me thinking... what would constitute a minimally viable project? Before we dig into that idea, what is a minimally viable product?

MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not.

The first thing that comes to my mind about running a minimally viable project (I'll refer to it as MVP from here on out, so don't confuse it with MVP from the quote) is scarcity. This isn't with a 'do more with less' management BS, but just an acknowledgement that the resources and ideas you do have are precious and should in no way be taken for granted. Lean Startups usually have very little money, and thus very little time, to create their product and get just enough customers to survive until the next round of funding comes in or until you get enough paying customers to sustain your company.

Sometimes projects start out with a surplus of resources, all of which are the wrong kind. When you're trying to figure out what needs to be done, projects often suffer from a too many hands in the cookie jar syndrome. The opening in the jar, our project funnel, can only support so many people reaching into it at one time before fighting begins. In this situation, cookies may be in plentiful supply, if the jar is large enough, but cookie access is scarce. The more hands trying to access, the more scarce will be cookies outside the jar due to hands getting in each other's way.

Starting an MVP requires having the minimum number of right resources to get the project off the ground. Any more or less of the wrong kind of resource and you are failing either the 'minimum' or the 'viable' part.

Another part of the Lean Startup process is a focus on using the tools you have available. Because of funding restraints, these usually end up being free, open-source software that the startup can acquire with little to no cost and can modify in any way they please. You don't necessarily have the tool that is perfect for just what you're trying to build, but you have tools that are good enough to get the job done now.

How many times have we waiting around to start a project because some piece of infrastructure or specific resources were unavailable? How frustrated did that make you? Yes, as I pointed out in the prior section, resource scarcity is a reality, but when you're in an MVP situation, you do not let yourself be hindered by the lack of that exactly perfect resource. You do without, knowing that at some point you will likely have to scrap much of what you've done anyway. Why would you end up tossing what you've done away? That's where we come to point #3 in the Lean startup.

Lean startups are all about iteration. The idea is to release quickly and often, get your customer's feedback on what you've done and then make it better at such a rapid pace that before they can get bored with what you're doing and move on. You constantly engage them with just enough progress that they stick around.

One of the things that often frustrates me is walking into a requirements review session knowing that its going to be two weeks until I see the revised document from the analyst. Yes, watching someone who is not computer savvy (or using a bad requirements management tool) attempt to update a document in real time during a meeting can be the definition of painful. When you're with an analyst who can fly through the changes, its amazing how seeing the final revision take shape in front of your eyes changes your entire outlook on the project.

Does your organization practice MVP? Do you think its something that sounds nice but is best left to the realm of the lean startup? Let us know in the comments.

Trojan Consultants

2011-07-07T17:00:00.000-04:00

This post originally appeared July 1, 2011 on BetterProjects.net

Found in this week's issue of The New Yorker. It made me laugh and I just had to share.

Remixing Innovation

2011-07-05T17:00:00.000-04:00

This post originally appeared June 29, 2011 on BetterProjects.net

A few months back, I finished reading a book by Steven Johnson called Where Good Ideas Come From. For a while now, I have intended to write a review of the book, but lets be honest, I suck at book reviews. It is difficult enough to encapsulate so many good ideas (pun not intended) into a short post for a book that was just ok. It is infinitely more difficult when the book you read is this amazing.

Thankfully, I have been saved from such a task by the latest installment of the Everything is a Remix (part 3).

One of the things I find so amusing is that this entire video contains elements that could have come directly from Steven Johnson's book. Many of the examples and all of the themes in the video exist in the book, in a condensed and concise format. The book expands and adds to these concepts a great deal. I highly recommend reading the former and watching the later.

As a teaser, I'll give you my favorite quite from the video:

We can’t introduce anything new until we’re fluent in the language of our domain, and we do that through emulation.

Do you remember your first project? The one where you were lost about what to do so you grabbed a bunch of templates, formatted your notes into them and prayed no one noticed you were just making all of this up? Yeah, me, too.

Do you remember your most recent project (assuming they're not the same one)? When you compare the two can you see how your actions in the first project, for good or ill, led you to what you've done most recently?

Its all remix, yet when we recombine things, sometimes we hit upon something that fits just perfectly. Its why everyone has created or modified an existing requirements or project plan at one time or another. Something wasn't right, you had this idea you got from a different domain, you put them together and something just clicked. You innovated.

What I think frustrates me the most about innovation is how most people just don't get what 'it' really is. We're told to "Go get creative; find a solution that doesn't blow the budget, can be implemented by a typing monkey and will be done in two weeks" yet those issuing that edict don't seem to get that good ideas can't be forced in that way. Yes, 'creativity', if defined as 'slap something against the wall and hope it sticks before I lose my job', then I can help you with that in a short time frame with no budget or resources.

But if you want a solution that is fully conceived, builds upon the right foundations in knowledge and infrastructure and, most important, actually solves the real problem, you probably want to put some effort behind it besides driving the whip.

Being a manager, this amuses me...

2011-06-30T17:00:00.000-04:00

This post originally appeared June 28, 2011 on BetterProjects.net

I haven't said it in a while, but I *love* this web comic. Pure genius. I will say that I have never passed anything along to one of my employees that I haven't already done at least once myself, but there have been a few times where I thought to myself, "At least its not me dealing with it this time!" Sad but true.

Timothy B. Lee: Industry Destruction

2011-06-28T20:51:00.000-04:00

This post originally appeared June 23, 2011 on BetterProjects.net

One of my favorite bloggers in the last year has become Timothy B. Lee. While I don't always agree with some of his libertarian viewpoints, this guy always makes me think. He did so recently with his discussion about how technology innovation cannot always be measured strictly in term of Gross Domestic Product (GDP).

The part of his article that most directly relates to those of us who work primarily in projects is this:

Self-driving cars are a good example of where things are heading. They will probably put millions of truck drivers out of work, lowering the cost of almost every consumer product. They’ll make taxicabs drastically more affordable, putting taxi drivers out of work and virtually eliminating demand for off-street parking. They’re likely to have significant environmental benefits, as consumers can order only as much car as they need for any given trip. They are likely to save thousands of lives by reducing accidents. They’re likely to transform the retail sector—how often would you drive to store if a self-driving Amazon-bot delivered your orders in an hour rather than 2 days? And of course they’ll have many other consequences we can’t anticipate.

Company-first

Stop for a moment and think about what self-driving cars could do to whatever industry it is that you work in. I'll give you an example from my own personal employer and myself. First, my employer has hundreds of employees who do nothing but deliver food to local stores and thousands more who do nothing but deliver its product end customers. Imagine if, over the next decade, self-driving cars become cheap enough that only the hundreds of drivers who deliver food to local stores no longer have jobs.

Even if my company undertakes no project to build, from nothing, a self-driving delivery truck, we would need a project to implement the self-driving delivery truck someone else built into our organization. Imagine the look on the faces of the delivery drivers when they are told that we're going to test a product that could potentially end their jobs.

I don't think anyone would argue that, from the perspective of the drivers, that would be a disruptive technology. For the company, its a huge up-front investment, one which would probably require the replacement of its entire fleet of vehicles, but in the end, it would end up a competitive advantage to no longer need to pay drivers in this way.

Making it (more) personal

But what about me, as a BA? How would self-driving cars impact my life?

Given that I spend, on an average work day, 100 minutes in my round trip commute, a self-driving car would make me more productive. Consider that I average 9.5 hours of work per day (570 minutes), 100 minutes of drive time and another hour and a half of productive time in the evenings (housework, laundry, blogging, etc), I would increase my productive time from 660 minutes to 760 minutes, an increase of just over 15%.

What could you do with an extra 15% of productive time per day? I don't mean necessarily 'productive' as in 'doing work for an employer', but what about reading a book, listening to a podcast or even writing a book? Maybe I just shift some those 100 minutes into my at the job time and leave at 4:50 each day, knowing that I'll still be exceeding my normal output, even though I am 'leaving early' for the day.

With one simple change, at least simple in terms of me doing the cash outlay to purchase a self-driving car, I completely change what I am able to complete in a day. Sure, I could, in theory, just move 5 minutes away from work and would produce essentially the same result, but I don't want to live 5 minutes from work (not to mention this would make my wife's commute now around 160 minutes per day).

Never discount the possibility of a technology to be disruptive to your business (or yourself).

Why Quality Is Important

2011-06-23T17:00:00.001-04:00

This post originally appeared June 22, 2011 on BetterProjects.net.

MG Siegler on Apple:

Even Apple haters cannot deny the quality of the products. Bitch about price, bitch about control, bitch about the fruit logo — but quality is simply never a compelling argument. Because Apple wins.

Somewhat colorful language aside, I can't think of a bigger compliment anyone could receive in a project than to say that their quality product is the reason they are successful every time.

Ok, so what, you say. Why is this important? He continues:

Apple will remain in a position of power for the foreseeable future because they have nailed that model.

Apple knows what business they are in, they constantly evolve that model to not just anticipate the needs of markets but to create markets and they do it better than anyone else. When was the last time that any of us evolved the project model? When did any of us create an entire new market for projects to inhabit?

When we, and I speak for myself as the first person in this line, own the model, we'll win every time.

What does 'Priority' really mean?

2011-06-21T20:48:00.000-04:00

This post originally appeared June 20, 2011 on BetterProjects.net.

Hello everyone from my multiple week hiatus. My deepest apologies for my prolonged absence. I was out one week on a family vacation and then had two weeks of hip (more like neck) deep work that piled up while I was out of town and had to get done before I got back to blogging. All of that is now taken care of, my batteries are recharged from some time away and I've got a whopper (I hope) of a first post for you.

Lets talk about priority. Yes, I know, I said I have a whopper of a topic and priority, well, doesn't seem to fit that kind of a heading. Hang on with me for a moment and I think you'll agree that priority doesn't mean what you think it means.

The traditional view of priority

While on the plane ride out to California, I listened to one of my regular podcasts, Back to Work, hosted by Merlin Mann and Dan Benjamin. It was episode 17 and Merlin spent a lot of time opening my eyes as to what priority really means.

If you're like me, when you hear 'priority', you might picture a large group of people sitting around a conference room table trying to determine which items on this big feature list they want done first. Its all about scarce resources and how to best deploy those resources.

Maybe you take a different viewpoint; maybe to you, its a notepad that contains a bunch of tasks that you have to get done today. You drop off your personal belongings at 8am and begin to complete those tasks in the order that your boss expects them to be completed.

In these views, priority is all about order and completeness. There is no thought that any of these items won't be done, its just a matter of how long until they are complete. To me, this had always been my thoughts on priority as well, even though it never really sat right with me.

My issues with priority

There are two things that always bothered me with this view of priority. During really large projects, I noticed a tendency for features that were either really difficult to implement or that were falsely labeled as important, almost always fell off the final deliverables list somewhere along the way. When we delivered a release, all of these things which people had given enough priority to be included in the initial scope just never made it to the finish line.

Stranger still was the rarity in which someone would complain about one of these items missing from the final product. Sure, the person who came up with the idea may grumble about it not being there, but when everything was said and done, the non-inclusion of these functions were non-issues.

For the really difficult to implement issues, they almost always fell apart not because the technology didn't exist or was too expensive, but that the business rules and definitions were always so vague or poorly defined that no one in the business areas even really understood what was being asked for. When those items failed to meet the final build, no one noticed because no one really understood what that thing was all about in the first place.

When it came to items that were falsely labeled as important initially, it was almost always to appease the ego of one stakeholder. Often times these items were tossed in to scope, even though they didn't really fit with the goals of the project, just to mollify someone who was offended that the genius of their pet project wasn't recognized by everyone else. Since no one ever saw this as a priority anyway, when it fails to be delivered, no one really complains about its absence.

What we're missing

What is missing in all this discussion of priority is a concept that, at first glance, seems like it doesn't really come in to play anyway. Yet, if we're really going to talk honestly about priority, you can't without it. Merlin nailed it when he discussed priority being nothing more than a way to quantify sacrifice.

Yes, sacrifice. When something is correctly prioritized, you're really discussing your value system showing what you will not do more than what you will do.

We need to reframe the discussion about priority. We need to change the thought from being "Here's a huge list of stuff, we're going to do all of these in this particular order" to "Here is the small number of things we're going to do and do really well, because these are the things that matter to us. Every other idea may be good, but we're going to sacrifice and not do them because they don't fit with what we really do want to do."

The outcome

Why would we want to change our viewpoint on priority? Isn't the traditional viewpoint better because it gives us a direction on what to go do after the current project?

No, it isn't. There is an assumption in an ordered list that we'll have the time and resources to continue completing items until the list is complete, but that assumption is faulty for many reasons. Projects are time bound activities and there is no guarantee that there will be a next project after this one, which fixes or adds in everything this first projected failed to include.

So is our alternative to just make all projects omnibus, where they contain larger and larger sets of requirements so that everything becomes a 'priority 1'? I don't really have to tell you the answer to that is 'No', because we've all seen those projects and we all know that even if they reach completion and deliver a final project, its never the exact product anyone wanted delivered.

The answer then, is smaller projects and a sharper focus on cutting out everything we can. We get that laser-like focus, we sacrifice everything we can live without in order to perfect the things which truly matter.

What a Business Analyst thinks about TV

2011-06-07T17:00:00.000-04:00

This post originally appeared June 3, 2011 on BetterProjects.net

I have a recurring conversation with many of my friends and coworkers. It goes something like this:

"Hey, Ted! Did you see what happened on show XXXXXXXX last night???"

"We've worked together for over 4 years now, and in that time, how many times have I ever answered 'yes' to that question?"

"Uhm... yeah, that's right. I forgot; you don't watch TV."

Yes, I am a weird-o. I don't watch TV. More accurately, I download a very limited set of TV shows, only one of which has gained any real mainstream popularity, and most importantly, my wife and I only watch the downloaded versions when we have nothing else to do. Its not that we have some kind of religious or spiritual aversion to the TV; its just that we receive very little enjoyment out of mainstream entertainment. To each their own.

How a BA looks at TV

Given my outsider status, I feel as if I have an interesting perspective on the television. Its not that I think its a tool of satan or something that rots your brain; just that it isn't for me. There are certain things that I want out of my entertainment medium and TV fails that on most every account. To put it in business terms, TV fails to meet nearly every one of my requirements. Are my requirements so esoteric that they're nearly impossible, at least economically, to meet? I don't think so, but my perspective is a bit biased.

Some of my objections to the current state of TV, at least as we have it in the US, is nothing more than my rejection of the values of the society in which I live. Minus my mortgage, I have no debt. I don't buy things I can't afford. I don't try to 'keep up with the Joneses'. Things like this just don't matter to me. TV, and its advertising sponsored channels, just don't have the same goal as I. That's not to say that one of the two goals is better or worse, just not what I value.

I see the same type of conflict happen between stakeholders on projects as well. Be honest with yourself and you've seen it happen, too. How often have the strict controls desired by finance and audit meshed perfectly with the flexibility desired by operations? When has the need for short call times within support matched up with the detailed analysis needed by engineering?

When our stakeholders do not agree, we either get them to some kind of acceptable compromise or one side's needs so far outweigh the other's that a decision is obvious. For me, I'm not going to ever let the needs of the other side (advertiser's and networks) outweigh my needs and any compromise that requires me to watch needlessly consumeristic commercial content in order to get a few chuckles is also abhorrent to my sensibilities. When faced with either of these two possibilities, I do what most project stakeholders are unable to do; I take my 'ball' and go elsewhere.

Making a better TV

So what would I do to make TV more appealing? I'm not the first to ask this question, which is why this idea of rethinking TV came to mind. Frankly, no solution that would meet my needs would allow TV as we know it today to continue.

The first thing that is important to me is the ability to make TV adhere to my schedule. Being able to watch what I want to watch when I want to watch it is primary. When I'm not at work, I don't plan my life around set slots of when I must be at some specific location to do a specific activity. If I miss a time window, or if I simply don't want to do an activity at a certain time, I shouldn't be punished for this. TV that requires me to watch on someone else's schedule is simply unacceptable.

DVRs, and tv-on-demand, have gone a long way to meeting this requirement. Tivo and other similar services help users time-shift programming to meet their schedules, yet they still have issues with my second requirement, location shifting.

Its not that I just want to watch TV when I want, but also where I want. Of all the screens in my house, laptops, iPad, netbooks, iPhones, desktops and TV, the TV is the one that is on the least. Even then, the number of movies played far outweighs the number of TV shows. Why is this? Simple; the mobile devices can go wherever I go, but the TV (generally) must be stationary.

If I go to the doctor's office and sit in the waiting room for 30 minutes, I don't want to be forced to listen to the soap operas or the afternoon talk shows when I can whip out my iPad and watch whatever I want. The problem with this model is that streaming TV over the iPad, especially when on a public wifi connection, makes for a poor experience. The only viable option, as of now, is to download the show in advance if you want to be able to watch later; a solution which really doesn't meet my need.

How many times, especially with the advent of cheap laptops and (more recently) tablets, have our users begged and demanded to have their data and processes available to them in a mobile fashion that doesn't equate to email? More and more, our users want their data available where they are, not just in the office. Just like I want my TV available where I am, our project stakeholders want to work where it makes sense for them to work, not where it is convenient for the project teams for them to work.

The last requirement I have is in regards to cost. Yes, it is absurd that I am unwilling to pay $1 for an episode of a show when I am willing to pay $3.50 for a hot chocolate from Starbucks, yet for some reason, I just can't bring myself to pay that for a show. The meager laughs provided by modern TV via download just don't seem worth it when the same content is available over the air for 'free' (advertising notwithstanding). Even just rereading this paragraph makes me realize how absurd my value system is in this area, yet I have a mental block that just refuses to budge.

This is the one that makes me cringe because I see it in myself. I know that my users are tired of hearing me say, "If only I had the time, people and budget, I'd love to do that for you, but as it is, I am completely constrained on all three of those fronts. Get me more of any of those three and I can help you out." Its the same thing with TV; I want it for (mostly) free. Yet my expectations of what it should cost to produce 30 minutes of quality programming and what it actually costs to produce 30 minutes of quality programming are far apart and unlikely to ever meet. When my stakeholders complain about me never doing anything for them, I cringe, because I know that I do the same thing when it comes to media companies.

Summing it Up

So what are my requirements? Simply put, I need to be able to view TV when I want, where I want and at a cost that doesn't feel usurious to my wallet. Those are not requirements that are unique to me. They are the same requirements that are asked of me on a regular basis (albeit with less militancy than I've expressed here about my own wants and needs).

Exercises like this, which outline our own requirements that are not being met, are useful not only to help us sharpen our skills, but to help remind us of the struggles our business stakeholders go through regularly. These are reminders that those of us who regularly work on projects need to have regularly.

A new Facebook Use Case

2011-06-05T19:43:00.000-04:00

This post originally appeared June 1, 2011 on BetterProjects.net

Recently, while looking through my Facebook feed, I realized there is a use case that isn't currently cared for by the site. Its something I had noticed in the past, but it never occurred to me that the site could actually resolve the problem for me (at least mostly resolve it).

As a result of 9 trips to France in an 18 month period that ended, coincidentally 5 years ago this week, I have a lot of former French coworkers who are my friends on Facebook. That same project also saw me make many friends who spoke Arabic and a few who speak Hindi (or other languages from the Indian sub-continent).

As my travels in France left me there, often with no other people who speak English as a first (or only) language, I learned what I called 'Menu French', which is just enough French to not starve when I head to a restaurant. But that little bit of French has, over the intervening half-decade, faded with disuse.

Enter my recent review of my Facebook news feed where I realized there was a post from one of my French friends that I could almost, but not quite, understand. Because I know my friends well, I know that they have French set as their default language in Facebook, even though they all know English. I know that I was not the intended audience for whatever it was they were trying to say, as it was in French, but I wanted to know what they were saying as I like knowing what is going on with them in their lives.

Sure, I could highlight the text, right click on it and then ask Google Chrome to translate it for me, but that's a pain. Given that Facebook knows their language, knows mine (English), and that they already have a UI element that could be repurposed for it, this would be an extremely easy thing for them to offer to auto-translate for me. Imagine another icon, just below the 'X' used to hide a post, that only appears when the text in a status update is in a different language than my default language. How awesome would that be?

Yes, I know, automated translation utilities suck. I get that, but frankly, I don't care. If the translation isn't perfect, that's fine as all I really want to know is the meaning (and maybe a small chuckle at how bad the literal translation actually is). What I want to know is what is happening with my friends. I don't need a legally binding translation, just enough of a help to keep up with their lives.

The technology exists. The is a known languages section in your profile that could act as a cue to Facebook that you might be posting in languages unknown to all of your friends. Why have they not stepped up to add this functionality?

Truth be told, its likely an edge scenario. I get that; I have to help business users prioritize edge cases all the time. Yet, its an edge case that can't by any means be unique, especially given the rapid rise in our world's population and the ability to connect with others in this world. These are two trends that will do nothing but continue to increase, so its is not that this is an area that will disappear with time. I am simply surprised that Facebook hasn't noticed it yet and implemented a resolution for the problem. It just seems right up their alley.

What about you? Could you use autotranslation, even if it is far from perfect, inside of your social networks? What other use cases is Facebook missing (besides useful privacy controls; I think that one has been beaten to death)?

Google Docs as a Requirements Management Tool? No, Really!

2011-05-27T22:44:00.000-04:00

This post originally appeared May 24, 2011 on BetterProjects.net.

At my day job, we've recently started a new program which will likely be the largest single technology endeavor ever undertaken by our organization. Its got big goals and, assuming we pull it off, will position us more than a decade in front of our leading competitors when it comes to technology integration within the organization. The advantages of our approach is making everyone from operations, finance, support and IT rub their hands in glee. Its got a little for everyone and a lot for some. Its one of those endeavors where everyone is on board with it and the only real complaint is that we're not done already.

Given the high priority and the huge operational need for this project, you might be asking yourself, why on earth would I, a guy who blogs about projects in general and requirements in specific, be dumb enough to pick a hack tool like Google Docs as our requirements repository. Great question, glad you asked. Its actually a long story, but for the sake of not overly boring you, I'll sum up a bit.

One of my favorite features of Google Docs is the drawing function. See, I like Visio for diagrams and even for rough wireframes, but the fact that nearly no one has Visio installed and the license fee is high enough that no one outside of BA's and IT manager can justify the expense in most organizations means that you're forced to output to PDF or past into Word just about everything you create. Frankly, that sucks.

But as nice as the drawing functions are, what really caught my eye was templates. A very short time after the template sharing was launched, I spotted this link for a basic set of wireframes that met my two requirements for any tool: simplicity and usability. I kept the link around for nearly a year before I found a project where it would be perfect.

What I wasn't expecting was how well people have taken to the idea of using Google Docs during our requirements elicitation process. We're totally changing the user interface and business processes used by this enterprise application of ours. Our user community is (rightly so) not thrilled with its current implementation, but, like most user communities, has trouble articulating exactly what it is that would make for a good application that meets their needs. This is where Docs, in general, and the linked to wireframe template, in specific, has come in so very handy.

The Process

Knowing my user community as well as I do, I knew that if we walked in to the first elicitation session with nothing to show, we would spend most of the day off in the wilderness trying to chart a path. So, having spent many years learning the business, I put together a few different sets of wireframes that gave different (sometimes wildly different) takes on what you could do in a modern application.

It was during this process of putting together those initial wireframes that something I wasn't expecting happened; I remembered a great little feature in Docs called 'Sharing'. As a lark, I decided to share off my wireframes to my Director and VP (plus a few other BAs on the team). They were curious as to what I was doing, so I figured the easiest way to make sure they always knew what I was doing was to allow them to proverbially watch over my shoulder.

From that point, things just started snowballing. I added a use case template and the BA creating the use case library for me started adding her docs and sharing them off. She and I use a Google Spreadsheet to keep track of the use cases we've identified, the status of each and as a way to signal to the other what work needs to be done. The best part, although its one we're just now really starting to use, is collaborative editing. We sit no more than 20 yards away from one another, yet being able to watch the other person update a document in real time does wonders for the creative process. I can't recommend this enough.

The best part of this is how successful we've been so far. Everyone has all the information the need whenever they need it. No document checkouts needed. We modify documents, compare revisions and leave each other electronic notes in the margins. No need to print out, mark up and return for review. We make changes on the fly, right in the document.

Our users don't (yet) have a clue how we're doing all this. Honestly, there hasn't been a need as most of my external stakeholders don't spend their days looking at their computer (outside of email and reports anyway). What I have seen is how they've taken to me sitting in front of them during review sessions and making changes live, in front of their eyes, as they make suggestions. It has shortened the feedback cycle, making the team significantly more effective at our job. When I started this effort, I expected it would take months to complete just the 75 use cases I originally outlined. We've been at it for about a week now and have 25 ready for stakeholder review.

Lessons Learned

Having the right tool is invaluable. No, we're not using a structured requirements tool. No, we're not using rich prototypes. No, we're not using pixel-accurate renderings of screens. Yet, we're achieving astounding results for no other reason than we're collaborating in a way I have never done before. So far, only a subset of the team is working this way as well. What will happen when the larger group of BAs, our stakeholders and the development teams start using this as well? I can't even imagine the productivity gains that are yet to be recognized.

Collaboration, when facilitated by technology, is an enabler you can't understand until you have experienced it. Yes, it is still annoying when I have to output my wireframes to a image file and then import them into a MS Word document in order to share them with my stakeholders. That is still frustrating, yet being able to work in real time with my coworkers nearly makes up for it. My stakeholders only review a nearly complete work product; they don't care about the guts of how I get it done. If what used to take me weeks of struggle fighting with my tools and of outdated versions found in the hairball that is a networked shared drive are things of the past, that alone is a victory worth celebrating.

I'm sure someone reading this is saying, "That's great. My company implemented something to do this YEARS ago. Tell me something new." That's awesome for you; we all envy you and wish our organizations put such an emphasis on providing such great tools to us, but we don't work there and have to make due with what we have. BUT, if this post taught you anything, it should be that good tools are out there and they are just waiting for you to use them. Use Google Docs for collaboration one time and, minor formatting concerns aside, I bet you'll be like me and be even more loathe to open up MS Word.

Reqline Beta Launched!

2011-05-22T12:28:00.000-04:00

This post originally appeared May 19, 2011 on BetterProjects.net.

You know, I have to hand it to the guys at Pragnalysis, they did something in a timeframe I didn't believe possible. Last Saturday, they debuted their new requirements management tool, Reqline. I love the idea of what they're trying to do here for a couple of reasons I feel I just need to point out.

First, the price is unbeatable. Its free. The last vendor I spoke with who promised me a revolution in how I elicit requirements wanted $250k just for a handful of user licenses. Their tool was, admittedly, top-notch, but when you work for an organization that relies almost exclusively on open source tools for their development practice, freeing up money for new desktops is hard, much less dropping a quarter of a million dollars, equivalent to some yearly departmental budgets, for a tool to replace MS Word, Excel and Visio, tools the company already pays a lot less for, is an impossibly hard sell.

Second, I like their approach. If you've been reading my posts for a while, you know I'm a big fan of simplicity. My general rule is to use as few tools as possible to complete the needed tasks in as efficient of a manner as possible. Despite the growing number of requirements management tools on the market, most try to be everything to everyone, and charge everyone for it. You know, I really don't need an absurdly complicated traceability matrix function, but if you just give me a list view with custom columns and, most importantly, an extremely fast way to enter the data I need, you're going to win me over.

All the praise aside, there are a few things that I have to talk about with the tool; things I just can't get over despite my want to love it.

Back to Reality

First up, this is a v1 release. Not all v1 releases are bad, but this one surely is. Guys, great effort, and I don't mean that in a pandering, elementary school soccer coach way. Please keep up the good work, but your tool, in its v1 incarnation, is simply unusable. Its not that I didn't try. I walked through the half dozen very needless configuration screens during the setup process and at the end, I was presented with a blank grid that did nothing. I figured I messed something up (user error, hello!) so I did it all over again. Same thing.

I'm a pretty savvy guy when it comes to software (just having to justify myself that way makes shivers run down my spine), but even I couldn't figure it out. I figured out Prototype Composer. I figured out iRise. I even figured out Oracle BPM Studio, yet your tool completely flummoxed me.

Maybe its not fair to pick on you, given I couldn't even get the tool to work. Maybe I should have contacted you for support. That's not really my point though. Its possible I was just over-thinking it and missed something very obvious, but isn't that in and of itself a problem? If I failed to be able to use it, what is going to happen to users with lesser abilities to navigate foreign software?

If I could give you only one piece of advice, it would be simplicity. Launch the app. Present 1 option for the user to fill out (the project name) and then slap in your 'best case' defaults for everything else. Get me using the app as fast as possible with as little work on my part as possible. Give me a way to tweak the settings later, after I get a chance to actually use it. Those half-dozen screens I walked through during setup? I had no context (other than my background as a BA) about the consequences of any of my selections, other than my experience with requirements in general. Keep it simple; it will help. There is a reason 'It just works' is a slogan. If it just works, you've solved most of my problems already.

But if I could give you a second piece of advice, it would be to ditch .Net completely. Its not a bad thing for desktop software, but its very limiting. You really want to do this right, you can still use .Net, but make this thing a web application that anyone can use. Don't make me install software; point me to your website and turn me lose. The name of the game for requirements elicitation and analysis is collaboration. Installing desktop software is a big bag of hurt on collaboration. Don't saddle yourself with what is a legacy application on its launch day. Don't tie yourself to something that can only be used on a Windows machine. Analysts need to be mobile and that excludes just about everything from Redmond, WA outside of lugging a laptop into someone's office.

Final Thoughts

It may seem like I was a bit overly critical of a v1 piece of software, but if you take anything away from what I've written, its that you shouldn't give up! Go on! Go faster! Go better! I love what you guys are trying to do and I truly want you to succeed beyond your wildest expectations. If you do succeed, then you've made my life so much better. I can't wait to see what v2 has in store.

The Better Way I Wasn't Looking For

2011-05-18T17:00:00.000-04:00

This post originally appeared May 16, 2011 on BetterProjects.net

In the first half of this year, I've written a couple blog posts about the checkout line. Naturally, given that I've got two under my belt already, when I saw the below video about a future way to a better checkout experience, I had to share.

This said, I don't think the technology as presented (note that the upper right corner of the video shows how many times above normal speed they had to increase the video pace as to not put you to sleep) works very well, but robotics is a concept I didn't exactly explore in my prior posts.

Anyway, as you all start out the work week, I hope you enjoy the little detour into the checkout line!

Privacy? Not on this man's Internet!

2011-05-17T21:17:00.000-04:00

A few days ago, as I did my morning perusal of the overnight Facebook updates, I noticed a curious comment that had been posted by a childhood classmate of mine. It was curious, not in its content, but more in its absurd vehemence. She was aggrieved, that one of her so-called friends would dare to let her louse of a ex-husband see any information that she had posted to her Facebook page.

I get her pain. A break such as she had obviously been through is traumatic and damaging. To then have a second person, someone you had thought a friend, betray the trust you had given them in the form of access to your private information, and provide that information wholesale to the person who hurt you most, must be painful beyond doubt. I get that you're hurting. I understand trust betrayed.

What I don't understand is why this person felt they had any actual privacy in the first place.

Lets, for the sake of this discussion, call this woman Susie. Her statement, which in respect to her privacy I will not repeat, was laced with undertones of having some inalienable right to controlling the thoughts and actions of those she chose to call friend. To her, anyone who did anything with her personal information that wasn't done so without her explicit permission was an affront to her dignity and humanity.

What Susie fails to understand is, she already gave not just her friends' list, but frankly anyone who wants to make up the most phony of legal charges against her, the right to everything she ever said or uploaded into Facebook. By simply making a digital record of her thoughts, visits and actions, she has explicitly chosen to give up any rights to privacy she might have had.

The Constitution, the Bill of Rights and all the subsequent amendments back this up. The Constitution itself provides for no right to privacy, thus the Bill of Rights was added to specify what rights citizens of the Union had and did not have. The 1st amendment provides a right to privacy of beliefs, the 3rd against housing of military personnel, the 4th against unreasonable search and seizure, the 5th against self-incrimination and the 9th says that there may be other rights not included in the amendments or Constitution upon which, and this is the key part, that the government may not infringe upon.

What did you notice about that list? First, not one time in that list is there one provision stating that one person has a right to privacy from any other citizen. Sure, there are plenty of laws on the books to protect such rights, but there is no stated, universal right to such protected by (and from) our government, much less anyone else. Second, there is no provision stating that a person has a right to privacy from companies. In fact, the entire reasons companies can send you junk mail or solicit you over the telephone despite being on the Do Not Call registry is because when you enter into a business relationship with them, you give away your right to not be bothered by them (at least until you tell them to buzz off).

I could go on through the rest of the amendments, but I think you get the idea. You've got a right to privacy, but it is a right only in certain areas and from certain entities.

So if Susie doesn't have a Constitutional right to keep her updates private, doesn't the fact that Facebook includes privacy controls mean that if she blocks someone from seeing her updates that they shouldn't ever know about those updates? Hardly.

Quick poll... who here believes that Facebook's privacy controls are there to protect the privacy of their users? If you said 'Yes', you're not paying attention. The reason those controls are there is to lull you into a false sense of security in order to get you to share more information.

Quick poll #2... who is Facebook's customer? If you said its users, you really need to have all five of your senses checked, because once again, you're just not paying attention. Facebook's customers are the ones who pay them money. In a word, its advertisers.

Quick poll #3... if advertisers are Facebook's customers, what is Facebook's product? If you said, 'a website', I must ask if you even have a Facebook account. No, the answer to this question is that you, its user base, are the product. Facebook sells your time, and more importantly your personal information (usually in a mostly anonymous, aggregated form) its to advertisers.

In other words, Facebook exists in order to make money off the information you freely post to the site. You're being used.

Don't get me wrong. I have a Facebook account and use it to an extent that would make most people blush. I'm being used, pimped out, put on a street corner and made to dance; however you want to say it, I'm being exploited for someone else's profit. I know this and, strangely, I'm ok with it. If I post something to Facebook, I know that it is not private and that to expect it to not be used by someone is absurd.

Yet, the myth of privacy on Facebook, and really the Internet as a whole, still persists among the masses. It makes me scratch my head that anyone would believe in privacy at this point just boggles my mind.

Let me go back to Susie for a second. I have no idea what information someone shared with her ex-husband, but lets assume for a moment that we're not talking about the Internet or Facebook and we're talking about she and her new boyfriend sitting on a park bench, making out in the middle of a parade. People see this, and even had they only been holding hands and not sucking face, its likely someone would have talked about it with an acquaintance who wasn't there. If your town is small enough, its likely that, eventually, given enough transmissions, the information would make it back to her ex-husband.

In this situation, does Susie have any right to be upset about her privacy being invaded? No. Absolutely not. None. Zero. Zip. Nada.

Don't mistake privacy with courtesy. Yes, it is the height of discourtesy to talk about Susie and her boyfriend to the town gossip (ie, Facebook), yet the fact that Susie chose to make out in the middle of a parade (and given the large number of games, apps and ridiculous scams that are rampant on Facebook's wall feed, it is a parade or maybe even a circus) ensures that she has no privacy.

Susie, complain all you want about people being mean, cruel, vicious and spiteful, but don't for a second bemoan your so-called privacy being invaded when you publicly announced to the world your activities. Anything you post to Facebook, or the Internet in general, will eventually come out. Any security measure, any privacy filter, can be broken with little to no effort for someone who knows what they are doing and are sufficiently motivated to do so. The only way most of us keep our privacy is that we are so supremely uninteresting that it is not worth the small amount of time needed to crack our accounts and share the contents with the world.

So, Susie, if you are really that concerned about violations of your privacy, what should you do about it? The first, and most obvious by now, should be to not put anything online. Stop posting pictures from your last vacation, stop talking about what you ate for dinner last night or about that cute guy down at the coffee shop you really have a thing for now that the ink has dried on the divorce papers.

But if you feel you must post to Facebook, and I'm not advising you to stop, do a few things. First, segment your friends into lists and put anyone you think as questionable on a restricted list which only sees a limited subset of information you specifically want them to see. Second, if you have questionable friends, just boot them from your list. Most people have been using Facebook long enough that they have accumulated enough friends that they won't miss you until you've been gone a long time (if then). Lastly, moderate what it is you do share. If its not something you wouldn't want your mother to know about, Facebook probably isn't the place. Email, instant message, even Facebook messages would be a better option for you than a wall post if privacy is really that big of a concern.

The last point, and this is the one I've been building to this entire time, is to stop complaining about it when you've been 'invaded' due to your own stupidity. No one held you at gun point and forced you to upload that pic of you doing Jagerbombs down at the bar last Friday night. When your grandmother asks to try one of those tasty-looking beverages at the next family picnic, remember it was your choice in what to share, just as its my choice to block your idiot self from appearing in my news feed.

RRR, The Triple-R

2011-05-15T18:49:00.002-04:00

This post originally appeared May 11, 2011 on BetterProjects.net

If you're wondering why my blog post frequency has slowed way down as of late, I've been a bit busy at my day job as we start up a new program. This new effort will be multi-year and could quite possibly end up being the largest project the organization has ever undertaken. Its something we've been wanting to do for quite some time and now have the backing to go do. Its been a lot of fun as I've gotten to do two things I don't regularly get to do in this job.

The first thing I don't often get to do is create wireframes to facilitate requirements elicitation and process mapping. My love of visual design has expanded to a nearly absurd level over the past 3 years and I now find that there is little that gives me more fulfillment than using visual representations to flesh out requirements.

Second to wireframes is facilitating requirements elicitation sessions (using those previously mentioned wireframes). One of the 'trick's I've started doing is to intentionally provide my users with 'broken' wireframes. I give them something that has blatant holes to force them to say, "No, you've got that wrong! Take a piece from the first iteration, add in a part from the second one and slap them all on the layout of the third!" It is truly amazing how your stakeholders will figure out their own requirements just by being able to pick out your (unknowingly) 'bad designs'.

That's all good, you say, but what is this 'Triple R' thing in the title that you're not talking about. One of the things that makes the program I'm talking about so big is that there are many ways in which we could go about accomplishing the exact same goal. Different people within the organization, myself included, have our preferred methods. We all have sound reasons for why we think our path is the right one, most of which completely differ from anyone else's logic. Before we can get on with the work, we need to figure out what pieces of work we will do, in what order and with what technology stack.

In a meeting earlier this week, a subset team outlined 6 different alternatives that could be used to reach the same eventual goal. After we 'named' the different paths, we began to put together a list of items we need to create in order to provide a recommendation to senior management on what roadmap we'll be following to reach the goals we've been given.

We started with a list of Pros and Cons. We talked timelines, both for implementation of the first phase and project completion. Budgetary concerns were raised. Business and technical acumen was discussed. At the end, we had a list of areas that needed to be covered in our presentation, but as I looked at the list, I felt like something was missing. That's when it hit me, we were missing Risk.

Getting to the Cold, Hard Facts

Each of the six options we had outlined were risky. If you put them all on a scale of 0-100, all of them were 80+. What we're doing is risky and there is no way for it to be anything else. Given that the scope of the program will touch nearly everything in our organization, it will simply be a risky venture.

Yes, there are ways to minimize or shift away the risk. We create plans, we build contingencies and eventually we just have to accept some level of risk as being a part of the game. What concerned me is two things: what was the type of risk in each of the solutions and what are the risks that are not shared by all the options.

We know all about the different types of risk: business, technical, regulatory, financial; the list goes on and on. Each of those six solutions had different types of risk, but I wanted to know what type of risk, and the degree of risk, that is specific to one or more, but not all, of the options. Knowing this information allows us to boost the signal to noise ratio; helping our executive team focus on the actual risks within the solutions and not get stuck on the risks they can't change.

As I looked at each of the solutions, they really fell into a couple different types of risk. Some of the solutions were built on technology that has been proven out, so its technical risk is lower. Other solutions follow a build-in-pieces methodology and thus provide a significantly lower organization change risk. Some of the solutions rely, to a greater extent, on 3rd party software licenses and thus, pose a greater financial risk.

With the risk profile so high for each of the options, its important to not only find the types of risk, but to understand that risk is relative. That brings us to the 3 R's, or what I ended up calling the Relative Risk Rating. My suggestion to the group was to not try and minimize the risk rating on any of the options, but given them a rating in relation to each of the other options. Given that each of the options likely had an 80+ total rating, I was suggesting ratings such as High, Higher and Highest, with details next to those ratings about which groups in the organization would bear the largest risk burdens.

The team liked the idea and we're going to give it a try. We're just now started putting together the format, so we don't have a final look and feel for it all, but I can't wait to see what the team comes up with and how it ends up influencing the final decision.

What are some ways you have used to explain risk to your sponsors? Would the Triple-R work for your organization? Let us know in the comments!

Its not what your Requirements do...

2011-05-07T11:03:00.002-04:00

This post originally appeared May 3, 2011 on BetterProjects.net

...but its what people do with your Requirements.

If you've been reading this blog for long now, you know that I'm an unabashed Apple fanboy (who also works with Linux and Windows at his day job, has a Chrome OS netbook, 2 Apple laptops, 2 iPhone 4s, a classic iPod and a 1G iPad). Given that, you probably won't be surprised at how much this article captured my attention. Its something I've believed for a while, that when a product is right, it can do amazing things in the hands of the most common (or even sub-par) user.

Why are requirements not the same? I remember, not so long ago, when I actually told one of my BAs that "You just start requirements by saying 'Have the ability to...' no matter the subject of the requirement." I think back on that and just want to slap my younger self in the side of the head for completely missing the point.

I can only imagine what it must have been like for my user community to read that document. (Come to think of it, that project got killed before it started, so its unlikely anyone ever read that document. Thankfully.) It was likely so dry that they decided War and Peace was a less painful, and shorter, read.

But in the right hands, dare I say the hands of a master requirements craftsman, your requirements can do amazing things for your stakeholders. The biggest thing quality requirements can do is to get your stakeholders to use them.

I've noticed that stakeholders seem to care about requirements at two points. First, when they are outlining their vision or problem to you, the analyst. Second, when they need someone to blame that their vision can't be accomplished or their problem isn't solved by the process and/or system that has been implemented. Part of this is because stakeholders often view requirements as a bothersome process that takes them away from their important work.

Imagine if we wrote our requirements not with system implementations in mind, but with the idea that they teach the business how to operate more effectively regardless of the software they use. Imagine if our requirements documents provided the basis for departmental policy and procedure and not just how we display text on a screen. And most crazy, what if our requirements could plot the future strategy of the organization and not just the layout of the new coversheet for your TPS reports.

So how do we get there? How do we help our stakeholders understand that what we do isn't a prelude to software but is a truly value-add part of their business? I don't know of any magic, but here's a few things I do to try and help.

First, make it about the relationship. Requirements are not a document, series of statements or a big set of process flows. Requirements define needs and wants of stakeholders. The only way to really understand and draw out those items are through relationships with our stakeholders. Its corny, but our stakeholders really don't care how much we know until they know how much we care. Take the time to get to know them as people and to let them know you as a person.

Second, make requirements something they want to review. I'm not suggesting lacing a document with 1 liners or even hiding 'easter eggs' with door prizes attached to see who really reads that 300 pound document. It doesn't need to read like a romance novel, but it does need to be read, comprehended and then become actionable by our stakeholders. We're told we should write to achieve clarity, but what does that mean? The dictionary is written for clarity but by no means do I want to sit down and read that!

It is easier said than done. Most of the time BAs sit between the business and the project team. We're trying to write with multiple audiences in mind. Creating one version of requirements in business-speak and another in tech-speak is a recipe for disaster. Creating one version for all purposes is nearly as bad. What our goal should be is a single, common lexicon that all members of the project speak, one that is specific and measurable enough for the programmers yet encompasses all the vagaries that make up our business people's lives.

This isn't easy; its a delicate balancing act that I have come to realize is something that can not really be taught but must be learned. I've been thinking about ways to teach this for years, yet continually come up empty when trying to show new BAs how to do this. No answer has yet presented itself, but with time I hope to find better ways and then share my insights with all of you.

Requirements Complexity - Expurgated Version

2011-05-04T17:00:00.000-04:00

This post originally appeared April 29, 2011 on BetterProjects.net

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.

Requirements Complexity

2011-05-02T19:36:00.000-04:00

This post originally appeared April 26, 2011 on BetterProjects.net

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.

Oops.

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.

The Danger in User Surveys

2011-04-21T17:00:00.000-04:00

This post originally appeared April 19, 2011 on BetterProjects.net

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?

Giving Them All The Information They Need

2011-04-16T09:00:00.003-04:00

This post originally appeared April 15, 2011 on BetterProjects.net

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.

The BABOK and Requirements Reuse

2011-04-13T17:00:00.006-04:00

This post originally appeared April 12, 2011 on BetterProjects.net

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.

The Shopping Cart Quandary

2011-04-11T17:00:00.005-04:00

This post originally appeared April 7, 2011 on BetterProjects.net

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.

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

2011-04-09T17:00:00.005-04:00

This post originally appeared April 5, 2011 on BetterProjects.net

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!

Who approved the requirements for Google +1?

2011-04-07T17:00:00.000-04:00

This post originally appeared April 4, 2011 on BetterProjects.net

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

Open a new web browser window
Go to 'http://www.google.com'
In the search box, enter 'user experience template' and press enter. Google returns a list of search results.
Click the first link in the search results in the middle of the page
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!

Smoke Test on a Smoke Break

2011-03-30T20:35:00.002-04:00

This post originally appeared March 30, 2011 on BetterProjects.net

A few weeks ago, I made one of those blunders all leaders new to a team makes... I made an assumption, a bad one, about everyone being on the same page regarding our testing process. It wasn't that the team didn't know how to perform a smoke test or that they didn't understand the necessity of performing a smoke test, its just that I wasn't clear at the outset of what my expectation were for the release.

Two days into the testing, someone finally got to what is our primary path for testing of a release... and found that the entire build was broken. This is something that should have been noticed within the first 10 minutes, not two full days of testing later. It was akin to trying to drive away in a car that had no wheels. The problem was so obvious, no one could have missed it. Yet, we did.

Sometimes its easy to get caught up in all the new bling of a release that we forget what it means to hit the fundamentals first. As the leader, the failure was my responsibility. I reiterated to the team why the smoke test was important, we all renewed our commitment to do this testing at the beginning of every build cycle and then went and did it.

Building it Better

But this miss on our part made me really start to think about what makes a good smoke test. Before our little hiccup, this had been mostly ad-hoc; we each took a look at the product, thought about the things that are vital to our users achieving their goals, hit the high points and then ran through as many things from highest to lowest priority as we had time. We were pretty good at this, too (when we remembered to do it).

This just wasn't good enough, in light of the problems that this miss caused. Thankfully, I have a team of really great testers and several others were thinking along the same lines as I. Last week, I finally took a few minutes to start outlining what it was I wanted in our smoke tests and how exactly we should go about doing them. No more than an hour later, with me never having said a word to my team about my personal brainstorming session, two team members walk up and present their ideas for a smoke test. The smile that flashed across my face likely blinded people three isles down the hallway.

I reviewed their initial draft and liked what I saw. They had basically nailed it. There were a few tweaks that needed to be addressed, but the list for our environment was mostly all there. With the hard part of creating the scenarios done, I started to think this situation would make a good blog post about why I was so happy about this particular smoke test. What follows are my thoughts on what makes a good smoke test.

Duration

It needs to take no longer than the worst cigarette addict's smoke break. In the time that the most fanatical nicotine fiend takes to burn through a few Marlboros, the team should know if the build is good enough for full testing or not. If the smoke test fails, snuff out the build and bum another from the development team.

For our team, we set this time at 20 minutes. The development team has usually taken the build for a spin in the testing environment, so its pretty rare when we are set loose that there is a problem that hasn't already been found and addressed. Still, its our first shot at the build and fresh eyes will routinely find issues that are overlooked by those who have been staring at it for hours.

Priority

What is that one thing that, if you can't do, the product becomes largely useless to your users? If this isn't the first item on your smoke test list, you probably need to rethink your list. Is it a piece of desktop software? If so, I'd start with a clean install (or upgrade if you mostly have a static user base). If the build won't even apply to the test environment, there isn't a lot else you can do.

For web testing, that's a bit different, especially in larger development shops like the one where I work. We have an Ops team that handles the deployments and a development team that makes the builds. Each build has passed through at least two teams before my team gets it, so install issues are basically found before I ever see it.

Given that we're an ecommerce site, ordering is the number one priority for our customers. If they can't place orders, we don't make money. We begin our smoke testing here. We look at the many different types of orders, they may different ways of making it into the ordering path and then make sure these all work.

Once the critical paths have been tested, its time to start digging in to the tasks of lesser importance. Add in scenarios until you fill up your allotted time. Don't choose quantity over quality, but aim for a nice medium that allows you to cover most of your system while hitting the really important parts in (relative) depth.

Latitude

But even for a website, not everything is about the web. Mobile and App channels are becoming increasingly more important in our highly-connected society. If our smoke test only concentrated on one ordering channel to the exclusion of all the others, we might be neglecting some of our most important customer's needs.

For installed software testing, latitude testing could be just as important. Imagine if you were testing a new video codec and decided to only test it with a single media player front end during your smoke test. Video codecs are important due to their ability to plug in to many different OSes and architectures, enabling people with all different types of environments to view the same content. Covering as many platforms and devices as possible, especially the ones that are common among your users, is vitally important.

Certainty

At some point, you have to make a call... is this build good enough or not to continue testing? If it is not, you know now and not two days later when you are now behind instead of on target or maybe even ahead of where you believed you would be. If everything tests out, you're not at the end, but you are at the end of the beginning.

An Elevator Pitch for your Project

2011-03-28T09:00:00.000-04:00

This post originally appeared March 25, 2011 on BetterProjects.net

photo © 2007 Daniel Morrison | more info (via: Wylio)I've got a personal elevator pitch. I developed it over the course of a boring, week-long training class that a former employer required me to take. Given the remedial and dull content of the course itself, I had to get something out of my time, so that's where I developed my 'personal pitch.'

When I started as a business analyst, none of my friends had any idea what it was I did, only that I loved my job. (Lets be honest, at that point, I really didn't even understand what I did, even if I was almost competent at the tasks!) I decided that I was tired of trying in vain to explain requirements, process flows and solution designs, so I came up with something a bit easier to understand. Here it is:

I'm a business analyst. I study how people do their jobs. I then figure out ways they can be better at their jobs, either by changing the work they do, how they do their work or the systems they use to do their work.

Over the years, I've tweaked that short description (I did a couple tweaks as I just typed it out) numerous times and its something I'm quite happy with and proud to say about myself. I've spoken with only a small number of people in my life who were ready to go with their own elevator pitch at a moment's notice. Having this little gem waiting in the wings has been of great use to me over the years and I highly recommend everyone create one of these.

Because of my fascination with my personal elevator pitch, I'm always curious to see more about giving elevator pitches. When this article by Don Dodge, about giving elevator pitches for startups, showed up in my blog reader, I was instantly attracted to it. Don gives some fabulous advice for giving a great company elevator pitch, much of which is useful for crafting a personal elevator pitch... or even an elevator pitch for your project.

If you've ever seen me give a product demo, you know its one of my best skills. Last week I was at our company's yearly operator's convention and I had the privilege to give a demo (with a voice so strained I could barely talk) for three hours about one of our newest systems. In the demo booth with me was the hardware vendor whose platform was used as a foundation for the application that we had built internally. At one point, my vendor pulled me aside and expressed to me how impressed she was at my ability to demo a system. High praise from someone who gives an amazing demo herself!

That demo was nothing more than an elevator pitch for our application. Given that I performed the elicitation, analysis, documentation, verification and validation of the requirements for that project, I knew it better than just about anyone else, so I was a natural choice for giving the demo, but its how I gave the demo that made the difference. We made sales all day from people who walked up just to see what was new and left having made the decision to purchase then and there. The system is great, it nearly sells itself, but having a great pitch can only help. Here's the pitch I give.

First, as Don Dodge says, explain the problem. It can't be just any problem, it has to be a problem that can relate to the person hearing the demo. If you can't state the problem in a frame that makes sense to the person listening, you're going to fail. Use their language, their viewpoint and better yet, use them.

I start out by asking, "Have you ever been in situation X?", knowing that they have, otherwise they wouldn't be there to hear me. This is my second point, focus on the person. When they answer 'Yes' to my question, they almost always try to put a spin on the question to let me know that the problem is worse than the scenario I gave. When this happens, I know I've got their attention and its time to begin using the scenario they present as a means to show them how the product meets fixes their problem.

Now, at the third step, I finally acknowledge that the solution has been sitting quietly on the table behind me this whole time. If they haven't seen it before, I give a quick overview, usually no more than 30 seconds, then proceed to walk them through the solution using the demo system. Once they know that the product can meet their needs, I move the conversation to a select, high impact set of features that either show off the best parts of the demo system or that fit closely aligned with their original need.

During this last part, I try to make the demo as interactive as possible, doing my best to have them pose problems and me show solutions to them. Quality back and forth is key in showing how the output of your project can be central to their needs. Once their questions are answered, or if the line behind them is getting really long, I move into the most important section, the close.

Because I'm a natural influencer and not a seller, I tend to shy away from the hard sale tactics employed by many car salesmen. To me, a good demo doesn't need arm-twisting as your project or product will sell themselves. Always ask if there are any more questions you can answer, give the person something they can walk away with (even if its just a cheap printout flier) and most important, give them a call to action. This can be as simple as "I hope you like what you saw. Make sure you stop by the table by the door to speak with the person taking orders!"

So what about you? How do you pitch your projects or products?

It doesn't just apply to startups...

2011-03-26T11:40:00.000-04:00

This post originally appeared March 23, 2011 on BetterProjects.net

Ever since I read his book, The Inmates are Running the Asylum, I have been following the sage-like advice of Alan Cooper. The man is sheer genius. If you're a twitter user, I highly recommend that you follow him.

On his company's blog, one of the Cooper employees discussed the company's difference in opinion on what makes for a successful startup development shop. An agile practitioner, Eric Ries, had suggested that the method for a successful startup is:

Build -> Measure -> Learn.

Cooper suggested that Ries got the elements right, but failed when it came to their order. Cooper said:

Learn -> Build -> Measure.

I couldn't agree more. How many times have we walked into a session with a stakeholder, who started out the conversation by saying, "What I think we need to do is..." without ever once explaining what their problem is?

A recent project of mine started by a drop-in from one of our field operations representatives. He asked me about a particular piece of functionality in our system that had been developed a couple years back but, because of some limitations in surrounding systems, had never been turned on. After a few questions from him about the capabilities, he let me know it what he wanted was different and this function wouldn't meet his need like he thought it would.

Knowing this stakeholder as well as I do, I know he wouldn't be spending this much time on a question if it was a casual inquiry. Thus, I decided to probe further and try to get to the root of the problem. As I started to ask questions, it came out that what he was asking for was really a way to achieve the same outcome that is achieved by one of our competitors, but within the unique confines of our particular business model.

It was one of those situations where, no matter how well you could have planned previously, what he wanted to do was completely contradictory to how the company had done business for decades. It wasn't a bad situation to be in, and what he wanted was a way to respond to a vastly different business environment that had sprouted up over the prior year. Yet, it just didn't fit within any of our existing business rules. A couple options we tried got close, but nothing ever really got 'there.'

So what if I, instead of seeking to first learn, had instead just piled a group of developers in a room and cracked the whip to get them coding? Sure, I might have had a solution sooner, and that solution would allow me to measure to see if the system changes would produce a desirable result. I could have learned first. But if I had gone with my initial first idea on how to solve the problem, without first taking the time to really dig in to the solution, I would have had a problem.

Namely, my first shot at a solution, while much easier to implement than our final solution, would have utterly failed to get at the root problem my stakeholder was trying to solve. The problem seemed extremely simple on the surface; in fact most of our stakeholders were astounded when we gave lengthy development efforts to do what was a simple act when using a piece of paper and a pencil. Eventually, it was the 3rd of 4 potential solutions that was eventually selected as the final answer and it took months just to get to that solution.

So how did we end up with the 'right' solution? There were a couple things we did that made a lot of sense looking back on it:

First, don't rush it. The original timeline we were given was 2 weeks to implement from the time I had that first conversation. It took months just to get buy-in because the seemingly simple requirement, so simple it was summed up in a single sentence by a stakeholder, ended up having massive implications throughout our entire enterprise. Don't scrimp on the analysis. Don't assume your stakeholder's assessment of the problem complexity is correct.

Second, dig in. Ask questions. Ask some more. Ask the first set of questions again, this time phrased differently. Ask someone else the same questions. Keep digging until you either hit rock or you're told to hand over the shovel.

Third, get creative. We had four viable, if radically different, ways to tackle the problem, once we understood it. They all met the core requirements, but some had more risk, some were larger development efforts and some were, frankly, hacks, that would have been a nightmare to maintain. If you looked at these four solutions in a vacuum from one another, I doubt you would ever believe they all solved the same problem. That is a good thing. Each of these potential options were theoretical 'build' steps which allowed us to then 'measure' if the solution was appropriate or not. Turns out, two of them really were not appropriate for our organization. Had we not followed the designs all the way out to the ends of their implications, we could have implemented one of these inferior solutions, causing us to lose much credibility with our stakeholders.

Lastly, over-communicate. About one month after the first conversation, we received sign-off on the solution direction and were beginning to plan the development effort. A seemingly innocent conversation between a BA and a stakeholder ended up turning the entire project upside down. Turns out, despite having said multiple times in multiple meetings what the implications of our initial solution would be, namely that one of the requirements would not be met by the 'quick' solution, our stakeholders didn't grasp what exactly that meant. Once they did, we started the analysis process over again, walking them through the entire set of options once again.

So what do you think of the Learn, Build, Measure process?

Bad Ideas v/s Good Ideas

2011-03-20T21:04:00.000-04:00

This post originally appeared March 18, 2011 on BetterProjects.net

The proper response to a lousy idea is not to stop thinking. It is to come up with a better idea. Indeed, we should prefer a bad idea to no ideas at all, because a bad idea can at least be reformed, while not thinking offers no hope.

I'm currently reading What Technology Wants by Kevin Kelly. The above quote just struck me as encapsulating what it is we as project people do every single day. I hope it inspires you all as much as it does me. The book is not for the faint of heart and its arguments are deeply rooted in history and society. I highly recommend it to everyone who reads this blog as a great philosophical tome on what I'll paraphrase as 'right technology.' Get it today!

(ps... I've got a post rolling around in my head right now based off of one of Kevin's ideas. Hopefully I'll get it written up this weekend for next week's reading on this blog!)

Why I'm a Business Analyst

2011-03-18T21:04:00.000-04:00

This post originally appeared March 15, 2011 on BetterProjects.net

If you've been reading my posts on this blog for long, you know that I tend to focus more on the 'soft' side of business analysis than on the hard skills. As passionate as I am about learning and being able to correctly apply the skills and tasks that make business analysts effective, I am a lot more passionate about the impact good business analysis has on our teams, companies and, if you'll allow me to be a bit dramatic, the world.

I don't know if Apple employs many (or any) business analysts. I do know they employ many amazing designers and developers who may not realize they use excellent BA skills. If you haven't played with an iPad, you really need to. If someone will let you borrow one (provided you can pry it out of their hands long enough) then I suggest you use it for work for a few days. It can change the way you work; I know it changed how I work.

But more so, I see good business analysis making an impact exactly like what you see in this video below. I hope it inspires you as it did me.

The HiPPO: A Project Nightmare

2011-03-14T17:00:00.002-04:00

This post originally appeared March 3, 2011 on BetterProjects.net

photo © 2006 Geof Wilson | more info (via: Wylio)Frankly, Hippos are really very aggressive animals. They've got massive jaw pressure, large fang-like teeth and because they are extremely territorial, will attack any human that gets even close to them. In short, they are not likely to end up on the list as a replacement for dogs as man's best friend.

But I'm not really taking about the Hippos you find in Africa, I'm talking about HiPPOs. While they can share some of the same traits, especially when it comes to territorial protection, Hippos and HiPPOs really are different things.

Hopefully by this point I've peaked your interest just enough to make you wonder what in the world I'm talking about. A HiPPO is the 'Highest Paid Person's Opinion.'

You've all seen it before... you're in a meeting, trying to figure out the solution to a really tough problem. For the last hour, everyone has been tossing out ideas, shooting holes in the ideas of others and generally building to a consensus as to what should be done. The group finally comes to a final decision, only to recognize that there is a shadow hanging over the room, namely that 'Bob' hasn't been involved.

Bob doesn't necessarily have anything to do with the solution. He's a VP and the entire room has been discussing implementation details of a project that has a smaller budget than what Bob makes in a month. Yet, no one wants to make the decision without Bob's input. The meeting ends with one of Bob's direct reports (or worse yet, someone who reports to one of Bob's direct reports) being assigned to go find out what Bob wants to do as his opinion is really the only one that counts, despite him not having the expertise or situational knowledge to make an informed decision.

I'm not a person who thinks that keeping a Bob in the dark is a good idea, but I'm also not one who advocates taking every decision to Bob, either. Taking every decision to Bob leads to decision paralysis and then project paralysis. If no one but Bob can make the decision and Bob is unavailable, work grinds to a halt. So when should a decision go to Bob?

When I'm deciding if something needs to go to Bob, I ask the following questions:

First, what is the impact? Is it big or small? How many people does it impact? Will it have a negative impact on another team, department or division within the organization? If the impact is small, both in people and reach, the decision doesn't really need to go to Bob.

Second, what does it cost? This one is a bit trickier because costs can be difficult to quantify. Is the cost a direct cash outlay? Is it for a deferrable purchase? What are the spending limits imposed by company policy? What are the savings? What department is paying for it? If the purchase fits within the guidelines of the people assembled to make the decision and Bob has previously authorized similar purchases, then its probably safe to say that it doesn't need to go to Bob.

Third, what about timing? Its rare when a decision must be made right now, but they do come up. If Bob isn't available and the decision must be made now, who makes it? Bob's boss? Bob's boss' boss?

Last, what is Bob's personality? Is he a person that expects every decision to go to him? Is there a way to help Bob understand that certain decisions really don't need his input? Is it worth sitting down with Bob to outline exactly what should be brought to him and what shouldn't?

These questions really are not easy to answer, despite them having seemingly easy answers. The same question, asked in the context of a small upgrade project versus a company strategic project may change if Bob should be included in the decision making process.

What questions would you ask before going to 'Bob' for an answer?

Everything is Remix

2011-03-12T09:28:00.000-05:00

This post originally appeared February 28, 2011 on BetterProjects.net

One of my favorite webisodes (episodic web videos) that has come out in the last year is Everything is a Remix. Part 2 was especially inspiring to me... well, it was actually slightly depressing, but it did hit really close to home.

The basic premise of this series is to show how there really isn't anything new in the world and that especially applies to Hollywood movies. That's not to say that the creator of the series dislikes most things produced from Hollywood, just that the makers of movies are always playing off of those who came before them. Even individuals who are thought of as visionary are really just playing to themes of their predecessors (watch all the way to the end of the embedded video to see who I'm referencing).

Part of the way through the video, it occurred to me that most things we do in projects are just remixes as well. Imagine that your organization is starting up a project to install the first ERP system in the company's history. Sounds new, right? Not really. Unless you're writing your own ERP system from the ground up, something that probably isn't very time or cost effective, this exact same system is likely installed with dozens, if not hundreds, of other companies. But even if you are writing your own ERP, its still a remix of what others have done for other ERP systems. Sure, you might be designing one that runs entirely on a smart phone (yet again, something you probably shouldn't do), but you'd hardly be the first to design a piece of financial software for a handheld device.

So its all remix in projects as well, but is this a bad thing? To me, admitting that sounds as if we're saying that there isn't really innovation in what we do with projects. But is that really true?

I think there is innovation, even if just incremental, in how we implement our projects. By remixing our tools, we get better and better development environments, better requirements management repositories and better process analysis suites. We see something that worked really well on a website and figure out a way to add the same concept to our company's internal portal. We are innovating, every day, on a small scale.

What about large-scale innovations? Is this even possible? Google didn't invent the idea of a search engine, they just built one that was better for general inquiries than everyone else. Social networks existed prior to Facebook, but they finally made it cool (and relatively simple) for everyone to use one. Apple didn't invent the smart phone, but they did produce a product that their competitors are still trying to match more than 4 years later.

In the end, I don't know that what we think of as 'large-scale innovation' exists. I begin to wonder if there really is anything truly new under the sun. What do you all think? Is there anything really new being done or is it all just remix?

How to Kill a Zombie... Project

2011-02-13T17:00:00.000-05:00

This post originally appeared February 11, 2011 on BetterProjects.net

I'm not much of a horror movie fan, but I do enjoy a good zombie movie (as long as its one that doesn't take itself too seriously). If you invite me over for Halloween, make sure you've got a copy of Shaun of the Dead or Evil Dead II around, just so we can laugh.

But zombies are real, and those of us who live in project-land, are all too familiar with zombie... projects. They live on, well past their day of expiration. Despite their slow, shambling appearance, they are very difficult to run away from. Removing the head is just about the only way to kill one.

Seriously, how do you kill a zombie project? In a phrase, not easily.

A zombie project usually lives only through the will of someone who isn't doing the daily drudgery and toil that keeps the project upright and shambling along. The best way really is to separate that driving will from the dead body of the project. Sometimes, that just isn't an option. Either you don't have a sharp enough weapon (your argument is dull) or you just don't have the strength to get it done on your own (weak level of organizational influence).

Trying to convince the person driving a zombie project forward is often a difficult proposal. For some reason, these individuals have convinced themselves that there is value to be had in this project reaching completion. It doesn't mean that the project's completion will bring value to the organization; it may mean value only to the person driving the project, but they see value there somewhere. You have to recognize that there is some kind of perceived value there, even if you can't see it.

And maybe that is the problem, too, that you just can't see the value. It might not be that the project is a zombie project, just one that's shuffling along arthritically. No, that's not healthy either, but maybe the project has to go that slowly in order for the rest of the organization to see its eventual value. Taking the time to verify if you're being chased by a zombie or just by some elderly project is time well spent.

Idea Mutation

2011-02-10T17:00:00.005-05:00

This post originally appeared February 8, 2011 on BetterProjects.net

If you've been reading this blog for the last year, you probably realize by now that I am not a scientist (nor do I play one on TV). There are, however, several concepts in science which fascinate me. One of those happens to be mutation, the process by changes are introduced into the genetic sequence.

Mutations can happen in many different ways, either by DNA being impacted by external forces or by internal cellular processes. Be it by virus, radiation, transcription errors or self-designed changes, mutations can be helpful or harmful to the cells.

No, this hasn't become a science blog (and a really rudimentary one at that), but it occurred to me earlier today that ideas also mutate in similar ways to genetic material and do so for similar reasons.

Getting to Why

External forces, such as viruses and radiation, push on genes to make them mutate. External forces like time and budget constraints force ideas to change. At some point in our careers, we've either faced (or will face) a project manager who tells us the budget for the project just got cut in half due to shifting priorities. At this point we find ourselves in an odd situation. No one has yet agreed to allowing us to finish later or to decrease scope, so we get creative... we force our ideas to change in order to fit with our new project reality.

Internal forces also cause our ideas to change. If you're like me, you've started out on some project with a picture in your mind as to what the ideal solution will look like when the project is done. As time passes and you learn more about the forces within and outside your sphere of influence, your idea of the end point morphs. You realize that while others might not recognize that the ideal solution needs to change, you recognize it and know that for the project to reach its fully potential, ideas will need to change.

Ways to Make a Mutation

Now that you know that your ideas must change, you need to figure out how to make them change in the right ways. Here are some thoughts, based on genetic mutation methods, that might help your ideas to change.

First, hit it with some radiation. Radiation is essentially the release of unstable energy. Take your idea and add something to it that makes it unstable, then try to figure out what you could add or take away that would once again make it unstable.

Next, infect it with a virus. Take a bad idea and attach it to your idea and see what the outcome looks like. Its possible that your addition will kill/destroy your idea, but then again, the addition might be just the one thing it needs to survive.

Third, swap around some of the steps in the process (transposons). If your process doesn't seem to fit with what you think would make an ideal solution, maybe your ideals solution is the problem. Take out sections, even ones that would seem like they must remain in place, and swap them or insert them into a different part of the process.

What are other ways you use to mutate your ideas? Let us know in the comments.

Stupid Project Labels

2011-02-08T17:00:00.000-05:00

This post originally appeared February 3, 2011 on BetterProjects.net

We've all see product labels that leaving us scratching our heads trying to understand what it was that the authors of the the product descriptions were trying to convey to us, the purchasers. This got me thinking, what if projects were labeled appropriately? What would these labels be? Some of these could be funny, yet quite meaningful:

Warning! May cause EXTREME profitability! Implement with CAUTION!
Only intended for use by professional stakeholders!
May be harmful if directions are not followed exactly.

Some could also be quite humorous:

Do not use if you cannot see clearly to read the requirements contained within this document.
Warning! May Cause Drowsiness!
Open Document. Open Mind. Keep brain from falling out.
Warning! This project contains nuts!
Warning! Project may cause homicidal tendencies.

What about you? How would you label your projects?

1.00 FTE - Recruitment Guarantees

2011-02-06T17:00:00.000-05:00

This post originally appeared February 2, 2011 on BetterProjects.net

Craig and I have both plugged 1.00 FTE on this blog before. Having hired 3 team members in the last quarter, I can completely agree with the point of this comic. Thankfully, all 3 of my hires were internal promotions and I had great references regarding them all. So far, all of them are turning out to be awesome selections and I look forward to seeing them all grow in their new roles. I am very thankful, and very fortunate, to have all of them. Now, ask me in a year and I'll tell you if this is still the case. ;)

Requirement or Design?

2011-02-04T20:17:00.002-05:00

This post originally appeared January 31, 2011 on BetterProjects.net

The last few years as a BA, I've become increasingly convinced of the necessity of mockups, or better yet high-fidelity simulations, in order to effectively elicit requirements. Yes, text based requirements are still a main-stay and process documentation is routinely needed, but when it comes to requirements for a system implementation, being able to show your stakeholders exactly what will happen is simply a must.

Its because of this realization that sites like Service Design Tools strike such a chord whenever they appear in my news feed. I think the Business Analysis community and the User Experience community have both come to the realization that both disciplines are necessary if we're ever going to create applications that meet our users needs and do so in the condensed timelines that our business partners are increasingly needing.

I love that this site gives you different suggestions for ways to communicate a design, which is nothing more than a visual representation of requirements, to different types of users and stakeholders. Not all of us 'get' requirements in the same way, but these generalizations help us tell the story in such a way that we are most likely to get the message through to our target audience.

The other thing that I think is just great about the site is its ability to inspire me to try out new techniques that are not in my current toolkit. I've never created a Moodboard nor have I created a Customer Journey Map. Sure, many of these techniques would never work in my organization, but the sheer volume of options suggests that there are at least a few items here that might work for me. I can't wait to try a few of these out on my next project.

BASF: Lessons From German Marketing

2011-01-30T17:00:00.000-05:00

This post originally appeared January 27, 2010 on BetterProjects.net

Back in the late 1980s and early 1990s, the German chemical company BASF ran an ad campaign with the slogan, "At BASF, we don't make a lot of the products you buy, we make a lot of the products you buy better." It was, in my opinion, an ingenious set of ads, an example of which you can see below:

There are a couple of things that really stand out to me about these commercials, all of which apply to work done by BAs, PMs and Testers. In the rest of this post, I'll use the above commercial as a jumping off point to bring out a few of these points.

First up, we're not the finished product. PMs create project schedules and budgets, none of which mean anything except as a plan to reach a goal. BAs manage requirement efforts, none of which mean anything unless the requirements are turned into a solution. Testers ensure that what the stakeholder wanted is what was delivered, which can't happen unless something is created. BASF doesn't make airplanes, lotion or carpet, but without BASF, those products would not be nearly as valuable to us.

I also see that its sometimes easier to define yourself in terms of what you don't do. BASF does a lot of things, but in the end, what it doesn't do is make direct to consumer goods but enhances the goods consumers do purchase. Its often difficult for people who don't have a good grasp of chemistry to understand the difference that BASF's products make in each of our lives. In my job, I don't turn in below quality work products, I don't turn them in late and I most especially don't disappoint my customers with an inability to deliver.

Next, emotional connections should not be overlooked. When you consider BASF's actual products: dyes, soda, sulfuric acid, ammonia, plastics, etc, you start to realize that the company doesn't sell much of anything a consumer would want to purchase directly. So why would BASF want to market directly to consumers with such an emotional appeal if it doesn't actually tell anything about what the company actually makes?

If BASF can get the customer to think about buying more airplanes, lotion and carpet, then end product producers will need to purchase more of BASF's products. They're essentially asking customers to pull their products through a channel. When you've got a product that isn't something that sounds easy to sell, falling back on emotion is a great way to get your message through.

This is a concept I rely on when ever I need to tell someone about my work as a Business Analyst. Both words in my title are fairly common, but the combination of them in a title seems to outsiders a bit odd. I know this by the crinkled looks of confusion people sometimes give me when I try to tell them what I do. I could talk about how I elicit, analyze and document requirements, how I translate business needs into solutions or how I help the testing team ensure that the solution met the customers needs. I've tried, and you know what I got? More confused looks. Eventually, I hit on a solution.

Now, whenever anyone gets that weird look on their face upon hearing my title, I follow up with an emotional appeal. My one sentence job description is that "I make people's jobs better by changing the work they do or the computer system they use." That, clicks every time. If they want more detail, I start asking them about things that frustrate them about their computer, or about common frustrations we all share, like hanging out in the waiting room with a bunch of sick people all trying to see the doctor at the same time. I then explain how its my job to find out how these systems are broken and offer up suggestions on how to make life less frustrating to everyone.

And that brings up my last lesson from the commercial, we help people, systems and processes get better. No, I'm not saying we have the deep impact on people's lives that their doctors, therapists or firemen do, but we have a small impact on a lot more broad of a population. The work I do at my current job impacts in the neighborhood of 60,000 employees every single week and millions of customers every single year. Our company runs quite lean in the development and support areas, so a small number of us have a large impact on a medium group of people and a small impact on a really huge group of people.

So what about you? What did you take away from that BASF commercial?

Google Chrome and the Release Cycle

2011-01-28T20:56:00.000-05:00

This post originally appeared January 24, 2010 on BetterProjects.net

Back when Google Chrome debuted, I thought it an interesting concept, but not something I would ever use. I was a Firefox diehard. I was one of the few who could (or at least would) admit to never having willingly used IE. Even during the dark days of IE dominance, when Netscape 4.76 was the only competition in the land, I still refused to move over to the spinning 'E'.

So, one year ago, when Chrome gained extensions on the Mac, I decided I would spend one month testing to see if it was usable. That one month has very quickly turned into one year. Despite the great leap forward Firefox 4 is showing to be during its beta period, I still don't see myself returning to it anytime soon. The release management differences between the two competing browsers is, in my opinion, a lens into my reasons for switching.

Back in July of last year, when Google announced that it would speed up the Chrome release cycle to a new version every 6 months, I was at first incredulous and secondly, I thought it preposterous. Really? What kind of major coding could you get done in 6 weeks that would necessitate an increase in a major version number? It wasn't until I came across this set of slides that I came to understand the answers to my questions:

Chrome Release Cycle 12-16-2010

Reading through the problem, I can see why they moved to the cycle they did. I can't say I blame them as the end of a release cycle is always fast and furious. We tell ourselves, never again will we do this, yet a few months later, we find ourselves doing the exact same thing.

The decision to focus on features and not on release numbers or date driven development is impressive, but sadly probably not an option for most of us who are not Google. I don't think that most non-IT management, and even a lot of IT management, really gets what its like to work a well-run development cycle. It is hard, but giving them a solid date and a version number gives many of them a false sense of understanding because numbers and dates are something they 'get'. If we tell them we have a plan for delivering v17.9 on January 31, then that's great, right? Well, maybe.

But what about that line that discusses disabling features with a single, small patch? This I like. I always wondered how features that take months to develop could be held safely during all that time. If a developer kept all that code on their local drive, which then had a failure the day prior to completion, all that work would be wiped out. Sure, private branches in version control systems could be used, but they clutter up your system with a bunch of dead branches once you're not using them any more.

Another advantage I see is that by doing this, you force the developers to keep dependencies between code modules at a minimum. If any feature can conceivably be disabled with a single patch, you ensure a better, more maintainable architecture on your application.

The last thing that stood out to me was really a question. If you move to 6 week upgrade cycles, why do you really need a version number at all? Sure, its easier for us as humans to remember 'v17.9' than it is a build number output by some compiler, but really, does a version number matter at this point?

From a purely logical standpoint, I don't think it does. Google could still put out a press release every couple of months touting a new release of Chrome that includes feature XXXX or decreases page load time by 17%. They don't need to specify a version number, just that 'you'll be getting it soon'. For the 'About' page in the browser, you just need to know if you're 'up to date with the latest browser version' or if you need to do an update.

Sure, you can say that having v17.9 sound more advanced than having v2.7, but versioning has always been at best an art and at worst, a marketing farce. I am just beginning to wonder if we shouldn't start working towards the 'post release number' era. I don't see that they provide much worth in the modern world.

The Enterprise Reset

2011-01-20T17:00:00.001-05:00

This post originally appeared January 18, 2011 on BetterProjects.net

Imagine if you will a natural disaster, be it earthquake, fire, flood or whatever, hits your company and completely wipes out your enterprise architecture. After everyone sorts out whatever remains of their personal life and returns to work, what do you do? You've got a clean slate. Nature has hit the reset button for you.

(For those of you who work in large corporations who are fortunate enough to not contain your entire operation in a single building, pretend you're a medium size business without a distributed environment to build upon. Or, if you wish, pretend your enterprise baggage can be tossed without anyone noticing!)

My thoughts:

Disaster planning has taught me that the first things to focus on are the critical items; those things that you need to run your business. You can suffer with manual processes and little automation for a short period of time, but there are some things so vital you must have them. Make a list of these items and get to work on them.

Once the critical systems are up and running, consider what you do and do not need to replace. If you've been wanting to do a process reengineering project to consolidate 3 antique systems into a single modern application you've already purchased but are only using a small fraction of, don't put the old pieces back in place. Install the new one and build from that better foundation.

Don't forget that its not all about systems. Some of your stakeholders probably lost a lot of valuable, needed historical documentation during the disaster. Now is probably the time to start up that offsite, electronic document store and buy a few industrial scanners so that the paper isn't stacked up all over the office but becomes a digital repository that can't be destroyed by a single disaster.

What about the location of resources? You're going to need a place to house everyone while you rebuild. Maybe its a time to consider not rebuilding, or at least not rebuilding as much. If the business location was destroyed, but your employees live in areas that were unaffected, maybe its time to start telecommuting or at least creating smaller, satellite offices.

Those are my thoughts. What about yours? Do any of you have a disaster recovery plan (especially those of you who work for smaller organizations)?

Globish: English for the rest of the world?

2011-01-15T17:00:00.005-05:00

This post originally appeared January 13, 2010 on BetterProjects.net

I've blogged a few times in the past about my very first project, a global CRM implementation that replaced 20 different systems with a single instance of a single application to serve the entire service division of a Fortune 500 company. It was an ambitions project, one that did eventually work, but it took a long time to get there.

One of the hurdles that project had to overcome was language. The company was headquartered here in the US, so English was the language used to communicate for most project purposes. When the project team members from around the world came together to talk, we did so in English. We were quite fortunate to have many of the non-US based team members who had either worked or lived part of their lives here in the US.

But there were several team members who spoke only enough English to reach a minimum level of functional communication during team discussions. True, their English was light years above my ability to speak their native languages (which is zero as I speak no other language but English), but had their English been more fluent (or my French/Spanish/German/etc been fluent), it would have meant many fewer struggles to bridge that communication gap.

Because of this project, the concept of Globish really spoke to me. English is not an easy language to learn. Its irregular, has an absurd number of exceptions to every rule and probably worst of all, those of us who speak it use an even more absurd number of idioms to 'enhance' what we say. Check out the video for more information:

What about you guys who work on international teams? Would a minimum set of words and with a simplified sentence structure make communication easier for you?

Putting Down The Headset: BA Lessons from Tech Support

2011-01-13T17:00:00.008-05:00

This article originally appeared December 13, 2010 on ModernAnalyst.com

On January 2, 2002, I took off my headset for the very last time. It was a strange day, leaving technical support, my first post-college job, to head off to be a junior business analyst, supporting the same team which had trained me for the previous three years. Though I was unaware of it at the time when I did the final sign-off of my call center phone, that job had trained me extremely well for the new challenges I would face as a BA.

About four months prior to that fateful day, I had come to the realization that tech support just was not the job for me. It wasn’t that I was unskilled or incapable; I ranked almost at the top of average number of calls taken and fewest average customer call-backs. I supported every piece of hardware our division had ever made on every operating system capable of printing, except for OS/2 (which I was scheduled to train on the same day I found out I was selected to be one of the new junior BAs). No, the problem was, as a call center agent, I was too keenly aware of all the things I was unable to do. I could see the problems our customers faced, I could help them work around their problems, but there was nearly nothing I could do to stop them from having problems in the first place.

As I look back on the last nine years of my BA career, I realize just how well that initial reason for leaving the call center, that desire to make a difference for my customers, has served as a guiding light for me as a BA. Providing my customers with tools and processes that anticipate problems they may have has been a goal throughout my years as a BA.

Lesson One - Anticipation

Tech support agents have one major flaw in their jobs that BAs do not; namely that while both can remove obstacles blocking our customers from their goals, tech support agents are generally powerless when it comes to ensuring their customers don’t encounter that obstacle in the first place. Designers of processes and systems can, with proper support from management, build in functions that keep their products and processes running smoothly. Each of these extra functions have a cost though, either in management time or physical resources, that make including too many of them not as cost effective as beefing up your support team to handle the extra work. It is the job of the BA to research which of these additions will most positively benefit their customers.

I realized this early on when I would receive the same exact call multiple times in a row, with only the customer on the other end changing. Many times, the fix was so simple it seemed inconceivable that, version after version of the software, the same recurring problem remained. Walking the customer through a ‘fix’ was easy, but after you’ve walked hundreds of customers through the same process, you wonder why wasn’t this something that was was obvious to our customers how to fix? The amount of money spent on agent time, management time, center infrastructure and long distance charges in a single day would more pay for fixing the problem, yet the problem still remained.

As a tech support agent, I was unable to effect the change that was best not only for myself, but for my customers as well. As a BA, I still find myself occasionally frustrated by some of the limitations imposed by a product roadmap or management priorities, but for the most part, I am in control of keeping my customers out of trouble. Much of my time is spent designing processes to be fast and flexible, within the defined business rules.

On a recent system replacement project, I modified a system process so that the same goal was achieved on the new system as on the old, yet the required keystrokes decreased from a minimum of 10 plus a password to a maximum of 2 plus a password. Considering this process is repeated more than 100,000 times every day of the year, that is an amazing time savings. Its great fun to demo the process to users for the first time and watch the awe on their faces as they realize how fast, and more importantly simple, we made it. Removing needless complexity for the user means work gets done faster and more correctly than it did in the old system.

Removing needless steps is nice, but it wasn’t the whole goal of that project; we also improved the steps that remained. While the longer-term employees understood more about how to do their jobs, we decreased the training needed for new employees so that what used to take them a month or two to become proficient at their jobs now takes a day or two. Even the older team members who only perform those tasks irregularly benefit as the system now provides them with all the information they need to do the task. No longer do employees filling in for someone else have to search their memory for the correct steps when they are called upon to perform these duties.

How did we accomplish such a win? By anticipating the needs our customers would be facing. The problem we solved was one that no one really even knew existed. 10 keystrokes plus a password does not take a lot of time, so no one really thought about if it could be shortened, at least not until we came along and shortened the process to two keystrokes and a password. I’ve since then realized that had we introduced biometrics in the form of a thumbprint scanner, I could shorten the process to a finger swipe and a single keystroke. If you added in a wireless proximity device with an attached LCD screen, I could accomplish the needed task with zero need for the user to directly interact with the system in any way.

As a tech support agent, I would never have the time to dream up these ideas, much less to be part of implementing them. As a BA, it is just part of the job. No process is ever perfect, so there is always some way that it could be improved. It is our job as a BA to be able to find the improvements that are not obvious to others, evaluate if improving the process would add value to our customers and then be an advocate for implementing the change. That said, it was my time in tech support that made me understand the importance of looking for these problems, even if I did not have time to find the right solutions.

Lesson Two - Speaking the Right Language

My home state of Kentucky is, often unfairly, labeled as a hub of ignorance and backwardness.

While the stereotype does fit certain parts of the state better than others, the place where I lived and worked as a tech support agent most assuredly did not fit the stereotype. Sadly, most of my customers could not get past the mild southern drawl most residents of the state possess and immediately relegated us all into the ignorant and backwards club.

I was more fortunate than most of my coworkers in that years of participation in choir classes had the side effect of removing most, but not all of the accent from my voice. What little accent choir failed to remove, tech support expelled in short order. After a year of being treated as if I was an ignorant hick, instead of someone who has an undergraduate degree in business and was heading towards an MBA, simply because I spoke in a manner that New Yorkers characterized as one step above mentally deficient, I had changed my accent to one that was as flat as the mid-western plains. It was a survival technique, as being yelled at constantly because of an accent is not an enjoyable part of anyone’s job.

Speaking with an accent was not the only reason my customers did not take me seriously; the words I used also failed to meet their needs. After diagnosing an issue with a customer’s device, sometimes the answer was that it could not be fixed over the phone. It is hard to tell a customer that the project that they’re finishing up, the one that had to be on their boss’ desk by close of business, would have to wait another day or two until we could get a replacement device to them.

What I failed to realize early on was why my customers seemed so upset that I was going to replace their broken device with one that functioned correctly. It wasn’t the hassle and frustration of spending time to do the swap, which would only take them a few minutes, but the way I presented the news that they would need to perform this task. During my first year, I was more concerned with fully presenting the customer with all their warranty options before allowing them to select from the possibilities, despite the fact that 99% always opted for the exchange. By presenting the exchange option last and forcing them listen to the other options which were considerably more time consuming on their part, I succeeded only in making the user’s frustration worse. Once I realized why my warranty customers seemed to always be more irate than my fellow CSR’s customers, I wised up and just offered the exchange up front. The change in my customer’s behavior was noticeable and immediate; all for the good.

These two situations, taken together, made me realize that what I said and how I said it was vitally important for a CSR and is equally, if not more important, for a BA. The way we use language, in our spoken communication as well as our written documentation, is often a sign of our maturity as analysts.

This lesson was driven home to me during my first year as a junior analyst, when we were submitting Business Requirements Documents (BRDs) to a review panel prior to passing them along to our vendor for consideration. That team of 8 analysts produced 63 requirements documents. As I was one of the junior members, I was assigned 2 of the smaller, less complicated documents. My two BRDs were each about 2 pages long, contained screen mock-ups so realistic one of my team mates thought I had pirated a copy of the development tools instead of just being a wizard with Microsoft Paint. Contrast that with several of the BAs who had been in the business for multiple decades, who were assigned documents with significantly more complex business matters, that turned in a couple of poorly worded sentences for each BRD.

For years it felt odd that I, the newbie who had never written anything like a BRD, turned in a higher quality work product than people with decades of experience doing this exact type of work. Now, looking back on nearly a decade as an analyst, realize that once again it was my tech support training which prepared the way for my success as a BA.

In 2001, as one of the new hire trainers for my department, I was tasked with rewriting from scratch our training manual. One of the realizations we had from the prior year was that our new techs were missing a very important skill... none of them had used DOS. Many of our support tasks required knowledge of DOS to complete but our new agents had no understanding of how to navigate from the command line, much less muck around in services. It was my job to make sure our new agents not only were at least minimally proficient in DOS but that they had a foundation upon which we could build their knowledge. With that as a goal, I created that new training module, which would be used for years, until the DOS prompt was eventually retired from the support teams altogether.

Being a BA is a lot like writing that training material. I take the information of processes and procedures and then translate it into spoken and written knowledge that benefits my stakeholders. The raw data that we collect is transformed into a valuable asset as it passes through the filter of experience and talent. Our customers appreciate our abilities to grow and learn, especially when we apply that history not only to them, but also to ourselves, in order to provide them with a better experience.

Lesson Three - Meeting Customers On Common Ground

During my last year in tech support, I had several experiences with customers who were, shall we say, less than pleasant individuals. The most memorable had to be a man, who I’ll call Steve, who was mad from the moment I said hello. For the first three minutes of this call, Steve made snide remark after rude innuendo about my company and its products. After three minutes, I had all I could stand of him.

What happened next is something I don’t recommend any of us ever do with our customers, but on that day, in that particular situation, it worked. I did something that caused technicians two cubicle rows over to stand up and stare at me over their cube walls. Yes, I told the customer off. I didn’t exactly tell him where to go, but I did suggest a few nice roads he can take to get there.

After my 60 second lecture on his poor behavior, I finished my comments by saying, “Now, I’ve just wasted a minute of your time. We’ve wasted about four minutes combined now, where if you would have just listened to me in the first place, we would be off this call by now and you could be back doing your job. I’m still willing to help, if you’re willing to work with me. Now would you like to start this conversation over again?” All that was said at a near scream…

As I said, not my best day on the job, but it does go to show why tech support was just not my thing. I was lucky to not lose my job over that stunt, but what happened next was even more amazing... Steve completely dropped his attitude and in two minutes, we were chatting like old friends as we said good-bye. He hung up the phone not only with a working device, but a much needed attitude change.

While this is one of the more extreme examples of giving to customers what they need, it’s also one of the more potent ones. What I did would never have worked with a mild-mannered secretary; I would have likely put her in tears and quickly turned over the phone to my manager, who she would have rightly asked to speak with. However, Steve needed to yell, and more importantly, needed someone to be as passionate about his problem as he was, a service which I, on that day, was for some reason more than willing to provide.

As BAs, we must do the same. Our customers come to us with all different types of attitudes and knowledge levels. We must tailor our message and our methods to our customers.

I once had a rather heated discussion with a developer regarding documentation standards and our audience. The company we worked for had stakeholders of all different knowledge and abilities, so it worked best to have a single requirements document that contained everything from business justifications down to field lengths and validation logic, with everything divided up into sections based on level of detail. Stakeholders with little knowledge could read the first few pages and get everything they needed to know, while those who wanted to know the details could read all 20 gory pages.

To my developer, it seemed that we could break this up into multiple documents and distribute them individually, which would have the same effect. What he failed to understand was that it was impossible to break a document up on the lines he suggested as it didn’t come close to fitting the gamut of stakeholders who needed the information in that documentation. The developer didn’t care about the business justifications, only the functional requirements from which he would create a technical design, so he wanted that removed from ‘his’ document.

Yes, that developer was as much a stakeholder of mine as any of the business users. He had valid points he felt he needed to address; points I took under consideration and eventually walked away from because they would do less good than they would harm to my relationship with other stakeholders. In the end, I made the right call. How do I know that? When you look at the relationship the developer had with our stakeholder versus the relationship I had with them, they always came to me and avoided him whenever possible. A BA lives and dies by meeting their stakeholders in the right place.

Pressing the Hang-up Button

Nine years after the fact, I look back on my years in tech support as a training ground for my career as an analyst, and good training it was! It was far superior to the lessons I learned in my earlier jobs as a production line assemblyman, a car washer and stocking shelves. I expect that on my last day of work, as I pack up my belongings to head off into retirement, that something I do on that day will mirror a lesson I learned while wearing a headset. My only hope is that whatever it is, it isn’t answering a ringing phone!

The Checkout Line: Why is it so slow?

2011-01-12T15:48:00.000-05:00

This post originally appeared January 10, 2011 on BetterProjects.net

My wife and I have a running joke that if you want to spend a long time waiting around to leave the grocery store, you let her pick the line. Its uncanny that nearly every time we decide to not use the self-checkout, we get stuck behind the person who picked up 14 items without barcodes or in the line with the cashier who has decided to work at 1/4 speed this day.

Given that my day job is to manage requirements for a point of sale system, the time spent waiting in line at the store ends up being rather ironic, but it does force me to think about what motions and systems work well and which ones could stand to be improved.

This is why the following video on Queuing Theory was so interesting to me:

The part of this video that stood out most to me was the most efficient way to lay out a checkout line, with a single line feeding multiple registers, was also the most emotionally frustrating way for customers. I know that when I'm standing in line for a roller coaster, with one massing long line up until you reach the station where that one line breaks up into a dozen small lines for each car, that the long line frustrates me, but that frustration goes away when i can pick my own short line.

I think there are some good applications to projects, especially when it comes to release management. Consider the situation where two stakeholders come to you with different problems. You know that in your next release, you have enough open resources to fulfill one of the requests, but not both. There are a couple ways you could consider to figuring out which you fulfill and which must wait.

You could use first in first out (FIFO) methodology and pick whichever request reached you first. This fails to take into consideration the severity of the problems. If both requests took the same time to develop, but one would bring in double the revenue of the other, then wouldn't it make more sense to do the one with larger revenue first?

But what if the one that would make less revenue has an impact to a government contract which must be in place due to a legal requirement? In this situation, no matter the revenue implication, the regulatory requirement would like get pushed to the front of the line.

So what method does your team take to 'queuing' up items for the next release?

Knowledge Externalization: BA Friend or Foe?

2011-01-09T17:00:00.000-05:00

This post originally appeared January 7, 2010 on BetterProjects.net

photo © 2009 Shironeko Euro | more info (via: Wylio)One of the things that I'm known for around the office is using technology in what most people see as 'novel' ways. I was one of the first people to cart around his laptop to every meeting, taking use of the wireless access in conference rooms to open up reference documents or take notes. Now, my laptop gathers dust on my desk and my iPad is my constant companion in meetings. Using Simplenote and Dropbox, I can access and edit all of my documents from my entire career, with just a few finger-taps.

Let me level with you, I hate memorization. Always have and always will. It just seems such a waste of time to me. If I know how to find the information in a very rapid manner, why should I bother to memorize it? It doesn't help that, when you look at my ratings on IQ tests, that memorization is the absolute lowest score of all categories on the tests. I'm bad at it, so I've found ways to compensate for the thing I'm not really all that good at.

It is with this background that brought me to a TechCrunch article about the 'dangers' of externalizing knowledge. Truthfully, I do get the author's point, that if we completely devalue retaining any information, then we will have a lot of problems learning anything new. I just feel that he takes the point to the level of absurdity.

We’re looking up more things, more often, and not because we’re more curious. It’s because we can’t be bothered to retain even the data that matter to us. The GPS in cars is an advance party of this trend: every couple months we hear of some driver who has followed the GPS to the bottom of a lake, or used a highway as a walking path because it was labeled as such on their phone’s map.

Let me contrast that quote with an anecdote from my mother, a 6th grade english teacher on the usefulness of vocabulary memorization versus learning to use a dictionary. She disliked the amount of class time she was required to spend on vocabulary quizzes. To her, if she taught a child the proper way to use a dictionary, then they could deduce the spelling of a word closely enough to look it up and confirm the exact spelling. If she had stopped there in her argument, then the TechCrunch author's points might have been valid, but my mother took it one step further. After a child looked up the same word half a dozen times in the dictionary, they would no longer need to look it up because the memorization would happen. Why would this occur? Simple, the process of looking up the word repeatedly would cause the word to become so familiar that the process of repeatedly looking up the word would become a disincentive to the child.

In simple terms, the bother of looking up that same word again and again would become so great that the word would imprint itself in the mind, just so the child wouldn't have to pick up the dictionary again.

To me, externalization of knowledge is just another way to learn, one that values process and creativity over rote memorization. We learn the information both ways, but using an external repository ensures that we only learn the most important things and allows us to keep our minds clear for what I consider more important tasks: knowledge synthesis and creative thinking. I look up knowledge and spend my time trying to put together the big picture instead of trying to commit it all to memory, then synthesizing it.

For Business Analysts, I think this presents some interesting implications. One of the reasons that I feel I've been successful at business analysis, is that I've developed the skills needed to think like my stakeholders. Given a short amount of exposure to a business process, I can generally determine the needs, fears, wants and desires of the people who carry out or manage that process. I do this not by memorizing every rule, step or decision point in the process, but by immersing myself in the thought patterns of the people in those roles.

When I need to look up specific rules to cite them in a document or presentation, I know where to go find them, either within the minds of my stakeholders or within the policy and procedure documents. After looking up the same information a couple times, I no longer need to look it up as the memorization has taken care of itself through long exposure.

This leaves me time to think creatively about the problems my stakeholders face. Yes, I need that detailed knowledge to verify that the creative solutions I've come up with will meet their needs in the way I believe it will. I open up those detailed documents or facilitate a review session in order to confirm my insights. I use those external knowledge source to their fullest until I have absorbed the information I need, without taking up valuable time to memorize the information in its entirety.

So what about you? Do you externalize your knowledge or do you memorize first? Despite what I've written here, I don't think you are wrong if you memorize first, but it is a strategy that has its drawbacks. I'm sure you can find some drawbacks in my methods as well. Point them out down in the comments.

Thomas Edison and Innovation

2011-01-06T20:00:00.000-05:00

This post originally appeared January 4, 2010 on BetterProjects.net

The long-lasting light bulb. The phonograph. The motion picture camera. When we think of big successes in innovation, Thomas Edison's name can't help but make the list. The man holds 1,093 patents, making him one of the most prolific inventors in the history of the world.

But not all was rosy for Mr. Edison. Despite that large list of successes, there is an even larger list of failures, some of which are quite interesting as they teach some really good lessons. Edison's doll with a phonograph inside it, made me realize exactly how far ahead of his time he was. Had he developed this in the 1980s, when Teddy Ruxpin was all the rage, instead of the 1890s, he might have had a winner on his hands. But in being so far ahead of his time, he ended up more of a loser on this one than a winner.

So what lessons can we draw from this failure of Mr. Edison? First, just because you can build it, doesn't mean you should. Technology is great, but sometimes something more simple, even just a better manual process, might be more appropriate.

Second, don't let failure stop you in your tracks. Edison's failure with the doll happened 40 years prior to his death. He didn't let this one stop him; he was inventing up until just months prior to his death. Learn from failure and make better decisions next time.

Third, learn timing. You don't always have to be first, but you do need to be timely. Being there with the right idea or product at the right time is better than being early or late. There wasn't much Edison could do to wait 90 years for his doll to be viable in the marketplace, but there is nothing to say he couldn't have created the genesis for the idea and then left that for his heirs to fulfill when the necessary technology had reached a cost and size ratio that was likely to make such a doll a success.

Those are the lessons I got from this article. What did you pick up from it?