In my recent post on requirements templates, I found that many of you fall into two very different camps. While some of you have formalized processes and sets of documentation requirements for your software projects (this can be helpful or hurtful), others have nothing. Those of you in the latter category feel you need to start from scratch every time and that this is counter-productive.
Given that this is a common challenge, I thought I’d share a bit on the way I approach project situations with little to no processes in place or templates to use.
- First, I get my head around the scope of the project and the need for documentation. Documentation should fill a need. The more I know about how my documentation will be used, the better I will be able to provide the right documentation.
- I evaluate what stage the project is in. Is there a budget in place and a development team ready to start? Is there a need to evaluate off-the-shelf solutions? Do we need to start with a scope document to support a go/no-go decision on project funding? I make sure whatever my first deliverable is helps drive the next project decision forward.
- I often hunt around in my archives of past work for something I’ve done to fill a similar need. After a few years, I’ve got a repository of everything from a 100-page requirements monster to a 1-page epic to a data feed specification to a user interface specification to a 10 page project scope document. I’ve also started building a repository of templates to use with my favorite sections, questions, and gotchas.
- If I’m approached with a new situation, I do a few internet searches to see if there are any suggested practices out there. I also pull out my favorite books for ideas. I might reach out to a few colleagues or contacts for help. As a side note, asking for help with requirements challenges is a great way to stay in touch with your professional network.
- I create a preliminary plan of what deliverables will best serve the project. Sometimes this is a full-fledged requirements management plan. Other times it is simply a plan to get to the next decision.
- Finally, I discuss some options with the project leadership and document consumers. I seek out their input on what would help them take the next step.
I’m probably a bit unique in that I never fully trust a template. A template is a good starting point, but it is no substitute for good thinking about where your project is at and the next step you need to support. Templates and repositories of back work are good because they help you avoid repeating mistakes, but they do not do your process work for you. Every project is a little bit different and needs some special TLC.
It might be worth thinking through a few of these questions before starting in on your next template-based deliverable. They can help you identify weak points in your process for the project in question so that you can add more value as a business analyst.
If it were easy, anyone could do it.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 18 comments }
With the greatest respect for my BA colleagues, most of what you’re asked to do is a symptom of the ‘failure’ of IT as a discipline.
In reality, requirements (especially the way in which they’re gathered and managed in most cases) serve only one purpose — facilitating testing. They are typically useless for ensuring the success of a solution. They were empirically proven nearly two decades ago to not be adequate for delivering successful solutions.
And starting from scratch…is just more nonsense. There’s a business context that every solution fits into. Unless you’re in a consulting role and are immersed into different business models at every turn, the primary value that anyone can bring to the type of role that BA’s fill is to create a collection of evidences that provide relevant context for every solution (addressed briefly in this piece about ‘intent’ http://www.fastforwardblog.com/?p=3298).
Another valuable analogy to consider is the model employed by commercial building. In that model, assume that Requirements and ensuing Development are not part of the activities of the General Contractor, but are one of the responding trades. That means that a larger architectural/design effort has gone on prior to the ‘response’. In that prior effort, blueprints are already drawn up and specifications (not requirements) have been delivered. The ‘requirements’ are the responses by the individual trades as to how they plan to fulfill the specifications.
The fact that we have a huge phase missing in the discipline of the SDLC and that it starts with some ‘poof’ of requirements has been a fallacy for decades. One that I’ve been on the constant search of the issues and reasons for.
With all due respect, Paula, I believe you misunderstood the intent of my post. I was talking about starting from scratch in the context of process not business knowledge. And understanding the context in which your work will fit, that is exactly my point in the first few steps.
As to what a BA is asked to do vs. what I see us responsible for on teams creating successful software solutions, that’s an issue I’ll take up in another post.
Laura
In reality, requirements (especially the way in which they’re gathered and managed in most cases) serve only one purpose — facilitating testing. They are typically useless for ensuring the success of a solution. They were empirically proven nearly two decades ago to not be adequate for delivering successful solutions.
Paula, I’d really appreciate it if you could point me to this empirical proof. I flatter myself that I am quite widely read in the field and I don’t know of any such research.
Requirements “were empirically proven nearly two decades ago to not be adequate for delivering successful solutions.” Citation please?
A building construction analogy? With some assumptions many would not make? Hard to take this trip…
The linked post is interesting, business adaptation at the point of customer/supplier interaction, but its application to this topic could be clarified.
Laura: I did understand that you were talking about the process. I’m questioning the process itself, as in, what difference does it make which approach you use if neither of them are relevant? The variable is irrelevant if the numerator is zero.
Kevin: It may seem a cop-out, but sadly the reference was pre-internet, but it was real…it was but a 1-page commentary in a technical magazine circa 1989. It changed the direction of my focus of work. I’ve looked for it since but have not found either the piece or the corresponding research.
They effectively did the equivalent of the show ‘Myth Busters’, starting with the assumption that projects fail because the requirements aren’t gathered/audited/filled sufficiently. They audited the process: all of the stated requirements adequately recorded (check); all of the stated requirements adequately fulfilled (check). System failed.
Then they brought in anthropologists/ethnographers (in this case the context was an emergency room system of record), who observed what was happening in the context of the work being done. They made new design recommendations…the system was a success.
Sure there are methods like Contextual Design, but if for the purpose of generating requirements, they too potentially fail to capitalize on a more optimal solution. Methods that instead leverage the research and then continuously test a variety of possibilities get to successful results quicker.
Indeed, save for flights to the moon and other life-dependent scenarios, failing faster is the most effective means for design…and a fundamental premise of Enterprise 2.0 (which requires a total redefinition of IT as we know it today http://www.fastforwardblog.com/?p=3256, http://www.fastforwardblog.com/?p=234).
I almost don’t know how to respond to Paula’s comments above. As a CIO and a long-term industry veteran, I’ve certainly seen people strongly debate the BEST way to collect requirements, and I’ve seen people bring up problems with how requirements have traditionally been gathered, but this is the first time I’ve ever seen anyone seriously suggest that it’s a “typically useless” activity for ensuring the success of a solution. And like Kevin, I consider myself widely read on the subject, FWIW.
I also, by the way, tend to instantly reject argumentation that provocatively labels the long-standing standard practices of others as “just more nonsense.” Aside from that being simply rude and arrogant, it goes against every software engineering text I’m aware of. Consult the IEEE SWEBOK (www.swebok.org), etc., not to mention authorities such as McConnell, Wiegers, et al.
I’m afraid that this line of thinking is so far outside the mainstream of what the IEEE calls “generally accepted knowledge”, so utterly extreme, that it just can’t be taken seriously and no one should spend a lot of cycles trying to refute it. That’s blunt and harsh, but it’s accurate.
On the other hand Peter the failure rates of large projects are a compelling reason to look at and consider alternative models.
“All of the stated requirements adequately recorded…” That’s your failure point right there, “stated”. Requirements are not stated, they are elicited, analyzed, documented, verified and validated. Requirements work is nor writing down what someone says or asks for, it is determining what an organization needs to be successful within the scope of the effort being considered.
And I am sorry, a source that can no longer be found is a poor foundation for an argument of this type 20 years later. If it has/had any validity, it would have been cited many times since.
Paula, I have to agree with David on this one. The only thing the story proves, based on your description, is that it’s possible to create a set of requirements for a solution that match what the stakeholders say they want but don’t fulfill their real needs. This is not exactly controversial and I’d be surprised if you could find any authority in the field who would disagree with that. There’s certainly a lot of discussion in the BABOK regarding that point.
However, it’s not proof by any means that requirements CAN’T be effectively defined. In fact, unless I misunderstand your anecdote a second team came in and did specify requirements that met the needs of the stakeholders.
So this is what Canadians do on a US Holiday! At least I know David and Kevin are in Canada.
It’s a Canadian holiday too. I’m on here because it’s not like my child was going to let me sleep. I can’t explain David.
Wow, Paula…..I’m speechless. Please mark this down on all of your calendars. Perhaps I should be in another line of work….like serving fries.
Ah, it was Laura’s tweet that brought me here… twitter knows no holidays…. although I spent most of mine parading (www.ferguspipeband) and barbering afterward… now, for Canadian Thanksgiving…
not barbering, barbequeing,…. jeez
Sounds like a requirement for Twitter 2.0. Allow users to suspend tweets during holidays.
Kevin: Indeed there is an angle to this that you’re still going to end up with something that informs the design, but as Craig pointed out, the failure rate continues to escallate.
Sure, I made money doing all sorts of documentation (including requirements) for years. Mindlessly doing the same thing and expecting different results is…well, you know how the story goes.
The point is that I’ve seen plenty of projects that have been deemed a ’success’ because they met the requirements (and bonuses were riding on the attribute), but the solutions were never used, or abandoned, or to this day cause remarkable burdens on the employees — hours of work that are unproductive.
Throw up your hands if you choose, ignore the conversation if you choose…the facts still remain, it’s not working. Doubt it…do two side-by-side efforts (similar to A/B testing on web sites — different designs, different approaches). Ask 37Signals what their approach to gathering requirements looks like (http://37signals.com/svn/archives/001050.php).
Step away from the car…it’s booby-trapped. It may have worked in the past…it’s about ready for a major meltdown and the fact that you’ve been doing it for years…ask the residents of Jerusalem who denied the prophets who insisted that Jerusalem was going to be utterly destroyed by the Babylonians in 500BC how that went for them.
The unfathomable is already happening. Surviving by the skin of your teeth is not evidence that you will continue to do so. But you’re free to continue to believe in the ‘old’ reality. Just be sure to tag this piece. One of us will be able to point back to it and say, “I told you so.”
Paula, I can’t speak for everyone, but I think we are all on the same page. In the end the solution needs to add value. Let’s look at some of Laura’s staements.
“The more I know about how my documentation will be used, the better I will be able to provide the right documentation. ”
To me she is saying document what will add value to the project, not document for document sake.
“I discuss some options with the project leadership and document consumers. I seek out their input on what would help them take the next step. ”
This tells me Laura is working with the key players to help determine how she can make the project a success. Project success is delivering the right solution.
I think you are barking up the wrong tree. Any chance Scott Ambler is now writing under the name of Paula Thornton?!!
Hi all.
I want to thank you all for your passion, support, and attention to this issues at hand. I’ve been considering how to keep this thread from running any further amok. Given that the dialog we are trying to have is a bit beyond what can legitimately be expected to happen via comments on a single blog post, I’m closing further comments on this post.
Thank you for reading and participating!
Best,
Laura Brandau
Comments on this entry are closed.