(A short rant about eye-contact-based specifications.)
In short, there is no such things as an eye-contact-based specification. And for a reason.
While kicking-off of a project, we had a discussion with the customer about the change management approach, and specification detail. (more…)
Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!
Methodology is a tough topic. There are good methodologies, there are bad methodologies, there are good methodologies gone bad. Methodology is not a silver bullet, it won’t just make any problems disappear, and is hardly ever the single source of success or failure. But a methodology can be a major contributor to success. I could put it this way: you stand much better chances of success if you apply a methodology, then if you don’t. With something as critical as an implementation of business software, methodology is a key success factor. According to Jim Johnson of Standish Group, it’s number nine on their ten identified most important success factors.
[Updated]
I had to update this post a little bit, see below for the details, but the killer feature had to go 🙁
[/Updated]
Remeber that tool “Automated Version Management” that I published here and on Mibuso five months ago? It has just got an update: version 2.0.
A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said:
– We aren’t implementing a new solution so that everything can stay the way it was.
How often does it happen to you that your customers say to you a similar thing: “But in our old system…”? What do you say to them? How do you approach change when your consultant proposes a new way of doing things, or a new approach to a common problem?