≡ Menu
Pawel Brodzinski on Software Project Management

My Private Project: Incomplete Requirements

This is another post from my private project series where I compare reality of house building and software development looking from project management perspective. This time it’ll be about requirements.

One could say requirements for house building project are pretty straightforward – two bathrooms, three bedrooms, one kitchen etc. The problem is these are coarse-grained requirements. At the beginning you don’t know about a lot (and I mean a lot) of fine-grained requirements which you become aware of during the process.

You don’t try to decide where exactly radiators would be placed or which switch will turn on which lamp and where exactly the lamp will be hanged. Actually you don’t need to know all these details at the moment you still have bare walls. That’s so agile by the way – coarse-grained requirements up front and setting up details only for nearest tasks.

Unfortunately way earlier than you’ll be designing how rooms will look like you have to make up your mind since plumber and electrician have to complete installations before you start plastering inside. Vendor, let’s take electrician for the example, is facing incomplete requirements. They want to know every detail of electric installation so they ask a project sponsor – you. The problem is you don’t really know since for you it’s too early to decide.

You end up not giving much detail to electrician and having random electric installation or making your decisions on the fly. Either way it’s definitely not a perfect design. You gave incomplete requirements and you, as a project sponsor, are the one who suffers.

How it is compares with our professional lives? Hidden and forgotten requirements are basically the same. Even in BDUF (Big Design Up Front) projects it is impossible to have all requirements included. The painful way we learn which requirement we forgot about is also similar. It’s usually vendor which comes to tell us, or rather ask us tough questions, about things which aren’t defined yet they should.

The main difference is in the way the issue is resolved. When building a house you don’t expect that builders would share your vision of the final product. You just give them specs and they ask you about anything which isn’t there. When building software it is different. Instead of specs you give a vendor something like a description of a vision of what product should look like. When after all it appears the product doesn’t fit to the vision because the vision was vague or it’s changed in the meantime the vendor is the one to blame for “failing to deliver business value” or something.

Maybe the problem lies within specs. With the design specs for the house even I can say which parts weren’t done according to the original design. Specs are pretty unambiguous. With software functional specification will never be all clear. The whole software thing is actually pretty darn ambiguous. Yet everyone expects we’ll somehow transfer our visions between our minds. It’s a bad luck we haven’t yet invented transfer method which is lossless.

Whole my private project series

in: project management

0 comments… add one

Leave a Comment