Search This Blog

19 November 2011

Product pitching vs software requirements

I was recently in a competition which involved doing a 60 second elevator pitch to a panel of judges, and learnt more than I expected from the experience.

My first main takeaway was the amount of effort required to really crystallise into just a few words the problems which I was proposing to solve. Expressing the problem is the absolute kicker in a product pitch, but it also made me reflect on my BA work. The standard requirements template I work with every day has a 'business need' section under the title. It can be easy to get lazy with that and just basically restate the requirement title in more words, rather than go that step further to actually capture the essence of the problem.

Likewise within the standard user story format, what follows the ' that' component should really hit home to help everyone understand the value of what we are setting out to achieve. A nice metaphor that was passed on during one of the competition pitching workshops was "put your listener/reader 'out in the hot desert' with your problem description, so by the time you propose your solution they are so thirsty they're willing to pay $1000 for the glass of water you are offering!".

The second takeaway stemmed from standing in front of actual investors and feeling the potency of the situation - I'm asking these people for cold hard cash and they need to be convinced of the financial return they'll receive on the basis of this idea/solution!

This experience has given me a new perspective. Sure, my project stakeholders aren't usually dipping into their personal finances, nor are the risks as high as funding a startup idea. But still, there are stakeholder's professional reputations and real money on the line. As a BA I need to play my part in making sure that the problem actually exists, it has been properly analysed and captured, and that measurable value is delivered at the end of the day.

18 November 2011

Embracing Constraints

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!

17 November 2011

Introduction to User Stories

Folks I am running my online Intro to User Stories course again.  Sign up via the training page on this site.

Once again the course is free.  I have taken on feedback from the last group and spread the content out over 5 weeks rather than force people through heaps of stuff in 5 days.  I hope it's a little more of a relaxed pace.

If you are interested in what I consider a really good explanation of the techniques and a discussion about the principles and surrounding issues (e.g. "What sort of documentation do we create?) you might like to sign on.

And of course, you should probably refer a colleague.

14 November 2011

My love/hate relationship with 'Being Busy'

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.

11 November 2011

ISEB on Wikipedia

From time to time I see new or aspiring business and systems analysts asking the forums whether they should go get certification.  Until the IIBA brought out their competing material the most frequent response was to take a look at the ISEB certification in Business Analysis.

I bring this up because I went to the Wikipedia Business Analysts article again today resolved to have a go at making it better. I usually fail in my attempts because there are so many issues with the page as it is today.  Anyway, rather than bite off too much I took a look at BA certifications and well, one thing led to another and I have drafted an article in ISEB to replace the previous poorly formed entry.

My proposed (and lean) article is below.  If you have an opinion, I'd like to see your comment below, but even better - head over to Wikipedia yourself and help improve the page.

What is ISEB
ISEB is a part of the British Computer Society (BCS). It is a certification body that accredits people to BCS standards within a range of business and information technology specialisations. ISEB is a acronym for Information Systems Examination Board.

ISEB started shortly after the creation of the BCS in 1957 to act as a certification body. The purpose of the certification body was to provide a standards group within the industry in the UK.

ISEB provides a three tiered certification model from Foundation, through Practitioner level and on to Advanced level.

Subject areas
Certifications are mainly built around Information technology competencies, however within the framework there are also several more generalist management certifications.

ISEB licences the ability to delivery courses that prepare for certification.

Other services
ISEB also publishes books, papers and holds events and conferences.

International Presence
ISEB is based in the United Kingdom but claims a presence in over 200 countries, mainly through certified people and training organisations.

Related topics

  • BCS, 
  • Certification, 
  • Information Systems

Sources for my history notes

6 November 2011

How to organise a Children's party

In 2009 I first heard this story. It's still a great introduction to how complex problems don't always need complex solutions.

I'm also looking forward to hearing David speak on Wednesday night this week when he comes to Melbourne, and of course to persuading him to come for a beer afterwards.