Category Archives: Business Analysis

Articles of interest to business analysts, or otherwise specifically about business analysis. Topics are mainly about business process analysis, business requirements analysis, and how to be a good business analyst.

Who Are Your Customers – Comparing Products Part 2

The first step to comparing products is understanding your customers.  This may seem counter-intuitive, but your product’s capabilities are meaningless unless you are comparing them from your customer’s point of view.  This article is part 2 in a series on comparing products.  Check out part 1, then continue with this article on the first steps of comparing products.

Continue reading Who Are Your Customers – Comparing Products Part 2

Compare Products Not Specs – Comparing Products Part 1

Recently, the gadget-reviewer crowd has caught on to something we’ve known for a long time.  Comparing products is not about comparing specs, it is about comparing how well the products solve problems that customers will pay to solve.  That begs the question – how should you compare products?  Read on to see the product comparison technique I recommend.
Continue reading Compare Products Not Specs – Comparing Products Part 1

Agile Estimation, Prediction, and Commitment

Your boss wants a commitment.  You want to offer a prediction.  Agile, you say, only allows you to estimate and predict – not to commit.  “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.”  There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.

This is an article about agile product management and release planning.

Continue reading Agile Estimation, Prediction, and Commitment

Requirements Management Journey – Part 0

Requirements Management – I’m embarking on a journey to help several teams manage their requirements with their existing systems and tools.  This is the first in a series of articles, where the rubber meets the road.  I’ll look at both the theory and the realities of what works (and doesn’t) in practice.  I hope you’ll come along for the ride.
Continue reading Requirements Management Journey – Part 0

Nokia’s Smartphone Strategy – Maximin

Nokia, the Finnish mobile phone manufacturer, is getting clobbered as their market rapidly moves away from them.  Recent analyst reports show that Android and iOS (Apple’s platform) based phones are rapidly gaining market share.  Nokia sells neither.  Nokia has a major press event in a few hours, where they will announce their smartphone strategy.  I think a maximin strategy is both likely and correct.

Continue reading Nokia’s Smartphone Strategy – Maximin

Everything Old is New Again

A lot of teams that I’ve worked on and with get hung up when thinking about defining requirements for “migration projects” and “system upgrades.”  There’s some intangible barrier to being market focused when it comes to improving existing internal systems.  Every new product represents a solution to an existing problem.  Why do so many projects move forward with teams that are blind to the actual requirements?

Continue reading Everything Old is New Again

Don’t Prioritize Features!

Estimating the “value” of features is a waste of time.  I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm.  Yes, you can get to an answer, but so what?! The important thing is to solve the problem.

Continue reading Don’t Prioritize Features!

Agile Documentation

Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto.  That doesn’t mean don’t document!  It means don’t document more than you need to document.  Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile.  How do you avoid over-reacting when changing a culture of over-documentation?

Continue reading Agile Documentation

Provocateurs Gather the Best Requirements

Ask someone what they want, and they’ll tell you they want a faster horse.  Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.

Continue reading Provocateurs Gather the Best Requirements

A Prototype is Worth a Thousand Lines of Code

A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Continue reading A Prototype is Worth a Thousand Lines of Code