Strategic Requirements Analysis

From Interviews to Models

Karl A. Cox

• Verlag: Routledge
• Jahr: 2016
• ISBN:
  9781317049531
• Auflage: 1
• Thema: Business
• Thema: Gestione dell'informazione

A strategic requirement is something an organisation sets out to achieve; it could be the long-term vision the organisation sets itself, the key business condition for a specific project to be a success or a business strategy to achieve a goal. A set of strategic requirements defines the goals, strategies and tactics that organisations need to put in place to give them direction and impetus. Business analysts and consultants have to understand strategic requirements to know where projects can deliver business benefits and where not. The ability of the analyst to interview, gather, analyse, model and present strategic requirements is key to success. The primary tool consultants and business analysts use for communication is talking; but, if you cannot present all that incredible information back to your client effectively, it is hard for them and you to get to grips quickly enough with what is going on. Being able to present a model is really powerful because it provides a visual format and structure on one page to reason about those strategic requirements. Dr Karl A. Cox offers a process, guidelines and ideas - that have been tried and tested in practice - for conducting interviews and shows you how to rapidly turn interview findings into strategic requirements models all on one page, to present to your clients, customers, team and / or supervisors.

Chapter 1
The Plan

Why should you plan your interviews? If you don’t plan, your interviews can only go wrong. You simply would not know if they went well or not because, without a plan, you would have no idea of what you needed to find out. Without a plan, you won’t be able to manage an interview or the interviewee. Before we look at the individual interview, we first need to know more about the project itself.

The Project Checklist

In order to plan for a set of interviews you should prepare answers to the questions/tasks you need to do as listed in Table 1.1. The project preparation checklist forms the structure of the plan. To complete the plan, you answer the questions and document the answers, where appropriate. Once all the necessary questions have been answered, you can then feel even more confident about conducting a set of interviews.

Though there are many questions in Table 1.1, it isn’t always the case that you will need to consider all of these. You may need to only use some. You may also want to address alternatives to these by adding to or deleting questions. Please feel free to do so. Though what I am suggesting is a fairly comprehensive approach, I expect you to be flexible and only use what is useful and relevant to your context. The columns in the table are self-explanatory. ‘Answer?’ is for answers to questions when needed. Ensure you list the person responsible for the activity. This allows you to cross check and confirm. If you’re the only interviewer, then you can ignore this column. Except, of course, there are activities in the list that might be the responsibility of the client. If you know who is responsible for organising interviews, for instance, add their name and contact details such as a phone number and email. The ‘Issues’ column is a place where you can very briefly highlight any concerns over the specific planning activity. This then acts as a reminder that you need to resolve the issue. It’s easy to forget the plan once you dive into the actual interview work. Reminders really help so make use of them.

Remember this is a checklist for planning the interviews. Once you’ve completed the plan, you have to be able to conduct the interviews and that involves further planning, as described in Chapter 2. For now, though, let’s get on with the preparation, starting with the first item in Table 1.1.

Table 1.1 Project preparation checklist

WHAT IS THE OVERRIDING OBJECTIVE FOR THE PROJECT?¹

Normally there is one overarching goal for an engagement. It’s like a Vision statement for your project. You need to find out what it is. This objective might vary from stakeholder to stakeholder but there will be a single stakeholder with overall authority for your engagement, its execution and outcomes. Why do you need to know about this? Surely you’re hired to just find out about stuff? Well, yes in the most abstract sense, you are. But in order to bring a sense of purpose to your own work and steer the project in the right direction, knowing the point of your engagement helps. It helps in determining what elements of the following to focus on:

• context of engagement;

• scope of deliverable;

• range of stakeholders to interview;

• expectation of your client on what you will deliver.

Some examples of overriding objectives:

• identify gaps in current supply chain business processes and propose mechanisms for plugging gaps;

• establish root causes for critical release failures and identify potential short and longer-term solutions;

• show how new infrastructure provides business benefits across the organisation;

• gauge public sector reaction to product ‘y’ claims.

Note that the examples are not mission or operational statements – they say nothing about how you go about the engagement, only what you are trying to achieve. Also note that the first two are in two halves:

1. identify/establish current situation of ‘x’, whatever ‘x’ is;

2. propose solutions to solve/redress problem in (1).

It is important that these statements push you towards a well-scoped deliverable. The final two examples simply push for well-scoped deliverables of a known phenomenon.

WHAT IS THE CONTEXT OF THE ENGAGEMENT?

Finding out the context of the engagement is very important. If you can get some grounding in the context, this will put you on a good footing with your prospective client/colleagues. You will be able to discuss the broad goals of the engagement with reference to the background context. This will give you a good sense of the scope of the engagement. It will importantly give your client a feeling of confidence that you are the right person for the job.

Context does not grow on trees so you need to do some initial research. Of course, you won’t do this until you know you are potentially going to be engaged on the project. Typically, you’ll be contacted by a stakeholder who is involved in the project or by reference from a friend or interested party who introduces you to the prospective client. You will quickly learn something about the engagement from this first contact:

• Who the client is and what the client’s company does.

• The type of engagement, for example: aligning strategy, gathering requirements, post mortem review, mid-term review, requirements validation, market analysis and so on. You’ll also need to find out about geography – do you need to travel between sites and even cities?

• The scale of the engagement – roughly how big it is, that is, how much money has gone into the project, how long is it expected to run/how long did it run for?

• The importance of the project to the client – is it strategic?

• What is the potential impact/was the actual impact of the project?

• What does the client expect from you?

• What are the time frames for delivery?

If you are working in-house, then you should already know about the project you are going to work on prior to being called in. That means you need to keep up with what your company is doing, especially if it is a large project. The last thing you want to happen is for a senior manager to call you in and ask you to get some information together about ‘project x’ and for you to reply ‘what’s project x?’ when it has been in every internal memo for the last six months!

How do you find out about your client? This will depend on your client. If the client is a publicly listed company or government agency, then you can find out a lot of information from the annual reports that it has to make publicly available every year. But why should you bother with this? Understanding your client’s business is important because it will allow you to understand its current health – is the company booming or struggling? This will tell you something about:

• the working environment to expect;

• how motivated and stressed out the people you will interview are going to be; and

• the importance the client places on the project and your engagement.

If the company is private it will be most unlikely it publishes any financial information. But it should have a website and this will give you a good idea of the business the client is in, the products and/or services it offers and also who’s running the company. You should check these people out because this will give you a feel for the culture of the company. Does the chief executive officer (CEO) have a proven track record in the other companies he has worked in? What about the chief information officer (CIO)? This will tell you about the current state of your client’s company in terms of drive to succeed in its market. Who are its customers? If your client is government then it is often harder to find out about the agency culture and its effectiveness, unless you are an insider in government yourself. But at least all government agencies have a mountain of freely available information about themselves, often including a strategic plan. You should always take a look at this to get an idea of what the agency is trying to achieve and how it plans to do it.

Ask around. Do you know someone who worked in/knows about your client’s business/project/product? What is their experience/knowledge? If you are in-house, do you know someone working on the project? What is their impression?

Get the client to provide you background documents on the engagement. If you are being asked to do a feasibility study, ask about whether there is a marketing/business plan you can read. Is there a business case? Are there any corporate brochures, slideware presentations to look at? If you are being engaged to interview stakeholders as part of a post mortem review, ask for any project documents the client is prepared to hand over. Were there any major incidents? What were they? Did they make the press? Some do. The documents might not always be appropriate but they give you some context and get you to start thinking about the engagement.

SCENARIO: HOW A JAPANESE COMPANY WORKS WITH ITS CLIENT

A leading Japanese systems integration (SI) company, Nomura Research Institute (NRI), before commencing an engagement, and at its own expense, sends a team of consultants into the client company to read up as much information as possible on the client and project at hand for a week prior to starting the work proper. Effectively, NRI is learning about the context of the engagement before getting too deeply into it so that: (1) NRI consultants understand the language and landscape of their client’s business; (2) NRI appears as it truly is – highly professional; and (3) it delivers real value from day one.

CONTEXT CHECKLIST

Table 1.2 lists the key things you should consider when thinking about context. Remember that working through one of these tables doesn’t mean background reading is over. All it means is you’ve done some homework and are reading up in order to present a knowledgeable face to a nice suit. It may not sound like a lot but it means a great deal to a client when you can talk their business from the start, even if it is only in terms of generalities. The specifics are what you will find once you get your hands on some of the documents not made public and of course when you start interviewing.

Table 1.2 Context checklist

Note entry point 5 in Table 1.2 above: ‘Your thinking/impressions’. This is really important so I’ve left it to last. You will form an opinion even if you don’t want to. You will need to go into the engagement with some pre-conceived ideas about the company and the engagement itself. Why? Surely this would be a bad thing and you might even embarrass yourself? Well, no, not really. You might ask a dumb question but the point is you do ask the question. This will get a response and you will get an answer that will provide you with more accurate context and scope to the engagement’s overriding objective. You will learn more if you ask. And you must always learn as much as possible. Also, if you have a team that is going to conduct the engagement, then you should get together with team members to thrash out your thinking about the type of engagement, what you know about the client and what you might expect. You will probably find your first impressions are wrong to some extent, but you need to start somewhere so start now. For now, though, let’s get back to the planning.

WHO ARE YOU GOING TO INTERVIEW?

This decision is often made for you. Typically your client will have a prepared list of relevant stakeholders for you to interview. But just because you have a list does not mean you should stick religiously to it. There is nothing wrong with deviating from the list provided you have good cause, such as a key stakeholder was accidently excluded, or you needed a second opinion from a specific job role. You’ll find that the list may have missed somebody out because the person or persons who prepared the list of interviewees were unaware of who all the major players are.

The important thing to remember about who you interview is to cover all the key roles or aspects of the project. If you are engaged on a Strategic IT project, you will need to interview:

• C-level management. There are few C-level employees and most are far too busy to see you. But you should at least talk with the CIO. The CIO might even be your client. Ask about the business, the strategy, the IT.

• General managers/division heads. Many will be are affected by the proposed system or the newly installed system. Ask about: how each division/business unit interprets and meets the corporate strategy; about the division’s business; about the impact of IT on that business; the role of IT in delivering that business.

• Programme/portfolio managers. Strategic projects are often part of a larger programme of work. There will be a programme manager/portfolio manager who oversees all the projects for that programme or portfolio. Ask about how the programme meets the strategy and how the engagement project fits into the programme. What are the project’s dependencies with other projects? What are the affected business processes?

• IT team members. An enterprise architect will have some understanding of the business organisation and strategy and will know a lot about the IT infrastructure. Ask what’s new/needed/changed? How will that be managed/was that managed? How was change handled?

• IT team members. A project manager can give you the overview of the project and hopefully where it fits into the bigger programme picture. What’s the critical path for the project? What are the high-priority requirements? Where is the project being delayed?

• IT team members. Who else? What about the business analyst (BA), who is the conduit between business and IT? Who does the BA think is really key to talk to? How is the IT going to help deliver on the strategy? If you’re investigating an IT failure, talk to developers, talk to designers, talk to infrastructure managers. If you’re the BA, you shouldn’t interview yourself, of course!

• Customers. Customers could be citizens, such as those who use a government website to claim benefits. Ask questions like: What’s the impact on citizens of the change from face-to-face meetings to using a website? Did the website provide all the information you needed? Did it work? What advice did you get if you were stuck? What do you need to be able to do? Did you have easy access to a computer with internet connectivity?

• Users are similar to customers and more likely to be internal to the organisation. Users use the software that’s built to help do their jobs, such as input data, produce management reports, interact with customers. Don’t talk to every single user unless there are less than 10 but do talk to representatives for each of the different roles. Ask questions like: What does your job entail? Does the system allow you to do all you wanted to do with the system? What are the workarounds? How do you fix them? What do you do in your job? How does the system positively/negatively impact your job? Walk me through a typical transaction.

For a post mortem review of a major project failure of an external public release, such as customer-facing systems shutting down in offices where customers renew passports because of a bug in the printer queuing software, you should probably talk to:

• All roles listed above.

• Customers (again). How did the failure affect them? What could they/couldn’t they now do? Don’t talk to every customer but if there is a customer representative group of some kind, go have a conversation.

• Incident report managers. Who records the incident? What happens to the report? What is the process? What is the reporting line?

• Customer office managers. How did they handle the shut down/crash/disaster? What were the workarounds? What were their teams informed about before, during and/or after the incident?

• IT architects. Find out how the printing bug got into the system.

• Quality Assurance. How did the print bug get through the testing process?

As I said at the start of this section, who you talk to is largely predetermined before you step into the room. The above examples give you an idea of the roles you want to think about interviewing. It is not an exhaustive or all-inclusi...

Inhaltsverzeichnis

• Cover Page
• Title Page
• Copyright Page
• Contents
• List of Figures
• List of Tables
• Preface
• Acknowledgements
• Introduction
• 1 The Plan
• 2 What Questions Are You Going to Ask?
• 3 Conducting the Interview: What to Say
• 4 Interview Analysis
• 5 Strategic Modelling
• 6 Presenting Your Work
• Concluding Remarks
• Index