Once again I have heard from a colleague from the development discipline that a requirements analyst is proving to be an obstacle to success because once the customer signs off on the requirements specification, the analyst considers his work to be done and disappears over the horizon.
Very pretty and neat, but... WRONG!
If I had any hair, I’d pull it out.
If you are a requirements analyst on a BPM project and you are still following anything that resembles a waterfall approach, you need to sit under the cold waters of that waterfall and wake up.
As a requirements analyst, your job isn’t to produce requirements artefacts, and it certainly isn’t to simply write down what the customers say they want and then regurgitate that in accordance with some template or other.
Your job is the same as everyone else’s job on the project: to produce a working system that meets the customer’s needs. Your job isn’t done until the system goes live.
So throwing your signed-off requirements specification over the fence and folding your arms is the wrong approach.
This is why I believe requirements analysts should be part of the development team. In other words, the people gathering and analysing the requirements are the people who do the development work. Sure, there may be a lead analyst who guides and supervises the developers during any work on the requirements, but each developer should do their own analysis.
And I don’t just mean developers who show up at workshops and apply a design mindset to the problem domain and then smugly note “analysis” on their curriculum vitae as one of their skills.
I mean developers who actually understand the difference between analysis and design (and can explain it in fewer than twenty words) and who can switch between the two mindsets as needed.
I don’t believe you can apply a waterfall approach to BPM projects. And if you accept that, then you cannot have requirements analysts on a BPM project who can only do analysis (and I’ve met a few who cannot even do that). The work has to be approached iteratively and the teams have to be multi-talented – specialised, to be sure, but multi-skilled.
Hmm… I think this is my first rant on this blog. It feels good.
Related posts:
Let it out Declan! I agree with you 100%.