Tag Archives: requirements management

MVP versus MPP

The big buzzword these days seems to be MVP, meaning Minimum Viable Product. It’s a reference to the approach to product development described by Eric Ries in his book The Lean Startup. However, while I’ve been hearing and seeing the term MVP a lot, I’ve almost never seen anyone executing the process that Eric Ries describes.

More often than not, what is called MVP is what I call MPP, or Maximum Possible Product. The word Possible has a double meaning: Continue reading

3 Comments

Filed under Minimum Viable Product, planning

When to use User Stories, Use Cases and IEEE 830 – Part 3: Requirement Statements

Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended  for specifying software requirements in IEEE standard 830, and still are in 29148:2011.

The IEEE standard for software requirements specification recommends this method as they have many advantages  Continue reading

Leave a comment

Filed under business analyst, documentation, requirements

When to use User Stories, Use Cases and IEEE 830 – Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading

Leave a comment

Filed under business analyst, collaboration, customer participation, documentation, planning, requirements, story writing, You're doing it wrong

Series: Requirements – You’re doing it wrong Part 1

Most of you have probably seen this meme on Facebook, Twitter and elsewhere. Generally it is an image, probably taken out of context, of someone demonstrating a lack of understanding, with a comment to the gist of “You’re doing it wrong.” While these images are a little extreme, I’m sometimes reminded of them when consulting on requirements analysis. I’m not saying that organizations are often completely missing the boat, but I’m pretty sure that if they stepped back a bit they’d quickly see their problems for themselves.

Before I start with my first topic in this series, I’d like to quote the IIBA‘s Continue reading

Leave a comment

Filed under collaboration, customer participation, requirements, standards, Uncategorized, You're doing it wrong

Why Business Analysts need to be generalists

Historically the Business Analyst position has been a grab-bag of roles. In some organizations the position is effectively a power user who has expertise in one or two systems and is responsible for analyzing and delivering service requests for those systems. In other organizations the analyst is nothing more than a scribe, responsible for recording meetings and completing documentation. Still more are pure business experts who act as subject matter experts as a proxy for the business.

The founding of the the IIBA 9 years ago started to resolve this problem, just as the creation of the PMI helped define and standardize the project manager position and activities. However, Continue reading

Leave a comment

Filed under business analyst, requirements, self-organizing

Leading the horse to water

In my last post I described 3 reasons customers cite for not participating in development. One of the reasons, and one that a project manager or business analyst can impact directly, is the customers feel that the meetings are not a productive use of their time. They feel the meetings don’t accomplish anything, take too long, or that they were unable to contribute and their presence wasn’t necessary.

I’ve witnessed many meetings with customers that I would describe as dysfunctional, and I’ve worked in many organizations where meetings with no agenda, no direction and unclear outcomes are the accepted norm. The focus Continue reading

Leave a comment

Filed under collaboration, customer participation, planning

Honey, Vinegar, and Customer Participation

Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:

“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”

This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:

“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”

I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto: Continue reading

Leave a comment

Filed under agile, collaboration, customer participation, requirements, scrum

Flattened Requirements Management

 (Originally posted here January 13th, 2012)

In 2003, Thomas Friedman wrote in The World is Flat how ten factors, which he called ‘Flatteners,’ have converged to create a more level playing field in terms of doing business, making it much easier for organizations in developing countries to compete with developed world companies in a number of industries. One of the flatteners is supply-chaining, which he describes as “a method of collaborating horizontally – among suppliers, retailers and customers – to create value.”

He predicted that in order for organizations to succeed in this flattened world, they need to learn to work closer and more collaboratively with their suppliers. Continue reading

Leave a comment

Filed under complexity, requirements