Controlling your requirements destiny

Either you know you know, you know you don’t know, you don’t know you know or you don’t know you don’t know? Come on, which is it?

As I have mentioned in earlier posts Requirements Elicitation is a complex task, full of knowns and unknowns. Let’s dissect what you know from what you don’t:

 

Spin, spin, spin the Wheel of Fortune!

Fact

When you know you know it is a fact.

Well, it’s a fact in your mind at least! Mrs. One Minute BA often has a different perspective to me and I have to admit I have my facts wrong (yes, it has been known!). Thus, facts must be documented as part of requirements package, e.g. as a requirement, business rule, constraint etc., and verified as part of the standard review process.

Question

When you know you don’t know there’s a gap.

Don’t mind the gap! It’s a good place to be, it means that you are aware there is something lacking and are able to control your destiny. Here you can do one of two things: make an assumption to fill it or elicit information to factualize it. Clearly the latter is preferable, but again document either so that others can accept or deny.

Experience

When you don’t know that you know you’ve lost it (and yes, maybe in that way – projects can drive us all a little crazy).

You knew it once. Perhaps it’s become so entrenched as the result of your experience that it has become tacit or maybe the fact never stuck in the first place. The former results in undocumented facts or assumptions; the latter may result in you asking the same question again, but it’s better to ask a question twice than not at all!

Fate

When you don’t know you don’t know you’re destiny’s child.

Is ignorance bliss? Or will fate deal a cruel hand? Since you never knew that you didn’t know or know that you needed to know, you haven’t asked any questions nor documented anything.  Maybe it was on a need to know basis and this piece of information was someone else’s fact or fact missing in action waiting to be elicited.

Now that you know I know you know, you know that I know that you don’t have any excuses, so now know that the Wheel of Fortune turns into the Wheel of Justice!

(Suitably tongue twisted?)

OMBA

17 tips for signing-on requirements

Reaching agreement on product requirements is at the heart of the Business and IT partnership.  Typically, organizations use the ritual of signing-off, even though it’s typically all about signing on!

It’s unfortunate that I use the term ‘ritual’ but all too often it seems that the activity is performed mainly for its symbolic value: with people being either reluctant to give their signature, refusing their signature, avoiding a signature, giving their signature for the sake of giving or giving it all too freely. Some, statements I have heard “professionals” say:

Sound familiar? Each is a massive warning sign, which will inevitably lead to future conflict. Let’s remind ourselves of the purpose of the requirements document sign-off activity:

To review with the intent to endorse or reject a shared definition of the product to be delivered

This sounds simple enough, what’s the big deal? The big deal is the connotations that come with it.  I suggest that the problem stems from a variety of masks ranging from fear through bravado to carelessness, regardless we need to remedy the situation.

Here are 17 tips for a meaningful sign-off:

1. Select a review group that covers all viewpoints
2. Explain the need for a shared understanding
3. Explain the intention of the document
4. Educate the reviewers in content and meaning
5. Advise the reviewer the value they bring
6. Discuss personal viewpoints e.g. I can use it, I can build it, I can test it
7. Ensure reviewers know what acceptance means
8. Advise the subsequent processes for the possible outcomes
9. Reassure that it is a best picture of the requirements
10. Explain the best picture is relevant to right now
11. Agree that requirements change
12. Agree change may requires additional cost, people or time
13. Concur change may impact on external areas
14. Accord defects are so when they can be traced to a requirement
15. Communicate that it is acceptable to reject the document
16. Realize that ‘no comment’ is an indication of a poor review
17. Don’t consider grammatical correction as feedback

Notice I use words like ‘intention’ and ‘best’, nothing is perfect – particularly project journeys, but the above can help you get stakeholders on board and aboard the right train.

Proto-typical benefits

Here are the reasons why you should not prototype:

Reasons not to prototype

Shucks, well that’s that then. If only there was someone who had the skills to focus on business objectives, capture requirements, manage product scope whilst handling user expectations (providing personal counselling to developers is an added bonus). Now where would I find me one of those?!

In all seriousness, I think a number of these disadvantages stem from the more traditional (read historical) method of prototyping whereby the user and developer were entrenched together alone, heads down and emotionally committed to the task at hand. Keep in mind, regardless of who uses it, prototyping is an analysis tool and thus the Business Analyst will add much needed control to the prototyping way.

So now that we have mitigated the risks let us take a look whether there is good reason to do it. Prototyping:

Reasons to prototype

Wait, did I interpret that correctly? We can have improved quality, in a shorter time and at a lower cost? And you said I couldn’t have all three Sir Arthur C. Clarke!

With that said then, I decree every software development projects shall be prototyped! Hold up, not all projects are suitable candidates. Here’s the caution, consider:

Selecting candidate prototyping projects

If you look, the key trait of the advantages above is business, business, business. We know that a project with significant business involvement has the greatest chance of success, perhaps prototyping is a just successful motivator of it?

SWOT’s up?

SWOT Analysis (aka TOWS) is a versatile technique that’s applicable throughout an organization: be it at the enterprise, business unit or operational level, and can support a variety of goals:

• Strategic analysis
• Project planning
• Comparing options
• Implementation feedback
• Workshop Evaluation
• Performance appraisal

Too often a SWOT diagram is seen as the first point of call in strategic planning; its real value is to profile the results from situational analysis activities in order to drive strategic planning.

Let’s look where the SWOT profile fits into strategic planning:

A, B, C of Strategic Planning

To begin with, analyse the internal and external environments considering areas such as culture, skills, market share, customers, competitors etc. Then generate a SWOT profile, which is what today’s #babite is all about, so hold fire! Finally, plan what needs to be done (strategy) and how to get it done (tactics).

With the context out of the way, let’s take a closer look at that middle task.  To produce the SWOT profile we’ll need to put on our thinking CAP:

Thinking CAP

1. Categorize

The results of the situational analysis must be organised. Internal environmental factors are summarized as ‘strengths’ or ‘weaknesses’ whilst the external factors are classified as ‘opportunities’ or ‘threats’, accordingly either are positive or negative.

SWOT Diagram

2. Analyze

Now don’t just accept these results – take a closer look. The diagram can over simplify the situation, as environmental factors don’t always fit a category snugly: strengths can be weaknesses and opportunities threats. Get a group, review, brainstorm, consolidate, tidy up and make amends.

3. Prioritize

By now we should have a wide variety of factors, but we’d better sort them into some sort of order as input into the final planning step. The SWOT profile is often displayed as a matrix list.

Personally I find this a little tame, I Pimp My SWOT!

By adding different filters and positioning the factors, I can prioritize pictorially and view from varying perspectives.

Pimp My SWOT!

Mix them up. Create your own. You get the idea!

Now we have our SWOT Profile ready for the strategic planning step, which looks to:

• Leverage strengths;
• Remedy weaknesses;
• Seize opportunities; and
• Mitigate threats.

The techniques used for situational analysis are key to strategic success, as is striking a balance between internal and external analysis.

Bring forth the requirements!

Non-business analyst’s often look at me funny when I use the term ‘Elicit’, I can see the “why can’t you BA’s just use a normal word like ‘gathering’?” look in their eyes.

Well, as you asked.

Words like ‘collect’ and ‘gather’ conjure up images of squirrels foraging for nuts or Goldilocks picking flowers, both happily going about their fairy tale day with blissful ease. Life for the Business Analyst is not as straightforward because requirements, despite popular belief, are not just sat there waiting to be plucked.

Let’s consider the definition of ‘elicit’:

to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question

Not being a non-BA, I can’t think of a better word than ‘Elicit’ to describe the activity, although the term ‘extract’ can be apt, as it can feel like I’m pulling teeth sometimes given the minefield that projects are.

To the untrained eye it may look like a flower ready for picking, but I assure you it is a minefield

Thus, there is significant proactive elicitation by the analyst to draw and bring forth true requirements from the stakeholders. To help navigate through this difficult terrain, we have a variety of techniques at our disposal, each one with their own pros and cons.

Elicitation techniques, their pros and cons

When used appropriately, these techniques help users to understand the situation and visualize the possibilities, consequently the requirements emerge and are articulated.  However, people typically pass on their explicit knowledge: “we know more than we can tell” (sig. Polanyi), and a major problem is that of tacit knowledge. We must include practices aimed at identifying actions and skills for those aspects that we are unable to articulate.

Moreover, should we approach a new project and an enhancement with the same strategy and tactics? No, we should not. Don’t default a technique because “I have done it before”, or because “it worked for me last time”. Each project is unique and the chosen elicitation approach should reflect the job in hand.

Project versus knowledge type matrix

That said, don’t be constrained by the above matrix. Document analysis may be irrelevant for a greenfield project, but prototyping could be great for gaining explicit knowledge also.

Remember, Business Analysis is an art not a science.

Stakeholder Analysis and Management

Stakeholder management, like many soft issues, is often overlooked in the bigger scheme of projects. Whilst the success factors time, cost and quality are key indicators, business acceptance is equally crucial to project success.

Poor stakeholder management is increasingly becoming one of the major reasons for project failure.  When a project is perceived as a #fail, it is a #fail. No matter how incorrect that perception may be.

We can reduce the risk (impact and likelihood) of this happening by adopting a formal stakeholder analysis process.

A Stakeholder Management Framework

1. Identify Stakeholders

First, we need to brainstorm the interested parties, given the definition that:

a stakeholder is anyone that has a stake in a project because they can affect or be affected by its actions, outcomes and / or policies

We’ll use a stakeholder identification chart  to consider internal and external people, groups and organisations. The proximity of the stakeholder to the central project indicates the assumed level of interest; the closer the stakeholder the greater the consequence of the change.

Stakeholder Indentification Chart

2. Understand stakeholders

Next let’s begin to analyse the needs and concerns of our stakeholders. The best way to do this is to interact with them directly and discuss the situation.

For each stakeholder we’ll make an assessment of their position.

Stakeholder Analysis Worksheet

3. Position stakeholders

Now we can prioritize our stakeholders by mapping their position on a chart proportionate to their level of power/influence and their interest in the project. When you mark peoples names on the grid use color to depict their attitude: red = negative, amber = neutral and green = positive.

Their position on the grid indicates the communications approach we will need to take.

Power / Influence versus Interest Matrix

4. Plan strategies

Finally we must create a communications plan for each individual stakeholder. We need to ensure buy-in and manage negativity, so form your strategy and tactics thoughtfully.

Communications Plan Worksheet

5. Engage stakeholders

Okay, we are as ready as we’ll ever be.  Let’s ensure that the expectations of key stakeholders are understood, acknowledged and put our plan into action.

Wait. Where are you going? The exercise has only just begun.

6. Monitor stakeholders

The stakeholder analysis activity must continue throughout the change to monitor effectiveness and receptiveness. Get to know your stakeholders even better! Seek feedback, observe, adjust and tailor your approach.

After all, a plan is exactly that!