Protecting your customer … from unnecessary requests

Today I stumbled over a twitter post:

This one is referring to the “product deathcycle”. This picture shows one part of the problem. Another part are requirements which cause the customer to be unhappy about you (the vendor). Every business analyst or requirements engineer knows about those customer demands.

So… Why are some requirements worse than others or why do they even harm the relationship to you.

IMHO requirements that are creating “un-happiness” are those which solve the problem that was on top of the customers mind while the key account (or business analyst) was visiting the customer. I’ve seen so many occurrences where a key account came back from the customer site with dozens of new ideas where most of them are “urgent”, “out of discussion”, “essential for our users” or even “important for our relationship”. Anyhow, the last one is somewhat an exception because that is usually a request to get something for free ;).

What is happening here that most of those urgent requirements result out of a single incident or escalation currently on the desk of the customer. If you solve this problem (probably included in a release several month later) it is out of the customer’s mind and usually therefore not urgent anymore.

Try to evaluate (together with the customer or through experience) if the customer’s requirement is a lasting one (no one time shot, really required and not part of a single escalation). In any other case try to see if the requirement can be

  • cancelled in the first place (i.e. convince the customer that he doesn’t need this requirement),
  • replaced by something the customer really demands (is lasting, improves efficiency, …),
  • cancelled during the offer process or
  • (as a last resort) deny to provide an offer for a specific requirement

The latter two ones are usually the ones with the most negative feedback from the customer. They should be avoided by using one of the first two options.

I cannot remember how often a customer came around with an important report the management (or somebody else) demands. After further evaluation the usual cancellation reasons where:

  1. One time demand (results in one day in Excel or two weeks in software),
  2. Exists already in slightly different form and is sufficient or
  3. Can be easily created in Excel with existing reports or data


Having your first hybrid development project with your new customer

… or “Rome wasn’t build in one day”1

Recently I’ve been invited to speak about hybrid development processes in the context of business analysis in Aachen.

One of the points discussed was how to implement a hybrid development process for a new customer especially if

  • the customer does not have any experience with agile or hybrid process models or
  • the customer’s procurement process does not allow agile or hybrid processes for external projects.

The simple conclusion and recommendation after a longer discussion was to start with something simple that the customer (and you) can handle.

Start slowly

We’ve seen good results with an approach that uses as many features and parts of the hybrid development process the customer can handle at a time; especially if you develop something with a customer who doesn’t have any deep knowledge of agile methodology start slowly.

In the first project we usually stick with the regular waterfall approach (requirements, contract, develop, deliver, accept) and use our agile process internally for development.

While going on with new projects and enhancements implement hybrid features by discussing changes open minded while developing the software. Start with some kind of fuzzy-ness for requirements and pass over to alternatives or a complete agile approach.

Do not rely on a stable customer relationship

Another point: Things change, this also happens while working in an active customer relationship.

Processes, resources and their minds change, and so the hybrid process needs to be adapted to the changes.

Do not think that if the hybrid process is implemented you can use it for a long time without change. If the relation to the customer changes in any of the above cases you may need to go back to start and re-implement the process again.


Hybrid Software Development Process – Writing Flexible Requirements

18-02-_2016_21-58-19During the last posts (here and here) I’ve discussed the overall problem and the hybrid software development process in general. This post will detail the requirements part of the hybrid model.

How requirements are covered and business analysis is performed is discussed in several books, articles and reports somewhere else (please have a look at this search or IIBA for some information).

The basic problem is that several parts of a requirement are either

  • not yet finished (i.e. the user department cannot give a final commitment on all parts of the requirement) or
  • the customer has not yet decided on several options to fulfill a specific requirement

As this information is necessary to create a binding offer while using a regular process/project model, it may be left over in a “fuzzy” state with some restrictions that allow us to create an offer based on the given information.

Any “fuzzy” information known at this point in time is usually more stable than any information from the requirement’s author when the author is forced to give a final statement on a requirement while.

So, instead of insisting that the requirement needs to be finalized, those points are marked as “open” or describe several (similar) “option”s.

Open Requirements

Open requirements are requirements which allow a concrete estimation for the offer but leave enough space to define the details on this particular requirement later during the development phase.

An example of an open requirement would be a report where the data to be shown on the report is defined but the format/layout is still open.

Another example of an open requirement would be a set of rules to define several levels of contribution levels. It is clear how many are there but which account accumulates to which contribution level can be defined later on during development.

It is very important to define the rules and margins on every open requirement to enable the vendor to create a estimation on this requirement that can be used as part of a fixed price offer.

Defining Options

Options define similar functionalities (from the user’s perspective) which allow the customer to decide later on which option to take. The options may have similar efforts.

An example for options is to decide on CSV or Excel (XLSX) format for an import later during the project. In case if efforts are not similar, the customer needs to be aware that as of the fixed price project only one price tag will be communicated and the price doesn’t change in case the customer decides on the cheaper one.

How to manage open requirements and options during later phases of the project

It is very important that the customer is aware of the fact that there has to be a decision to be taken for each and every open requirement and option during the development process. It has to be agreed (latest) during the contractual phase if and when the decision needs to be done. If the decision is not there at the point where it is needed project delays or additional costs may occur.

Agile and Enterprises – No Match Found

I’ve just stumbled over an interesting blog entry: Why Agile is failing.

Cyrille shows in a very smart way the problems that I’m facing while selling our software to our customers. We are working internally according to Scrum (it’s actually ScrumBut, but anyhow), but our (enterprise) customers like to work on a strict waterfall model (for the process, not for their ideas :-)).

What is missing is an acceptance of the customers and a smooth migration strategy especially for enterprises to adopt agile methodologies (and not only for s/w development).

As long as this problem remains, there’s some kind of mixed mode where we try to handle two methodologies in parallel.