The project timeline is challenging, but you can just about make the deadline…

Then you realise all of your key stakeholders are away at a leadership conference for the next three weeks.

What’s a BA to do?

You know two of them quite well, and they agree to block out 20 minutes one day for a short phone call.  They explain that the vast majority of the stakeholders are keen on the project, and will make time to see you after the conference, but they explain that since this conference has been in the diary for 12 months, it just can’t be moved.  Nor can the stakeholders squeeze any more time for you during the conference, as the schedule is so packed.

As you walk back to your desk, you have that sinking feeling:  “What on earth can I do for the next three weeks?” After all, surely stakeholders are key to requirements elicitation, right?

Well – yes and no.  As BABOK reminds us, there are so many elicitation techniques, and whilst workshops and interviews are used extremely frequently, there are many others that we might choose to employ.  In this article, I will describe three elicitation techniques you can do without access to your stakeholders.  It’s unlikely that any technique will stand on its own, the key to good elicitation is using the right blend, but these three can be particularly useful when stakeholders time is scarce.

#1 – Domain Research / Competitor Analysis

When projects start, particularly when stakeholders are unavailable, it can be useful to ask the question “how do our competitors solve the problem we’re trying to address with this project”.    Depending on the domain, it can be useful to visit their websites,  stores or branches to get a sense of their products and processes.

• What have they done well, and not so well? What type of data seems noteworthy?
• What business rules do they seem to have employed?

The idea here is not to copy or re-use, but to get a sense of the likely requirement areas that might be relevant.

#2 – Document Analysis and Organisational Research

Large organisations often contain hidden information goldmines in the shape of process documents, previous requirements documents,  business architecture diagrams and so on.  It’s well worth asking what existing documents are available about the “as is” picture.

Often documents like this are left languishing on dusty shelves – so they might be out of date – but they can be a useful starting point.  As analysts, they help us to formulate the best questions to ask when our stakeholders become available again.  They might also help us to determine some of the existing process requirements which may need to be considered in any new or updated system.

#3 – Observation

On projects of all types,  it can be extremely powerful to simply go and observe end users or workers, and see how their processes and systems actually work. End-users are normally extremely knowledgeable, yet sadly sometimes they fall into the “high interest, low influence” stakeholder category – they certainly care about the target solution (as they will need to work with it), but the decisions are being made elsewhere (perhaps by the sponsor, subject matter experts, and other domain experts).

When this is the case it’s even more valuable to see how they work, understand their day-to-day pain, and understand how they perceive the problem. This should always be done with fore-warning and permission of their managers, and it’s vital to build rapport and explain why you’re there. As with the other techniques mentioned, observation can help us to gain a greater understanding of the problem which we can refine by using other techniques.

And Then Validate What You Learn With Key Stakeholders

These are just three elicitation techniques you can work through without engagement from your key stakeholders. There are certainly others.  These techniques can be useful when used alongside interviews or workshops.

One final point: the scenario I painted above was one involving temporary stakeholder absence, which is a challenge that we can work around.  If stakeholders are continually unavailable, this might suggest a deeper-rooted problem and may require a different type of intervention by the project team.  This might involve by gaining their buy-in (with the help of the sponsor), or maybe even delaying the project completely (if it isn’t essential to progress it now, and if availability will increase in a few weeks’ time).

In summary: stakeholder involvement is clearly crucial to elicitation, but there are other techniques that we can use too.  The key is to use the right blend at the right time.

Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement

And  if you are looking for even more tips to manage difficult stakeholders, download this free guide. You’ll

• Save time and effort by clarifying the requirements more quickly.
• Build stronger relationships that elevate your reputation and career.
• Improve project outcomes by communicating more effectively.

Will the next track be by an epic rock legend, or will it be a remix of some trashy 90’s pop song?

The mystery is part of the fun!

After hitting the “shuffle” button this morning I was rewarded with the excellent 80’s track, “Atomic” by Blondie.  In a moment of lateral thinking, this 80’s new-wave song prompted me to think about requirements, and specifically about requirements quality.

Let me explain…

Good quality requirements have a number of characteristics.  Many authors have produced guidance around requirements quality, and as an example, the BABOK guide suggests good requirements should be:

• Cohesive
• Complete
• Consistent
• Correct
• Feasible
• Modifiable
• Unambiguous
• Testable

(See “A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) BABOK v2.0”, sec 6.5.4)

As part of cohesiveness, BABOK states:

“A cohesive set of requirements relates to only one thing,” 

I would extend this definition and say that each individual requirement  within the set should relate to one and only one thing. Or, put another way, each requirement should be atomic.  This is of relevance to detailed textural requirement artefacts – for example, declarative requirement statements (“The system shall…” or “A user can…”) or textural business rules.  It wouldn’t normally apply to a model or a high level scoping statement.

The Importance of Atomic Requirements

If you are using declarative requirement statements or similar artefacts, there are several advantages to ensuring each requirement is expressed atomically.  One of the most significant advantages is it helps to avoid prioritisation anomalies.  When several requirements masquerade as one, it makes prioritisation difficult.  For example, imagine a requirement was stated as:

“A user must be able to add, edit and delete a new customer record”

This is actually several requirements bundled into one.  Perhaps the most important priority is to add (create) the record.  Edit might be important, but not critical for day 1 (perhaps it could wait for a second release, depending on the nature of the system).  It might be possible to defer the “delete” function even further. This level of prioritisation can only happen if the requirements are split out.  Otherwise, it’s likely the whole requirement will be seen as a “critical” day one requirement, even though elements of it could wait.

Muddled and combined requirements also create issues with traceability.  What if a different person “owns” each part of the combined requirement above? It would be difficult to show this relationship.  Equally, showing relationships and dependencies between requirements becomes more difficult, as it isn’t clear which part of the requirement has the dependency.  Muddling requirements makes requirements analysis and requirements management more difficult and causes problems further down the project lifecycle.

So, when you’re using declarative requirement statements, think “atomic” as well as “cohesive”!

>>Improve Your Requirements Writing Skills

When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

>> Click here for more information about The Blueprint <<

However, we’ve probably all had experiences where the reality seems quite different.  Sometimes groups don’t seem to “gel” very well, and sometimes certain delegates look like they want to contribute but seem to be self-censoring themselves.  Perhaps their boss is in the room, and they are afraid of speaking out.  Or perhaps they lack confidence and are afraid of asking “stupid” questions.

The irony, I believe, is that the so-called “stupid” questions are the most important.  Often they are so fundamental that they’ve been overlooked, until someone is brave enough to raise them.  It’s important to foster an environment in a workshop that creates the permission to ask any relevant question, however provocative or obvious it seems.  This will ensure your workshop is most effective and uncovers the cold, hard facts.

When planning a workshop, it is worth considering whether you need to include workshop levelers in your agenda.  Workshop levelers are tools and technique that remove rank, prevent a single attendee from monopolising the conversation, and allow shy people to contribute without fear of having to speak out in front of their boss.  Here are a few notable tips that I like using:

1. Set the scene:  On the agenda, and at the beginning of the meeting, ensure that you create the permission for people to ask provocative questions.  Explain that all views are valid; we might not action every idea that is mentioned, but even some of the most “quirky” ideas might prove useful after subsequent discussion.

2. Leave rank and job titles at the door:  As part of setting the scene, let attendees know that when they enter the room, they leave their rank at the door.  Contributions from front-line staff are just as valid as those from the CEO (and, in many case, front-line staff are able to provide excellent insight into what real customers want).

3. Mix it up:  If you are running a larger workshop and you split the attendees into syndicate groups, ensure each group has a mixture of backgrounds and seniority.  This will allow cross-pollination of ideas, and will help prevent the delegates from slipping back and focusing on their own rank/job title. You may want to include a suitable icebreaker to help people to get to know each other better, and to break down the barriers of formality.

4. When appropriate, embrace anonymity:  Consider using techniques that allow people to make a contribution anonymously.  Allowing people to post stick ‘post-it’ notes with their ideas to a flip-chart will encourage even the most shy of person to contribute.  The output can then be discussed in total rather than identifying individual ideas.  (This technique needs to be used with care; anonymity can lead to a lack of ownership, but managed carefully it works well).

5. Facilitate fairly:  During group discussions and debates, don’t allow a single attendee to monopolize the airways.  If someone looks like they need to speak, actively invite them.  Say something like, “John, you’ve been a bit quiet – I just wanted to check you’re OK with this. Do you have anything you’d like to add?”

6. Recognise body language and trust your gut:  If someone looks uncomfortable or unhappy, don’t ignore it.  If you aren’t able to get to the bottom of their concerns during the meeting, consider following up with them after the meeting (perhaps over coffee).

There are so many more excellent techniques I could have mentioned, but these are six of my favourite.  I hope you have found them useful!

Elicitation can be a tricky activity.  Often when needing to understand the requirements for a particular project, the temptation is to jump straight into facilitating a requirements workshop or holding stakeholder interviews.  The challenge, of course, is getting enough stakeholder time, and knowing which questions to ask with the limited time available.  Understandably, business stakeholders are often too busy running the business to attend meetings, workshops or interviews.

It’s important to come prepared with as much information as possible, and the technique of document analysis can be extremely useful.   It’s possible to use document analysis to gather information about the business domain and/or the problem being solved without taking up too much stakeholder time.

So what does document analysis mean? Well, in essence, it just means “finding out what relevant documentation the enterprise has, and reading/referring to it”.  This is something that you almost certainly do intuitively, but by consciously planning it you can expand the scope of documents you consider.  Here are some document types to look out for:

Forms: If you are examining a process that involves paper forms, ask to see a copy of the form.  This will tell you a lot about the process! It will help you to understand the data that’s collected, and it might even hint at the business rules that apply (e.g. you might find that the form states, “All applications over $3,000 must use a form XYZ2”.  You’d then know that something different happens in these circumstances).

Business Architecture diagrams:  These will often show who does what, where and which business services are in-source/out-sourced etc.  They can give you a macro-level view of your domain.

Process or procedure diagrams:  Often operational areas keep documented copies of their processes.  But beware: They might not be up-to-date, and people on the ground may well be doing something subtly different (so it’s always worth following up with interviews/observation).

User guides/help screens:  If you’re working with an existing system, user guides and help screens can help you to understand the “as is” screen-flows.  They might even hint at underlying process logic and business rules.

Previous requirements documents: Sometimes, you might strike gold and find that a previous BA has produced a full set of requirements for the system or process that you’re aiming to change.  If so, this will be an excellent reference point, but remember that not all requirements get implemented, so it’s worth checking whether anything was de-scoped.

Customer complaints: Sounds strange doesn’t it?  But customer complaints can often give you great insight into where processes have broken down.  If you’re working to fix or improve a process or system, it’s well worth finding out whether there are any related customer complaints.

Defect logs:  Sometimes, business users will keep logs of “pain points” and perceived  defects on systems that they work on.  Sometimes these will be on a central defect management system, but sometimes they’ll be kept informally on Excel logs or in paper files.  Ask for a copy. It’s very useful to understand which parts of the process or system are causing pain.

Product/service promotional material:  Often the marketing material for a product or service will give you an insight into how it works.  For example, if you are working on a project that involves making change to an Investment product, then the existing prospectus/brochure provide a whole range of useful information about the “as is” product.

Document analysis is a great way to quickly gain enough information to ensure you’re asking the right questions.  It can help you quickly get up to speed, and ensures that you’re using stakeholders’ time effectively.   A quick initial 5 minute phone call to ask, “Do you have any of these documents, and if so could you send them to me?” can really pay dividends.

Have you ever heard stakeholders say things like:

“We don’t have time for up-front enterprise analysis… we just need to get going!”

“Why do I need requirements?  It’s simple – I just want xyz system. That’s my requirement. Now go deliver it, by next Tuesday please.”

“Why do we need to understand the ‘as is’ system – surely we can just worry about the changes?”

“Why do you keep asking me about business goals and objectives?  That’s not for you to worry about.”

If you haven’t ever heard sentiments of this type, I am extremely jealous!  I know from my work with organizations and BA practitioners in the UK, that misunderstanding, and in some cases resistance against the BA role does occur.  Sometimes it feels like they don’t really want a BA at all.

As a community, it’s easy to blame the stakeholders for misunderstanding the BA role.   “Those annoying stakeholders… why don’t they understand the benefits that structured change and analysis can bring to them?”   However, I think it’s time for us as a community to turn the conversation around.

A Challenge: The Cocktail Party Test

One of the challenges we face in articulating the value we add can be illustrated with what I call the “cocktail party test”.   Imagine you’re being introduced to a new friend at a party – someone you’ve not met before.  They don’t work in business change, in fact they’ve never worked in a project environment at all.  Perhaps they’re a chef or a baker.  Imagine you tell them that you’re a business analyst—and you’re met with a blank stare.   Followed by the question: “What does that mean?”

How would you explain your role to them? Take a moment to consider this before reading further.

This is what some people describe as an “elevator pitch”, and many BAs (myself included) find it incredibly difficult to succinctly and meaningfully describe the role and the BA value proposition.  What we do is so broad—we work on projects from conception to realisation—and it’s hard to cut down the essence into a single, snappy sentence. Particularly to someone whose role is outside of business change.

It’s like there’s a brick wall…

Add into the mix that if you ask 50 different BAs to describe the role, you’ll get 50 different descriptions, all of which are probably perfectly correct.  There will undoubtedly be some areas of controversy; what counts as “systems analysis” or “design” varies between organizational contexts. So, if as a community of analysts we can’t agree on a succinctly and useful definition of our role,  no wonder our stakeholders are confused!

You may ask “why does this matter?”  History is littered with expensive project failures… and we know that good quality business analysis (along with our change colleagues – project managers, architects etc.) can avoid this. But, sometimes it feels like there’s a brick wall between us and our stakeholders.   We know that we can help them so much… if only they’d engage us earlier.  If only they’d let us help them before key design decisions were made.   But they don’t yet know the breadth of problems we can solve for them.

The million dollar question:

So my final question:  Does anyone ever really want a BA anyway?  Or a project manager for that matter, or an architect? Controversially, I think the answer is no.  To draw on the commonly quoted cliché… people don’t buy drills because they want a drill.  They buy a drill because they want a hole in the wall.  In the same way, people engage BAs and other change professionals because they want effective business change that delivers business and customer value.  Sounds obvious, right?

However, this provides a useful lens to break down the brick wall of misunderstanding.  When we’re faced with scepticism, we need to break it down – brick by brick – by explaining and demonstrating how we add value in the context of the change that the business needs and wants.  Then, we need to faithfully deliver that change.

We can’t bulldoze down the brick wall, but through reliable and consistent delivery, mixed with superior stakeholder management and marketing, we can nibble it away—a brick at a time… leading to better quality earlier engagement and better quality project and business outcomes.

However – not all workshops achieve their goals.  What are some of the common pitfalls, and how can they be avoided? I have listed 7 key pitfalls below:

1. Insufficient planning and preparation

A workshop needs structure, and a good facilitator will spend time considering which methods, tools and techniques should be used. It’s important to craft this into a carefully considered agenda to make sure that the key points can be covered in the allocated time.

The amount of planning needed is likely to vary depending on the number of attendees, whether it’s a routine or a “One off workshop”.  Think of it this way – if you hold a 3 hour workshop with 10 people present, that’s 30 hours of collective time.  That’s a huge cost! The workshop needs to be a success, so don’t feel guilty spending 3 or 4 hours preparing.

Preparation involves preparing your audience by providing them with an agenda, and where needed making individual phone calls/visits to ensure they have everything they need. It also involves planning to arrive early to set up the room and test any equipment needed.

2. Unclear or non-existent workshop goals

Have you ever been to a meeting or workshop where nothing has been achieved, and the conversation has gone round and round in circles?  This can be down to the fact that stakeholders had a different understanding of the purpose of the workshop.  Perhaps one thought it was to define scope, and another thought it was to reduce scope.  Subtle differences lead to people talking cross-purpose.  All workshops should have an agreed goal/objective up front.

“We are here to focus on… This workshop will be a success if by the end of the meeting we achieve…”  

3. Inviting the wrong people 

Workshops are most effective when they are kept short, succinct and the key decision makers are in the room.  If you can’t get the key people to commit to attending, consider deferring the workshop.  If it looks like the workshop will involve 25 people, consider asking what each individual’s area of expertise is. Are they a decision maker? Do they need to be there? Could the workshop be split into two shorter focussed workshops to keep attendance down to a manageable level?

4. Letting energy get low

A workshop should be interactive and energising.  If you need creativity, think of ways to keep the energy levels high.  Bring cakes.  Take away the seats.  Use colour, music… do whatever you need to keep people engaged and interested!

5. Ignoring conflict

It’s all too easy to gloss over conflict in a desire for stakeholder consensus.  I have a controversial view here – workshops are exactly the right place to encourage conflicting ideas to be discussed!  Let’s face it – conflict is going to occur sometime during the project.  Better to get it on the table when people are together, so a resolution can be found early (or at least the issue is acknowledged).

6. Feeling afraid to jump in

This is something I used to struggle with. I think it’s a product of being British (and our national obsession with “politeness”), but I used to find it difficult to “interject” and move someone on.  Sometimes people seem to make their point over and over again, or perhaps they go drastically off topic.

Let me set the record straight.  As a facilitator, it is perfectly OK to respectfully cut someone short, to “park” an item, agree a future time it’ll be discussed and move on through the agenda.  In fact, it’s quite likely that the rest of your audience will thank you for it!  Make sure you have an “actions log” and “parked ideas log” so that these ideas and concerns aren’t lost – they can be discussed offline if needed.

7. Not documenting the meeting

Chances are, nobody will remember the decisions that were made in a meeting held at 10:30am on a Monday morning 6 months ago.  To ensure there is a clear understanding of what was discussed and agreed, it is worth ensuring that the workshop is recorded, in whatever format works for you and your stakeholders. Your meeting notes should also be made available for review after the workshop.  (You don’t have to take this role on yourself.  You could consider allocating the role of “scribe” to a willing volunteer.)

A good workshop can be productive, fun and effective.  Good planning, preparation and facilitation is a key differentiating factor.  And some cakes or candy to bribe the attendees can be a good move too!

The issue for many people is that ‘networking’ sounds scary. It stirs up images of ill-fated cocktail parties and other awkward forced social situations. The good news is that it doesn’t have to be this way!  Networking can be easy and fun as well as productive.  Here are some tips:

1. Plan and commit to networking opportunities:

If you are interested in expanding your network, the first step is to find some relevant networking opportunities.  A great place to start is your local chapter of the IIBA – they may well hold monthly events where you can meet other professional analysts.  Alternatively, depending on the type of person you are hoping to meet, there may be another professional organisation relevant to your specific domain.  Once you’ve identified a networking opportunity, mark it in your diary and commit to it.  If you are a nervous networker, you might be tempted to back out.  By making a commitment, and making time in your schedule, you are more likely to make sure it happens.

2. Carry the right tools:

To make the most of your networking opportunities, you will want to carry the right tools.  It is good practice to carry a supply of clean, up-to-date, crisp business cards.  Remember that first impressions last, so don’t be tempted to rely on an out-of-date creased business card with your old job title on it!  If your employer doesn’t supply business cards, consider having your own personal contact cards printed.

3. Meet new people:

When going to networking events, it can be tempting to spend time speaking to people you already know.  Remember your aim, and make sure you speak to people you haven’t met before. Don’t be afraid to introduce yourself to people –  I find a smile, handshake and brief introduction such as, “Hi, I’m Adrian, I don’t think we’ve met yet,” can often be an easy way to strike up a conversation.  You might also want to consider how you introduce yourself, and some networkers advocate using an ‘elevator pitch’ (a short polished summary of your role and/or strengths).  Either way, the important part is to be confident and genuine.

4. Exchange cards and build your address book:

When you meet new people, be sure to exchange cards or contact details.  After each networking event, store the business cards you have been given carefully, or even better put the details into your address book.  You might also want to add a few lines describing the person/their role to help remember them in future.  Make sure you do this as soon as possible, else you will end up with a stack of business cards with no idea of who was who, particularly if you meet several people with the same job title, first name or from the same company.

5. Be genuine:

Networking should be a fun professional activity.  Unfortunately, some people use it as an opportunity to immediately sell their services, or to ask for a favour.  My view is the best type of networking happens when neither party has any immediate gain.  That way, a professional relationship can build over time, and perhaps at some point inthe future business might be conducted.  It is also better to think about what you can give to your network, rather than what you can get from it.   If you act genuinely and invest in your network, you’ll find you won’t even need to ask your network for help – they will offer it when they find out you need it.

6. Stay in touch:

Professional relationships strengthen over time, so make sure you stay in touch with your network.  If you see an article that a colleague might like, ping them over an e-mail.    If you see an opportunity that someone in your network might be able to bid for, let them know.  There are many ways to stay in touch, and you might prefer to use a professional networking site like LinkedIn.   Online social networking is a very useful way of supplementing real-world networking, but it certainly doesn’t replace it!

In summary, as BAs we can benefit greatly from networking with our peers in other domains and industries.  This allows sharing of information and best practice, and building a strong network is a great way to protect your career stability.  It is one area of professional development that can definitely be fun.

>>Networking as Part of Your BA Job Search?

Our BA Job Search Process covers the entire lifecycle of finding a new BA job, from getting started to accepting the offer.

Click here to learn about our BA Job Search Process

It is important to ask the right questions early on. This encourages our stakeholders to approach the problem-space in a thoughtful and creative way hopefully working around any presuppositions, prejudices and assumptions. Asking a balance of logical and also deliberately provocative questions can help us to get a better understanding of our stakeholders’ worldviews, and help us to understand what they value as well as ideas or requirements.

Provocative questions are those that encourage a stakeholder to think creatively and laterally.  They help to uncover any perceived constraints, and can help to evaluate whether those perceived constraints are real or imaginary.  They can help to confirm or uncover the business driver behind a project/requirement, and they promote a level of creative thinking which might not be obtained through purely straight forward questioning.

Thesequestions help to challenge our stakeholder’s preconceptions, and ensure that we understand the business driver behind the project/requirement.  By explicitly externalising these ideas and constraints early in a project’s lifecycle, it is also an opportunity to spot any conflicts or areas of disconnect between stakeholder groups.  This also provides the opportunity to debate and gain consensus on the objective of the project, before moving into discussions over potential solution options.

Here are some examples of some provocative questions you might find useful:

1.  “If there were no constraints (budget/time), what would your ideal solution/outcome look like?”: This is often seen as a dangerous question, as it opens up scope. It certainly needs to be used alongside clear expectation management, however it can get us closer to the real business problem or opportunity that is being addressed by the project.

2. “What is the worst possible project outcome from your perspective, and why?” : This might sound like an abrasive and counter-intuitive question, so it’s essential that you are sure you have built good rapport with a stakeholder before using it. This question is valuable as it helps to elicit values, constraints and tolerances.  For example, if the worst possible outcome is “Late delivery, because the regulator will shut us down”, then you know that time is the key constraint.

3. “Imagine nothing changes. What would happen, and where would the organisation be in 12 months time?”: This question helps to understand the relative urgency of the project, and is also likely to uncover any environmental factors.  It also helps to confirm the business drivers for the project.

4. “If you had to articulate the project objectives in a single short sentence, what would it be. And how will these objectives help the project to deliver financial benefit?”: It can be enlightening to ask stakeholders to succinctly state the purpose of a project, stating how this is of financial benefit.  Often, different stakeholders have subtly different worldviews, and therefore perceive projects differently. For example, an operational stakeholder may focus on efficiencies, a marketing stakeholder may focus on increased revenue. Even when a business case has been drafted, stakeholders tend to have slightly different views on what benefits will be realised (and how they will be realised). This is extremely useful to know, as it will uncover any areas of disconnect early so that they can be resolved.

5. “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”: This question helps gain an understanding of the future state of the organisation, and what it means for the people and processes that run it.  It can be used to get a sense for the size of the change that is envisaged.  For example, does it involve significant organisational restructure? Or is this out of scope?

6. “How do our competitors handle this? Do we want to be the same, or different from them?”: Often, business stakeholders will look to see how a competitor has solved a particular problem, and will initiate a project to replicate this.  In some circumstances, this will be a completely valid approach.  However, a better solution might be to differentiate from competitors, and solve the problem in a new way that increases value to customers.

8. “Is there any other way your business objectives could be met? If not, can you explain why this is the case?”: It is extremely useful to know whether delivering a particular project is genuinely the only way to address the business problem/opportunity that has been identified.  There might be others, and it’s useful to know whether they have been ruled out.  Other options might include:

• Process (rather than IT) changes
• Organisational changes
• Outsourcing work
• Manual workarounds

In summary, using provocative questions is a great way to encourage lateral thinking amongst your project stakeholders.  This will help to surface ideas, values, issues and perceived constraints.  Once these thoughts have been explicitly surfaced, they can be discussed and re-evaluated.

Encouraging lateral thinking helps to uncover imaginary constraints, and helps us challenge the business objectives to ensure they are sound.  I hope that the questions above help you engage with your stakeholders and understand what their projects mean for them.

>> Learn to Ask More Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

It is important to have a conscious professional development strategy and this is likely to involve a number of activities.  However, it is good practice to build in professional development to your weekly and monthly schedules.  Professional development doesn’t have to be costly or time consuming, and it’s important not to overlook the experience we gain in our project work.

One of the single biggest ways we develop as BAs is through the work that we carry out day-to-day, and I have found that keeping a project journal is an incredibly useful professional development tool.  It can be tempting to move straight from project to project without taking any time to reflect on what has been learned, but consciously recording relevant information in a journal (acronyms, terminology, lessons learned etc) can be an effective way of crystallising knowledge and storing it for future use.   This can become excellent reference material if you work on a similar project in the future.  The act of reflecting on your progress and recording it, is useful in itself, as it helps you to consolidate your knowledge and consider what you might do differently in future. It can also be useful to review the journal periodically, to reflect on previous projects and ensure any knowledge is carried forward.

You can spend as much or as little time on this activity as you like.  It would be valuable even if you only spent 15 minutes writing a summary after every project engagement.

A very light-weight journal might include:

• Project name
• Date started/date completed
• Techniques used
• Stakeholders worked with
• 3 things that worked well
• 3 things you’d do differently next time
• Biggest learning point
• Acronyms & terminology
• Other relevant information

You can tailor your journal to your particular needs and preferences.  I keep an incredibly light-weight journal.  By keeping the journal short, this makes it very quick to update (which means I am much more likely to do it!).

A project journal can also form a useful part of your stakeholder management strategy.  For example, you might learn that a particular stakeholder likes to receive information in a particular way (perhaps they prefer diagrams, or value telephone calls over e-mails).  It can be incredibly useful to record these preferences, so that you can keep this in mind for any future engagements.

The journal itself can be kept in any format you like.  You could keep it on paper, electronically or even on your iPhone.  I personally keep mine in Excel, as it is easy to sort, search and update. The important thing is to get into the habit of updating it, and allowing time to reflect on your progress.  Why not put a monthly reminder in your calendar, blocking out 15 minutes for reflection?

One final benefit of a project journal is that it provides an excellent repository of information which you can use to periodically update your CV or resume. It will also help you if you decide to apply to become Certified Business Analysis Professional (CBAP ®) qualified, as you will need to provide evidence of your project experience.

However you address your professional development strategy, I hope that you have found this article useful, and I hope that you consider reflecting on your experiences and keeping a project journal.

>>Invest in Your Professional Development (for free)

Start your business analyst career with our free step-by-step career planning course. Upon joining, you’ll also receive our BA career planning guide and follow-up insider tips via email.

Click here to learn more about the free course