The DREAM15 Conference – my experience

DREAM15 Event

Location: Hotel Vianen, Utrecht, Netherlands

In my earlier post “22 reasons why I’m Attending the DREAM15 event I described a conference that DREAM (Dutch Requirements Engineering And Management) were holding.

In it I had mentioned that one session didn’t have a speaker yet. I was ecstatic when the organisers asked me to fill that spot. While you can read my slidedeck from that session here, today I’d like to describe the conference itself.


Arrival

Buzzing” is the word I would use to describe the atmosphere at the conference when I arrived. I was taken aback  at the number of people that were attending. The place was packed. And this became even more evident during the opening keynote.


Opening Keynote

The opening keynote speaker was Paul Turner. As I’ve mentioned (in the above-mentioned post), Paul Turner is one of the co-authors of the excellent book “Business Analysis Techniques (99 Essentials Tools for Success)“. Paul was entertaining while being informative, and while Paul presented in English, and the audience was Dutch, everyone enjoyed his presentation. In fact, what he had spoken about was repeated at several times during the day by other speakers. (However, Arjen Uittenbogaard, one of the speakers, commented in his (dutch) blog that Paul had given a bit of a mixed message at one stage.)


Sessions

This was where it was difficult. And the organisers, in the introduction in the morning, acknowledged that it would be . There were just so many great sessions running in parallel. It really meant that you had to make a choice.

I had intended to write a little bit about them all. I even tried this, in the morning, by watching a little bit of each presentation, running from one conference room to another, Unfortunately, this was not very effective.

Brainwriting

In the afternoon, there was one session that I wanted to attend: “Brainwriting“.

Like brainstorming, this technique also allows for the generation of ideas. However, unlike brainstorming that relies on the quick, and “public” shouting out of ideas, brainwriting involves lists. Blank ones. The main problem, or goal, is written at the top of the lists. Participants are divided into groups of 6, and then each person is given a list. They write their idea down on the list and, after a given time, each participant hands their list to the person to the right of them. A new idea is written down. And so on. At the end, there are a large number of ideas, and these can be discussed.

As mentioned, the aim of this technique is similar to brainstorming but lets everyone come up with an idea, rather than just the loudest people in the room.

This was a practical session and very effective. As well as being a lot of fun. I recommenced searching for more on this.

My Session

It was an honour (and a surprise) when the organiser’s asked me to present.
(You can read my presentation here).

There were more people in the audience than I had expected, and my presentation was well received. (Even considering that I presented in English – just goes to show how well the Dutch can speak a language that isn’t their own.)


Closing Keynote

The closing keynote, by Theo Severein, took the opposite angle from the opening keynote and looked at organizational improvement from a holistic viewpoint. This was also a crowd-pleaser.


Socialising

This is one of the big draw-cards for me. A chance to mix and mingle with other like-minded people. It also was a chance to meet, in person, people that I have been interacting with online.

During one of the breaks I was doing the rounds of the vendor stands and had a chance to meet Jan Willem Knop, one of the committee members of the IIBA NL chapter. it was really great to finally meet him in person, and learn more about the IINA in the Netherlands.

Carrying on around, I also got to meet Stefan Sturm, the Managing Director of IREB (International Requirements Engineering Board). Through some of my blog posts and posts on LinkedIn, I been “conversing” with Stefan for awhile. Also a really great chance to meet him in person.

Just before the end of the break, I was able to introduce myself to Paul Turner (the keynote speaker). This was an honour, and I had a  very, very interesting chat with him.

In fact, it was a great chance to learn more from Jan Willem, Stefan, and Paul, how the IIBA, IREB and BCS will be playing together in the new alliance/partnership that the IIBA had announced.


Conclusion

All-in-all, a great day. Great sessions combined with an excellent chance to meet, and talk with, others in the industry.

Related Links

  • DREAM site: http://www.dreamevent.nl/
  • My presentation: here
  • Zingeving voor RE’er, by Arjen Uite
  • Tweets from the conference: here

 

Do you want to learn more?
(Important Disclosure)


Udemy Courses

Requirements Analysis Destroys Ambiguity
Exposing Functional and Non-Functional Requirements
Writing Better Requirements in Plain English

 

 

 

 

Related Post

The Value of BA Standards

In 2015 I had the honour to present at the DREAM15 event. This is run by DREAM (Dutch Requirements Engineering And Management).

In an earlier post, I wrote about the 22 reasons that I was attending the conference.

However, in that post, I didn’t mention the 23rd reason – that I had been invited to present.


The Mistakes Pieter Made, or the Value of BA Standards

Here is the slide deck from that presentation.

[slideshare id=53786963&doc=themistakespietermade-151011062302-lva1-app6892]

 


Do you want to learn more … ?
(Important Disclosure)

Related Post

22 reasons why I’m Attending the DREAM15 event

DREAM15Vianen

EnglishNederlands

DREAM15 event

I’ve registered for the DREAM15 event being held in Vianen, on the 8th of October, 2015, in the Netherlands. And I am looking forward to it!

What’s DREAM?

DREAM is an acronym for Dutch Requirements Engineering And Management.

It’s an initiative that was set up, in the Netherlands, in 2008. Originally spearheaded by Atos, but is now supported and run by representatives from different organisations, with the goal of sharing knowledge and best practices surrounding Requirements Engineering and Management.

So … what’s DREAM15 then?

Dream15 is the sixth conference that Dream has organised. This year there will be three main topics:

  • Business Analysis – Business analysis has to do with change in organisations from identifying the changes that are needed and creating suitable solutions through to the implementation of the solution and subsequent analysis of its effectiveness.
  • Best practices – following proven/accepted standards helps reduce errors, and keeps unexpected problems to a minimum.
  • Methods, techniques and tools – What methods can Business Analysts use, what techniques are handy for the BA, and what tools are available.

Ok … what are these 22 reasons why you are attending?

Where to start?

1. Great keynote speeches

Opening Keynote

The conference is kicking off with a keynote speech by Paul Turner. Paul Turner!!! He’s one of the authors of “Business Analysis Techniques (99 Essentials Tools for Success)“. (This book is my go-to book for BA techniques. It should be in the bookcase of every Business Analyst).

Paul is also the Director of AssistKD. (Check out their site, there’s tons of great resources there.)

Paul will be talking about systems thinking and the soft systems approach, concentrating on how they can be used to add value to the Business Analyst.

Closing keynote

At the end of the conference, Theo Severien is going to give a presentation on organizational improvement from an holistic point of view. that is – when changes are implemented, the order of attention is people – > business – > information – > systems.

Theo will be going further into how this is all possible using a mixture of philosophy, theory and practical examples. It sounds fascinating. I’m definitely hanging around for this one.

2. Great sessions

There are 16 sessions that are spread across 4 streams.
(One of the sessions is still to be filled).

This is frustrating, because  I want to see all the sessions, but because they are running in parallel, I’ll have to make a choice

There’ll be (in no particular order):

a PhD student, from Utrecht University, presenting on quality levels in user stories, and a web application that the University has created to check this automatically
a presentation on digital litigation and the impact that will have on UX and also on requirements.
a chance to learn about, and practice, brainwriting
an in-depth look at Specifications by Example and how they were used, at bol.com, to bridge the communication gap between stakeholders and developers.
one of the Netherlands’ largest banks (ABN AMRO) presenting how it implemented a central requirements management tool to accommodate multiple projects, multiple BAs, multiple regulations, and many, many requirements.
an “exploration” of the correct detail level for requirements in an Agile environment
a look at how Business Analysis techniques such as Impact Analysis can be used to improve the bureaucratic Dutch government system of registrations (“stelsel van basisregistraties“)
two interesting presentations that cover complexity, and how the Cynefin framework can be used.
a discussion about the “uncovering” of requirements hidden in business processes.
a look at how Behavior Driven Development (BDD) was used inside an Agile environment.
a process simulation and game using … socks
the chance to see how the national railway company in the Netherlands (Nederlandse Spoorwegen) was able to guarantee quality in its requirements enineering.
presentations by Synergio and also by Atos.

3. Great sponsors

I’ll get a chance to visit the stands of some of the top companies, in the Netherlands, in this field, and see what they can offer…

This includes: Atos, Devoteam, Entrador, Le Blanc Advies, Nederlandse Spoorwegen, Synergio, iSQI, IREB, Jama, Microfocus, Mithun, PNA, The Future Group

4. Learning

I always love the opportunity to get together with like-minded people. It can be very inspiring as everyone speaks the same language.

There’s always a great chance to learn something. Whether at the sessions mentioned above, or by listening to the keynote speeches, or challenging the vendors, or talking with other attendees

5. Making New Friends and Networking

This event will be an excellent chance to meet new people. my goal is always to meet as many people as I can in the time.

6. Conversations

As mentioned in the previous “reason”, we’re all in the same game. We all talk the same talk. I look forward to asking others what they do, and why. What techniques they prefer. Whether they think Agile is “the answer”, or whether Waterfall has its place.

Having a conversation is one of the most dynamic, and enriching things that we can do. And often I have discovered that, just by having a conversation, valuable things have come from it.

Where’s it being held?

The Dream15 event will be held at Hotel Vianen

Where can you learn more?

  • Check out the DREAM website
  • Download the DREAM flyer

So – those are the 22 reasons I’m going to DREAM. (I know – there are only 6 listed above, but if you count the keynotes and the sessions, there are 22 reasons).

I’ll be blogging while I’m there, so if you someone frantically scribbling notes, and dashing back and forth between sessions, then that’s probably me. Feel free to say Hello.

 

Do you want to learn more?
(Important Disclosure)


Udemy Courses

Requirements Analysis Destroys Ambiguity
Exposing Functional and Non-Functional Requirements
Writing Better Requirements in Plain English

 

Related Post

What value does the IIBA Alliance offer?

 

IIBA (International Institute of Business Analysis) has announced a strategic alliance with four leading, global organizations. 

The four “leading, global, organisations” are:

  • BCS The Chartered Institute for IT,
  • BRM Institute,
  • IREB, and
  • Sparx Systems Pty Ltd.

In my opinion, this IIBA Alliance is a good thing.

Each of these organisations offer real value – often in ways that the IIBA can’t.

 

Map Makers

Let’s face it, IIBA does not pretend to be an expert in any one specific field.

The IIBA (according to themselves) assists business analysts by defining standards for business analysis, identify the skills necessary to be effective in the business analyst role and recognise BA competency through their CCBA and CBAP certification.  

In fact, in an earlier post, (CBAP Certification as a Destination), I mentioned that “the BABOK was merely providing an extremely good high-level map of the BA world. One with signposts to areas that needed further exploring.”

 

Members of the IIBA Alliance

So what value do the parties of this alliance have to offer? Let’s have a look…

BCS

BCS, The Chartered Institute for IT, promotes good working practices, codes of conduct, skills frameworks and common standards. (In that respect, they are similar to the IIBA).

They provide rich, detailed, guidance, and certifications, for specific areas relating to Business Analysis. I have always been impressed with their in-depth material. In fact, one of the most valuable books that I have in my BA bookcase, is “Business Analysis Techniques”, it’s my go-to book when I want to understand specific BA techniques

I see the BCS as definitely complementing what the IIBA offers. (Check out their website, the qualifications, and certifications that they offer, and their list of excellent books).

Let’s face it, IIBA does not pretend to be an expert in any one specific field.

BRM Institute

The Business Relationship Management Institute advances the art and discipline of BRMThey offer training and varying degrees of certification in BRM. They also have their own BOK, the BRM Body of Knowledge. 

Having the BRMI in a partnership with the IIBA is definitely a winner. It will definitely strengthen the discipline of Business Analysis.

You can read more about the BRM Institute on their website.

IREB

The International Requirements Engineering Board provides training and certification in the field of Requirements Engineering (naturally). Their certification is the Certified Professional for Requirements Engineering (CPRE), and is made up of three levels – Foundation, Advanced, Expert. (The Expert level is in the planning stages – so really it’s only two levels).  The IREB publish an excellent (free) quarterly magazine – Requirements Engineering. 

The IREB focuses in depth on software specific requirement elicitation, requirements documentation, requirements analysis, requirements modeling and requirements management. This will definitely be of value to a complete BA offering.

IREB’s website: https://www.ireb.org/en. Click here also to see an interesting comparison of the IIBA and IREB offering (from 2014).

Sparx Systems

Sparx Systems specialise in visual modelling tools. Their product Enterprise Architect is an exceptional tool for full life cycle modeling. It has a user base of over 350,000, and is used across the globe. Added to that Sparx offer a wealth of information including white papers, tutorials, e-books, etc.

Having Sparx Systems as a member of this alliance makes sense. Sparx Systems have very good credentials, and can offer a lot. 

 

The Whole is Greater than the Sum the Parts

Each member of the Alliance brings something valuable to the BA discipline. The IIBA is very broad in what it offers, but not necessarily deep. The other partners all contribute something that bolsters out that depth. It is a very sensible alliance and one that I am excited about.

 

Another possibility…

As you might be aware, dear reader, recently there has been a new threat  to the IIBA’s seat of power. The Project Management Institute (PMI) has developed it’s own Business Analysis certification. A lot of analysis has been performed on the validity of this threat.

Watermark Learning made some very interesting observations in a blog post.
The PMI’s perspective of a BA is is that the business analysts support the efforts of the program and project manager.
The IIBA perspective is that business analysts support the organization.

But,in most cases, who is the Business Analyst reporting to? The Project Manager.

So … it is also possible that this alliance came about as a way for the IIBA to fend off this new threat, 

I’m curious what you think …

 

Other Links

  • Announcement by IIBA
  • Announcement by BRMI
  • Announcement by BCS

Recommended Resources

(Important Disclosure)

Related Post

Writing Functional Requirements for the Paper-clip

black1

David Ordal mused, back in 2008, about what would be necessary to write the functional requirements for the humble paper-clip.

He feels that it should be an easy task, and promotes the idea of “keeping it simple”. The less detail there was the more creative the developers could be.

While I find the idea of writing functional requirements for a paper-clip amusingly fascinating, it’s interesting to take a look at the “short-form’ requirements for this “paper binding device”. Is it really enough? Or is what David describes an “agile” way of looking at it?

Go read David’s article now, and then come back and tell me what you think. The comments at the bottom of his post are also rewarding to read.

Related Post

Using a Smartpen in Business Analysis

Using a Smartpen in Business Analysis

For those that aren’t in the know, a smartpen allows you to capture the actual conversation taking place while you are writing notes.

By using specially marked paper, the pen can synchronise the audio being recorded with what you are writing and, at a later stage, you can press the pen anywhere on the page (on which you have written your notes), and the conversation that was taking place at that particular time is played back to you.

I have used a smartpen in a lot of elicitation situations and, in this post, I would like to describe some of the “lessons learned“.

Download a PDF of this post


 


Which smartpen have I got?

I’ve got a Livescribe smartpen.

There are several models of the Livescribe pen available. The latest version is the Livescribe 3 Smartpen and it offers some pretty cool functionality.

When I wasoriginally  looking at the pens, 3.0 hadn’t been released yet.  And I also reasoned that I did not need real-time syncing to the cloud.

As such I chose the Echo smartpen. You can see what this pen is capable of here and here.

 


How I used it?

I’d use the smartpen in business analysis in any elicitation situation where I was taking notes.

I would use the Echo to keep a record of the actual conversation taking place, and at the same time, I would take be writing notes.

After the session I would playback the conversation at various points, to confirm that my notes were correct, or to expand on what I had written (you know that written notes don’t always capture everything that was discussed).

Using the Livescribe Desktop app, I was able to convert my written notes into a dynamic PDF that could be archived, or distributed to others in the team. This PDF had the audio embedded and the reader could click on any word to playback the discussion taking place at that time.

 


When I was not the one taking notes

Often when you are running an elicitation workshop, you are up in front of everyone, leading discussions, asking questions, prompting and encouraging responses. You can’t do this and write everything done.

In this case, there is usually someone else who has been assigned this task (the scribe).

When I was in this situation, I was still able to use the Livescribe. Whenever there was a change in the subject being discussed, or a particular point that could be summarised in a word, I would write that on the special dotted paper.

After the session, I could still playback what was said at that point.

 


The Advantages of using a Smartpen

Using the Livescribe pen has a lot going for it:

  • You are able to capture the whole discussion and tie it in with your notes.
  • The audio is synchronised to the notes you have written, so you can playback the conversation that was taking place at specific points.
  • The notes with audio can be shared with other members of the team, or with the stakeholders (f desired), as part of your Work Product.
  • You are confident that you can go back over the audio to pick up things that were said, but not written down.

 


Lessons Learned

Using the smartpen in business analysis has been very handy, but it also has its downsides.

What follows are some of the “lessons learned”.

Ask Permission

Before actually using the pen during any elicitation event where other people are involved (workshops, interviews, active observation, etc), ask if it is OK to record the conversation. Usually, people are pretty good about this and don’t mind.

However, it is important to reassure participants that you are using the pen merely as a tool to support the notes you are taking. And as a professional BA, you need to remember that, also.

Don’t let the pen be a replacement for Active note-taking

Use the pen to capture the conversation, but don’t be lazy. You still need to actively listen and write down the important points from the conversation.

You still need to Confirm

Just because you have an audio record of the conversations that you have, does not mean that you don’t have to validate, that the stated requirements match the stakeholder’s understanding of the problem and the stakeholder’s needs.

What is written, and what was said, still might not be what was actually meant.

Make your notes meaningful

As I mention above, in a workshop situation you might just write a word of two and let the pen capture the conversation.

I’ve had situations where, after a series of seven one-hour workshops I’ve gone back over my notes, and haven’t been able to work out which part of the workshop the squiggle on the page tied in with, or what that strange sentence that I wrote (which meant something at the time – three days earlier) actually referred to.

When writing “headings” to describe certain parts of a conversation/discussion, write something meaningful, so that, after five days, it will still be clear. The discussions in workshops, or interviews, don’t always take place in nicely define “sub-sections”.

Never just record the session

This is a classic newbie mistake and relates to something I wrote aboveNever, ever, just record the elicitation session with the intention of “writing up the notes later on“.

You might have had a three-day workshop. Remember – when you playback the audio, it will take three days to listen to it! (And this includes all those side-conversations, jokes, and irrelevant comments that get made.)

Secure the output

This is related to “Ask Permission” above.

Regardless of whether you have been given the OK, by the session participants, to use the Livescribe, be aware that a lot of things are said during the workshop/interview/active observation session that might not be relevant,or are “off-record”.

It may not be your intent, but you don’t want a situation where something someone says is later used against that person.

Have a way of charging the pen

The pen can be used for several hours, but it won’t last forever.

With the Echo, I could plug a USB cable into it, and plug that into my PC. This allowed the pen to be constantly charged while I wrote notes.

Ensure you have enough paper

The Livescribe uses paper with microdots on them. This allows the smartpen to be able to map what is being written, and the location on the page.

Livescribe sells this paper in the form of notebooks.Ensure that you have an extra notebook with you. You might never use it, but, then again, you might. (You can print out the Micro Dot paper yourself, but read the next “Lesson Learned” for more on this.)

 

Keep track of the pages

Each page in the notebook has a unique, sequential, ID. This way, the Livescribe can keep all the pages in the correct order.

Don’t write your notes on random pages. It makes it difficult when it comes to working with the notes, and audio when you are back at your computer.

Printed Pages

As mentioned above, you can print out the Micro Dot paper yourself. If you do this, you will have several loose sheets. These are handy if you want to put the sheets in a ring binder, etc., but be aware that, as with the notebooks, each page is in sequential order. Keep them in the correct order (the page number is printed on each). This saves a lot of pain when exporting to a PDF, etc.

 


The Lessons Learned Infographic

Download a large (800px X 2000px) version,

or …

Share this Image On Your Site

img src=’https://markjowen.com/wp-content/uploads/2016/05/Using-a-Smartpen-in-Business-Analysis.png’ alt=’Using a smartpen in Business Aanalysis – 10 Lessons Learned’ width=’540px’ border=’0′ />
















 


Conclusion – Would I recommend using the pen?

The pen is an incredibly handy tool (with the later version offering, even more, functionality, as well as looking like a real pen).

However, for the purposes of Business Analysis, I would not, personally, recommend using it.

Why?

As I alluded to in some of the Lessons Learned, being able to record the conversation taking place is valuable. But it also makes you relax.

It’s easy to think “Oh I won’t write that down – I’ll go back over the audio later.”

WRONG! The idea of the elicitation session is to actively capture the main points. In real-time.

That’s part of being a good BA. Active Listening and Active Note Taking. You are in the elicitation session to really understand the message that the stakeholders are communicating. And you need to make sure that you have captured it properly.

Going back over a recording of a session, in my opinion, is of little value. The real value should be in your notes. If they need expanding upon, or clarifying, that is something that needs to be done directly, with the appropriate stakeholder.

I’m not saying that a smartpen is worthless. But if you think about it, BA’s have been taking notes as part of the elicitation process for years. How many have recorded the session?

However…

My conclusion above, however, is how I feel about it.

For you, fellow BA, it might be a different situation.

In fact, someone pointed out to me that their handwriting was terrible, and they often could not read their own notes. Having the pen would mean that they could, indeed, dive into what was being said at the time the notes were made.

I can’t argue with this reasoning…

 

 


Other Reviews

For other reviews of the Livescribe pens, click here.


Your opinion

Have you used a smartpen in business analysis? What are thoughts on it?

Do you think that I am wrong in not recommending it for BA work? Feel free to let me know in the comments

 

.


What to try for yourself?
(Important Disclosure)

Related Post

Understanding the Frustration of a Project Manager

Oops

So there he was. Charlie had been assigned as lead BA on a project with an external client. “Cool” he thought, but still felt a bit nervous. There were others in his department that had been in the game longer, and he was still reeling from having the proverbial  “slap in the face” in an earlier project that had turned slightly pear-shaped..

As such, Charlie decided to ask some of his colleagues for help. They were most forthcoming, and decided to hook in other expertise. “All fine” he thought, “the more experience available in this, the better.” 

Continue reading

Related Post

10 Steps to Successful Requirements Gathering

Jordan Hirsh published a great article on the Phase2 website in November last year. Dealing, on a daily basis, with the importance of requirements, I found the article really valuable – to the point of asking if I was allowed to reproduce it on my blog. Fortunately, Jordan agreed …

 


What The Heck Are We Building? 10 Steps To Successful Requirements Gathering

There’s a common refrain that gets uttered at the end of unsuccessful projects: “The requirements weren’t clear.”

Fingers start pointing, blame gets thrown around, and no one ends up happy.

Thankfully, there’s a simple way to alleviate that problem, and it’s as obvious as it is challenging: requirements gathering. Depending on your project methodology, you may do this step at the beginning during a Discovery phase, you may do it during the project within each sprint or build cycle, or you may skip it altogether and hope for the best. That last option is a simple way to sabotage your project and guarantee a lot of late nights and awkward status meetings.

Successful Requirements Gathering - reality

This doesn’t have to be you!

Successful requirements gathering is both an art and a science, but there are some general steps you can take to keep this all-important step of your project on the right path. Here are some guidelines that we try to follow at Phase2:

Establish Goals & Objectives Early
This step can feel redundant:
of course we know why we’re doing this project…don’t we? Even if you think you know, write it down, and get your client to sign off on it. Without clearly stated goals and objectives, you are lacking a framework to guide future decision-making. How do you know if a newly introduced requirement actually fits in your project? Simple: does it help accomplish a goal, or does it satisfy an objective? If so, it’s probably a good fit. If not, it’s a good candidate for a future release.

 

Write It Down
When you’re in the midst of stakeholder interviews and document review, you can often feel like you have a great grasp on things. But then a week goes by, and some details start to get a little fuzzy, and you
realize you don’t quite have a full grasp of X, Y, or Z. It sounds obvious, but making sure that you are taking detailed notes during your stakeholder interviews is a powerful step in successful requirements gathering. And it’s not enough to just write everything down, as you’ll see in #3…

 

Be Transparent
Sure, you understand the requirements. And your client understands the requirements. But does your client understand your understanding of the requirements? After every meeting, go through your notes and clean them up – then share them with the project team, including the client. This transparency not only helps make sure everyone’s on the same page, it fosters a sense of project buy-in all the way through your project, beginning with the requirements. And it circumvents the issue of someone saying “hey, you agreed to X but it’s not here!” 6 weeks into the project. If it’s not in the notes, it didn’t happen.

 

Talk To The Right People
A project can often have “hidden” stakeholders. Ask probing questions in your kickoff and initial meetings with your client to try and get to who the real users are – often those people are not going to be the main decision-makers, but their buy-in is essential to a successful project. Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project.

 

Get Detailed
Don’t assume that you understand everything, even if it seems obvious. A seemingly simple requirement such as “we want a blog” can mask all sorts of underlying assumptions, requirements, etc. What are the fields for a blog post? How are authors managed? What about tagging? Categories? How are the posts displayed? Are they aggregated into an archive? Is there an RSS feed? Who are the authors and what is their level of technical proficiency? Etc. etc. etc. The devil truly is in the details, but you can catch him by the tail if you ask a lot of questions and don’t rely on assumptions.

 

Confirm, Confirm, Confirm
This ties into “
be transparent” but is not entirely the same thing. Just sharing your notes with a client is great, but far more valuable is actually having a quick review with them and getting their official sign-off. This is true for meeting notes, user stories, diagrams, wireframes, really any kind of requirements artifact that you are creating. Radio silence is not an indicator of success – get actual confirmation from your client that you are representing the requirements correctly in whatever format you’re using, then move on.

 

Be An Active Listener
Making someone feel heard is one of the greatest things you can do for them. But it goes beyond just listening to what they say – you also need to listen to what they don’t say, and how they say things, and read their body language, etc. This is called “active listening” and it’s a key component both of successful requirements gathering and improvised comedy, among other things. Don’t assume that you’re always getting the whole story – listen for little cues that reveal pain points, desires, unstated goals, and assumptions.

 

Focus On Requirements, Not Tools
Be careful when you are gathering requirements that you are really focusing on and listening to what your client needs, not what your tool-of-choice happens to do best. Even if you know you are going to be using a certain product, you need to adapt the product to the user, not the other way around. Listen and gather first, then determine where the gaps are between your client’s needs and any existing product you may have in mind. Remember: requirements are about the WHAT, not the HOW.

 

Prioritize
In an agile methodology, we work towards a Minimum Viable Product (MVP), which encapsulates the least amount of functionality that would count as a successful product at launch. Even when following a non-agile methodology, prioritizing is your friend when you are gathering requirements. It’s easy for requirements gathering sessions to turn into wishlist gathering sessions, where stakeholders tell Santa (i.e. you) everything they want. The point isn’t to ignore that information (in fact it often reveals goals and assumptions if you’re using Active Listening) but rather to clearly and transparently prioritize what you’re hearing and delineating what is in scope for your initial launch and what is not. You definitely want to track wish-list items, “nice-to-haves,” etc. but prioritizing helps you focus your efforts and helps you make decisions if time gets short and something has to go.

 

Remember That You Didn’t Get Everything
Even the best requirements gatherer is going to miss things. Why? Because you and your clients are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your client will think of things that they forgot to mention. Things will change. Priorities will shift. The good news is that if you plan ahead for this, you can build in time during your project lifecycle for ongoing requirements management. This time is essential because requirements (being human-driven and human-created) are simply not static. Giving yourself time to actively manage requirements throughout the entire project can help you stop scope creep before it starts, and make sure that your team is always focusing on the right set of priorities that match actual requirements.

There’s obviously a lot more that can be said about the art and science of requirements gathering, but hopefully, this list has given you some helpful tools to manage this process successfully. If you are the client on the other side of this requirements process, check out Nate Parsons‘ blog post “How to own a boat or… How to maximize the ROI on your expensive new website” to learn about the questions that your team should ask while gathering requirements for your new site. Good luck out there!

 


Thanks Jordan

You can read the original post on the Phase2 website:
http://www.phase2technology.com/blog/what-the-heck-are-we-building-10-steps-to-successful-requirements-gathering/

 


Want to learn more?
(Important Disclosure)

Related Post

15 Tips for Writing Better Requirements

Abidemi Stephanie Famuyide wrote a post a few days ago title
15 Tips for Writing Better Requirements“.

I don’t agree with all of the tips. However there is a lot of good stuff in there. And I particularly like the last one that describes ways to word a requirement.

  1. Define one requirement at a time. This implies that the requirement should be atomic. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because it can prevent developers and testers from missing requirements.
  2. Avoid using let-out clauses like but, except, if necessary.
  3. Each requirement must form a complete sentence with no buzzwords or acronyms
  4. Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).
  5. Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design; Normally, if you catch yourself mentioning field names and software objects in the requirements specification document, you’re most likely in the wrong zone. 
  6. Avoid ambiguity caused by using acronyms like etc, approx. and the like
  7. Avoid the use of indefinable terms like user-friendly, versatile, robust, approximately, minimal impact. Such terms often mean different things to different people
  8. Avoid rambling, using unnecessarily long sentences or making references to unreachable documents.
  9. Do not speculate; avoid drawing up wish lists of features that are impossible to achieve. Saying you want a system to handle all unexpected failures is wishful thinking since no system will ever be a 100%
  10. Avoid duplication and contradictory statements
  11. Do not express suggestions or possibilities. You can identify these wherever you see statements like might, may, could, ought, etc
  12. Avoid creating a jigsaw puzzle where requirements are distributed across documents, causing you cross-reference documents. It can make your requirements specification document extremely difficult to read
  13. Do not forward reference or refer to a requirement that is yet to be defined. Again, your objective is to make the document as much of an easy read as you can
  14. Use active or positive statements such as “The system shall…” instead of stating “the system shall not…”
  15. Shall“ should be used where requirements are being stated, “will” should be used to represent statements of facts;  while “should” represents a goal that needs to be achieved

Go and visit her site “Business Analyst Learnings” where she invites you to “rub minds”.
(There is oodles of great information and resources related to Business Analysis.)

Related Post

Why giving the users what they want is not enough

Why giving the users what they want is not enough

Did you know that giving the users what they want is not the right thing.

Why? Because, often, the users don’t know really what they want.

often, the users don’t know really what they want

Example

Consider the following example:

A Restaurant

A large restaurant chain has restaurants across the globe.

Each restaurant needs to maintain documentation such as construction plans for each restaurant, recipes, procedures, and methodologies, etc.

The “critical” documents are kept in a legacy ECM system and several SharePoint repositories store the non-critical documents.

These systems are located centrally and are all globally accessible.

The business users work primarily with the legacy ECM system, but often also need to work with the documents in SharePoint.

When a document was needed, a search was either done in SharePoint, or in the legacy system, using its rather complicated search feature.

Performing searches in two different places wasn’t easy, or efficient. And so, the users cried out “Give us a one central place where we can perform a search”

When asked for more details the business users replied “Make it like Google”.

The restaurant’s IT-people (who might have been a little too enthusiastic) swung into action, without any more questions.

They found a tool that would allow SharePoint to “talk” with the legacy ECM system and crawl all the documents, indexing everything it could.

After working many weeks getting things set up, and configured, the IT-people sat and watched as SharePoint crawled through the content.

Once finished, initial tests were done to ensure that a search action would actually return content. It was working perfectly.

And it was “just like Google”.

A demonstration of the Search system was given to the users, who were ecstatic. They were able to easily enter search terms, and get results from SharePoint as well as the legacy system’s repositories.

It was fantastic. It was easy to use, and there was no extensive training required. There was much cheering and showering the IT-people with small gifts.

After further testing, the search facility was officially moved into production.

For the first couple of months, the users were keen to use the “enterprise search facility”.

Complaints

But then, gradually, complaints started being heard. “The search results contained too many hits”, “Why wasn’t it more like the search feature in the legacy system?”, or “the search results were just showing the title of the document.”

Users went back to using the legacy system’s search feature for the “important” documents, and the SharePoint search was just used for the documents in the document libraries.

The “central” search facility was a failure.

What went wrong?

What had gone wrong here?

The business users wanted a single search facility, and they wanted it “like Google”. And that’s what the IT department had delivered.

There was a single box where users could type in words that they wanted to find. And the search would return documents from all the different document repositories.

In this case, however, the users didn’t really know what they wanted.

the users didn’t really know what they wanted.

Yes, they wanted “easy”, but they also wanted something that allowed granular searches to be done (just like their “old” search tool).

They also wanted to know where the search results came from – the legacy ECM system, or the SharePoint repositories. And they wanted the “important” documents to appear at the top of the search results.

And they wanted the “important” documents to appear at the top of the search results.

What should have been done

The IT team should have asked more, and then they should have listened more.

And then they should have repeated this process. ntil it was understood what the Business really needed.

The team had followed a Waterfall approach, where requirements were asked up front, and then were not allowed to change.

Agile programming techniques could have been used where a “finished’ product is shown to the users several times during the project. The users could give feedback which would lead to a better understanding of what they want, as well as the ability to refine the solution.

Happy Ending

Fortunately, the IT team had the opportunity to improve the search system. They did add a small button to the search result screen, where users could provide immediate feedback. Working with this, as well as sending out regular “satisfaction” questionnaires, the IT team was able to identify areas of improvement.

These include not only changes that were required on the user interface, and results screen, but it also allowed the IT team to see where further refinements were needed in the indexing process.

Every four months, the improvements were presented to the business, and then implemented.

Now, the business users don’t use anything else.

Want to learn more?

Below are a selection of resources that I personally feel are relevant to this blog post, and will allow you to get more in-depth knowledge. I do earn a commission if you purchase any of these, and for that I am grateful. Thank you. (Important Disclosure)

Related Post