Well I’ve been a bit quite of late as I have been on some much needed rest and relaxation so I have sadly neglected my blog.
I have had a number of comments with suggested tools to consider and comments wanting to know which requirements management tool we choose. After a couple of months of assessing different requirements management applications we did propose Holocentric to the management team. We liked its requirements management flexibility, business process mapping, ability to map relationship and traceability.
We hit a wall though when it can to implementation and unfortunately have had to go back to our previous tools. There were two main barriers.
1. Cost: Set up costs of initial training and licences required to to use the product (these costs were not part of the original project budget so would require new funding).
2. Downtime: We had invested so much time already using the current tools that to convert our current work to the new software would mean a lot of rework to get to the same point and extend the project time-lines.
So, whilst it was too late for this particular project, we now are aware of other tools out there and can captilise on these for our next project.
Scope creep is annoying, but what is more annoying is doing all the business process maps and documentation in visio and word. The changes and flow-on affects of these changes then need to be manually changed in the documents.
I am currently looking at some software tools to support my current project so that I can have enhanced traceability and be able to quickly work out what requirements are impacted when a certain element changes (eg cannot now be delivered in this current release).
I am working in an agile environment where there is rapid change and the business needs are evolving and this needs to be manged. Requirements are never really complete until the project is finished as the needs of the business will inevitably change over the life of the project development. Telling the business “it is not in the spec” doesn’t solve the issue that they need this change.
In this type of environment it important to know the “ripple” effects of a change to a particular requirement (eg architecture, design, code, tests and deployment). What a first may be a minor change, can indeed be very costly.
Requirements management done well can help your project to deliver the benefits the business is looking for, without you having to get frustrated by the process. I am hoping that the tools we evaluate may help to support our requirements process and help to ensure we can adapt to the rapid changes required in this agile environment.
Recently I attended a session on the “7 Pillars of Wisdom-Requirements” by Suzanne and James Robertson. It was a great session and reinforced what I have been thinking for some time about why some BAs succeed and others do not.
The fourth pillar that they spoke about was that “requirements come from people”. This I believe is the key message for BAs. Yes business analysis is about the business and the system, but it is also about the “people”, the “users”.
My background before the BA life was business management and communication. My technical expertise has been learnt from experience at both the client and technology group end. I really agree with Suzanne and James that gathering requirements is a “sociotechnical” business. You do indeed need to find out who all the stakeholders are to find out all the requirements. You also need to keep them interested and motivated throughout the process and that’s about communication.
People love to talk about their business. If you take the time to really listen you will uncover what they like and don’t like about a process and what opportunities they see for improvement. Getting initial interaction to get some high level requirements is the first step, but not the only step. The systems that are developed right, are the ones where there has been stakeholder engagement from start to finish.
Unlike some of my collegaues, as a BA, I don’t think the process finishes when I have delivered the requirements document. I believe it is only the start. Keeping the stakeholder engaged through the development and testing process means maintaining a level of enthusiasm and passion for the project. OK, I admit that sometimes this role may be filled by the project manager, but I find, that if as a BA you have developed a great working relationship with the client, your passion and enthusiasm for the project will help ensure you get requirements that are not only sound from a technical perspective (as you have uncovered all the needs for the system) but you also have a system that works from a useablity perspective. Happy User = Happy Client 
Recent Comments