Thoughts of the Eternal Bachelor

The Price of Free

2012-02-20T17:00:00.000-05:00

This is my second speech, The Price of Free, in the Entertaining Speaker book for Toastmasters. This speech's focus is Resources for Entertainment and focuses on telling an entertaining speech using source material that is not my own.

Consider if you will the two bowls of chocolate here before you. On my right, you will see a bowl of expensive Ghirardelli chocolates. On my left, you see a bowl of common Hershey's Kisses. Both of these foil wrapped sugary bundles of cocoa and milk can be used to satisfy similar urges, but there is something very different about them besides just their molded shape.

You see, for tonight only, I'm giving you, my fair audience here at Toastmaster's, the opportunity to purchase one of piece of chocolate for an extraordinarily small sum of money. The Ghirardelli pieces are but a mere $0.15 and the Hershey's Kisses are a mere $0.01. You won't find deals like this just anywhere!

Now, I'm going to raise each bowl and when I raise the bowl which contains the chocolate you would prefer to buy, I'd like for you to raise your hands to show which you want to buy.

First the Hershey's...

And now the Ghirardelli.

Now, just as I thought would happen, most of you in here are chocolate connoisseurs and picked the Ghirardelli. There is a reason I call this club home!

(Alternate... you all disappoint me greatly! How have I been coming here for nearly 4 years now when you are all so different from me! I know I am a chocolate snob, but really? A Hershey's kiss? Unbelievable!)

You see, this little survey isn't my idea. In fact, I read about it in a book entitled Predictably Irrational, by an author named Dan Ariely. He's a behavioral economist and he studies how people make decisions and tries to understand why we make the decisions we do.

So what did Dan learn when he did this experiment? When people are confronted with the same choice I offered you, 73% of people select the higher priced chocolate and the remainder pick the lower priced chocolate. Frankly, this proves we are rational beings (or most of us anyway), we know a good bargain when we see one and we make wise decisions.

Lets go back to Dan's chocolate experiment, but this time, lets have a bit of a price change. We still have our same two bowls of chocolate, but now we decrease the price of both products by a penny. The Ghirardelli is now $0.14 and the Hershey's Kisses are FREE!

Now, a quick vote again...

First the Ghirardelli...

and now the Hershey's...

When Dan's subjects saw this experiment, 69% selected the Hershey's Kisses and the remainder selected the expensive chocolate. The percentages almost completely reversed.

This shows you the price of free. See, the price difference in both situations was $0.14. The outcome in both situations was that you ended up with a piece of chocolate. The only real difference in the scenarios is that one had something for free and the other did not.

Why is this important? First, it shows off exactly how irrational we really are. Most people prefer a better quality of chocolate, but when offered an inferior piece of chocolate at zero cost, many will sacrifice quality in order to gain the gratification of getting something they really didn't want, but getting it for free.

With the cost so little, and there being no real difference between how much you pay in either situation, it seems that free really does have a price.

This is something that impacts our life in lots of little ways. Lets say that you're about to select a new bank. You've narrowed the field down to two banks. The first offers a checking account with no minimum balance and a small interest rate where the second offers a checking account with a $500 minimum balance, no interest and a free toaster! Which is the better deal? Most people would here the 'free' in the second offer and are more likely to rate that as the better account despite the likelihood of the second account costing more in the long term.

On your last trip to the grocery, what did you see on the labels of products? 'Fat Free!' 'No Calories!' 'No Cholesterol!' 'No Flavor!' (Ok, I made that last one up). These are all methods to get you to purchase something by making you believe that you are getting something extra when in reality you are getting nothing.

So how to we get out of this fallacy of believing that free is better? Ariely doesn't have a lot of specific advice, but the best piece is to spend time asking two questions: First, what are the real costs of this transaction and second, what is the behavior that someone is trying to invoke in us by triggering our 'free' response.

Now, the question I know you all have been wondering since I started this speech and the answer is "YES! I'll be passing out the chocolate in just a moment!" and I won't even charge you as I said I would earlier. Before I do that though, I want you all ask yourselves one question as you open the foil wrapper... what is the behavior I am trying to invoke in you by triggering your 'free' response!

I don't believe in slipping dates

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

This post originally appeared January 30, 2012 on BetterProjects.net

You're in the weekly project status update meeting. The agenda has been reviewed. Last week's minutes are quickly discussed. The PM asks for any new business and finally its time to do that last task we all dread...

Review the project schedule.

The PM opens up MS Project, filters by task end date and asks everyone in the room for a status of the tasks that will end during the next week. Its a painful process, takes at least half of the meeting and most everyone is checking email while their colleagues provide updates.

After all the updates are added to the schedule, the PM asks Project to calculate a new end date, only to find that the project just slipped two weeks.

Oops.

Now the PM goes into panic mode. How did this happen? We were ahead of schedule last week and now we're going to be late! Where is the slack time? Who is on the critical path? Can we crash this thing back to baseline?

The sky is falling!!!!

Or is it?

This situation has always bothered me in ways that I never really could put my finger on, but this week I think I finally understood why this bothers me so much. While on my commute, I was listening to the Back to Work podcast, featuring Merlin Mann and Dan Benjamin, and the topic focused on projects and slipping dates. Merlin's main points were not directly related to my epiphany, but it did get me to thinking some about the whole concept.

Here's the deal... I don't believe dates ever slip, no matter what happens in the project plan. Dates are fixed, and not just because some executives says so. The day a project is over, with whatever system or process changes implemented, is the day it was done. It doesn't matter if that day was weeks early or years late, that is the day the project finished. You can't go back and change that date and since it is now live, you can't go forward in time and make it go live again (at least not with that particular phase).

End dates are always fixed, but what isn't fixed is our understanding of that date. Its possible, maybe in probable, that at some point during the project, something will come up which alters our perceptions of the project and how close we believe we are to its end.

The end date did not change, only our ability to accurately see that end date.

Big deal, you say, the effect is the same. That is true, but I believe that understanding end dates in this way changes our perception of projects in general.

If dates 'slip', this is seen as a bad thing; like we're not doing our jobs or that something unforeseen has impacted the schedule in a way that is not easily recoverable.

If my view is correct, then new information has been assimilated and we now have a more accurate picture of reality.

I don't know about you, but I think my viewpoint feels a lot better.

I Called It!

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

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

Back in June of last year, I wrote a post entitled A new Facebook Use Case where I suggested that what FB really needed was a translation utility for comments. Called it.

Obsession Times Voice

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

This post originally appeared January 19, 2012 on BetterProjects.net

One of the members of my QA team recently said something about me that made me smile. It wasn't that the comment was some kind of over the top suck-up or a snarky jab, but something that was a subtle reminder, in the midst of a sentence on an only vaguely related topic, of why I get up and go to work every day.

He said I was the only person he knew who loved their job.

The sad part is, I don't think he's far from wrong. I do work with several people who I know do love their jobs and it is clear from my daily interaction with them that their passion for what they do comes through in every conversation, every email and every line of code.

Its people like this, those who think of what they do as craft, who inspire me. I'm lucky; in my current job, I'm fortunate to have many of them who work with me. In my career, I've worked with people who are all over the spectrum when it comes to intelligence, motivation, perception, knowledge, wisdom and taste, but rare has been the person who really has a passion for what they do.

Passion is fleeting, but when it is really intense, its something that has you and not the other way around. Its something that I don't think you can fake; its either present in what you're doing or its not. The quality and the responsiveness of your work is directly correlated to exactly how passionate you are about it.

Even though I crossed the line years ago from individual contributor to manager, I still make it a point to regularly go back and do some business analysis work just to keep my skills sharp. Strangely enough, every time I sit down to do a bit of light analysis on a project, I can't help but remembering why I love this kind of work so much, why it fits me so much. Simply put, I get to make a difference for someone (or as I am fortunate enough to do, for millions of someones).

Given that passion, it probably shouldn't be a surprise to any of you that I obsess about projects. There isn't a better way to illustrate this than to realize that for two years (minus the last 4 months), I've been regularly writing on this blog. That isn't easy, especially with a crazy workload, long commute, a 2 year old and a small bit of socializing. Obsession over this topic is something that drives me, not the other way around.

Obsession is a powerful thing that John Gruber and Merlin Mann nailed. Listen to the audio in the link on this page as these are two guys who really understand what it means to take obsession and give it voice. Their obsessions are different, albeit related, to mine and I strive to have a voice that is as strong as theirs. In particular, pay attention to Merlin's discussion of writing about Jawas. Brilliance.

One of the things writing on this blog has helped me with is to find my voice. The last couple years have helped me refine what I really feel is important in a project and the direction I think projects will take in the coming decades. Technology, especially in the mobile space, stands to make a radical shift in how we elicit, document and analyze requirements.

The biggest change, in my mind, will be using video in the requirements process, especially agile processes. We can already do this today, but mostly its done by making some kind of prototype or slide deck, narrating over top of it and letting your remote users get a feel for what it will be like to use some kind of application. Pulling all that together into a produced video takes lots of time and planning. I don't think this will be how we do it in 20 years.

I see our business users watching someone failing at a process, pulling out their pocket communication devices (we better not be calling them phones then!), snagging a video of the incident, tagging spots in the frame, adding some text or commentary on top of the video, emailing it to the project team and waiting a few hours (better yet, minutes!) for the adjustment to the system to be made.

Or how about the stakeholder using that pocket communication device to make the adjustment themselves! Instead of creating only the tool used by the person performing the process, why not create the next great app that is used to create the next next great app?!?

Its ideas like this that really get me excited. My obsession is going full speed and my voice is coming along. I hope you all can say the same.

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.