the importance of a good spec...

[RafkeMagic]

It's been ages since I have received a decent spec and today was another example of how that can lead to (serious) issues and most of all a waste of time (and money, as time = money). I've been working with SAP software since March 1997, first as a developer and since 2000 mainly as a BW consultant. Back in the 90s specs were still common, but that slowly disappeared in the "nillies" and seems to be completely gone since the 10s. Maybe it's just on the projects I work on, but I think it's a more widespread issue... especially when looking at some of the posts here, I sometimes think other people are even worse off than me.

What is the point of a spec?

For starters to have a clear description of the "problem / issue / request" at hand, but also to specify what exactly is expected from you (the consultant / project member / developer). No rocket science, right? So, why is it so hard to write a (good) spec? On some projects I have worked on, it wasn't even clear who should write specs? Really? Yes, really! It should be quite Obvious: he/she that requests a certain report (to keep it in the BI world) should be able to specify what it is they want. Next a "functional" consultant should "translate" that to SAP/BW language, so that we understand it. This means a spec should be written by a combination of one or more business people and one or more functional consultants. In my experience, that hardly ever happens... "business" usually has no time (really?) and they want things yesterday. The functional consultants quite often claim they don't know BW (even though you explain them several times and let's face it, it's not thàt hard to understand the basic principles) and if they put something on paper, it's usually so "vague" that you could probably deliver a zillion of different reports/setups to get "something" that is described in the "spec".

So, how do we know what to do? Well, you have a meeting (if you're lucky... usually it's multiple meetings) during which some people vaguely describe what they want and they try to make it sound really simple and straight forward. In a lot of cases they also wonder why they don't have such a report already? (those are my favorites... not). During the follow up (or status) meetings, the (non-)specs have a tendency to "change".

What's the impact of not having a (decent) spec?

Well, in the approach described above, you start with a basic setup and you try to "deliver" on time. Over the course of the "project", certain definitions (or even concepts) change, so you start bending & stretching your model to accomodate for these changes. This works in 90% of the cases... what if you're in one of those 10% though? One little change in the "requirements" litterally requires a complete new setup because the "tiny change" for the business, means a totally different logic. Today I was faced with such a "small" change that we actually implemented "between the soup and the potatoes" (Dutch expression litterally translated into English which means there was not a lot of time to do it) a couple of weeks (maybe even months) ago, but "suddenly" someone noticed that the report was no longer giving correct results. After more than half a (working) day of debugging, I came to the conclusion that the entire "logic" that was once true, has now become false. Is there time to "rethink" this? No... so, another work around is in the making.

So, by not really having a spec, we wasted a couple of weeks (I didn't work full-time on this as I was assigned to multiple clients) and now we're back to the "drawing board".

I really feel that this is what I have been doing for the past 4 or 5 years... and this can't be good, right? Surely I can deal with it and I am capable of changing logics completely, but that's no longer "fun" (or a challenge)... rather it's becoming a serious drag. Just wondering, am I the only one noticing this trend or are there soulmates out there?