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.

Footnotes

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.

Is this task appropriate for my job?

One who considers himself too important for small tasks is often too small for important tasks.
(Jaques Tati)

ImageOnce in a while there’s a discussion where people are asking: “Is this task appropriate for my job?” (or role, assignment, or whatever) while they have to perform a specific task that seems to be a little bit outside their usual business.

Well, when we would live in an ideal world this question would be right and I would answer: “Yes, you are right. That’s not supposed to be your job. I’ll find the correct person/team to address this topic”.

Coming back to reality (especially while working for a project oriented company where the “start-up spirit” should still be the favorite way of working), statements like these would kill your business. Continue reading “Is this task appropriate for my job?”

Finally I learned something

After working for years I finally got the PMP certification. 200 questsions and 3,5 hours in front of a computer resulted in a passed exam. Now I’m eligible to put the PMP on my business card…

The next “trouble” is starting now: You have to recertificate every three years by showing your experience in project management. If sounds simple. Everything you do in respect to project management gets counted and you receive points. After 60 points you are eligible to use the title PMP for another three years. We will see…