“Make it Real” with a Usage Narrative

Usage Narratives aren’t really use cases – at least that is what I have been told by several Use Case authors. But they do have several of the Use Case benefits: They are from the user perspective, they show a scenario, they can uncover additional requirements, and they have a “happy path”. But I found them to be most useful in making technical team members put themselves in the shoes of the user: no technical terms, no “user” or “system” but real names of people and applications. So let me give you an example of a usage narrative describing the process of using my brand new iPhone to access the internet through Safari (true story).

…Gina was working extremely hard in her home office [my business partners may question the reality of this] when her 92 year old father walked in. Peter had an urgent need to find out where a particular bank was and their hours because the newspaper advertised they had the best CD rates for his retirement fund. Gina tried to get online quickly, but had problems with her new PC. She saw her iPhone charging by the PC and check out if she could connect that way. She touched her menu button and immediately the Safari icon showed up on the bottom of her desktop. When she touched the “Safari” icon it took her to the last search she did – checking a flight schedule while at the airport the other day. She touched the multi-page icon and then “New Page” to start a new search for her father. She realized that she could turn the iPhone so it could be more easily read in landscape (she didn’t have her reading glasses). Gina touched the search bar and it went to keyboard view. She quickly entered the banks name and touched the search engine icon on the bottom right corner. Success! She found the link to the bank and wrote down the information for her father…

Now if we were really using this usage narrative, what questions might it trigger to help uncover requirements? How might this help in understanding the various types of users? How might this usage narrative provide the reasons for using various product features? How about asking about response times (what does immediately mean)? How about thinking about the what-ifs – what if she timed out while waiting for the search and it went back to her password screen? Could it be used to show the current feature or the new and enhanced one?

So give it try. Next time you create a Use Case, “make it real” with a Usage Narrative. For more information, check out the book “Writing Effective Use Cases” by Alistair Cockburn.

----Eugenia (Gina) Schwalm, Managing Partner at Lighthouse Consulting Partners, www.lighthouseconsultingpartners.com

Manage your distributed team expectations – Remember, they are also stakeholders

We have all been there. Which side of this conversation were you on? Consider that moment when someone’s voice changes over the phone or there is that silence at an unusual time signaling your senses that this person is angry as they describe why they are upset. They say you are 2 days late on delivery and that is UNACCEPTABLE! You barely have a chance to say anything when they tell you it needs to be turned around right away. Fear of an outburst of emotions being around the corner you say you will try without giving any explanation. The last project you were on you could be up to 2 weeks late without any concerns since quality was the emphasis and was what was measured. Why is this project so different? Well, it is the first time I have to deal with someone across the ocean.

When teams are brought together, there are the typical cultural differences that can hinder communications. But for projects with teams distributed across time zones in various countries across the world, differences becomes magnified. One way to lessen the impact is to consider setting up a project climate that provides the team the boundaries to build their own project culture. A Project Orientation Package (POP) or Team Orientation Package (TOP) can help provide that. It provides boundaries for the team and sets expectations that can be clearly documented in the project management plan or documented in a standalone document. It should describe how we as a team will communicate, escalate, schedule meetings, access information, use collaboration tools, identify what to save or throw away, what is confidential or what can be shared, communicate information about each team member, information about each location, holidays, etc. But best of all, it tells each team member when they might get into trouble. No one likes the conversation above – especially if they really thought they were doing a good job and didn’t see it coming. Clearly define what is important for this project or team. What are our guiding principles? How can we help each other out? Do we know how late is too late, how much money spent is too much, how much change it too much. How much am I empowered to handle on my own and when do I escalate? Every culture or team member experience may put a different emphasis and threshold on the project factors (time, cost, scope, quality). Remember, you have to manage stakeholder expectations – and your team members are stakeholders too!

----Eugenia (Gina) Schwalm, Managing Partner at Lighthouse Consulting Partners, www.lighthouseconsultingpartners.com

Gathering Requirements and Negotiations: Process Similarities?

I was just putting a presentation together for the Michigan Council of Women in Technology (MCWT), www.mcwt.org , called “Negotiations for Amateurs”. As I was putting the presentation together, brushing up on my negotiations knowledge and recollecting my experiences I made this interesting connection. I am sure others probably have also, but I thought I would throw this out there to find out.

Negotiations has always been a key skill for business analysts. Requirement priorities – negotiate. More time needed for analysis – negotiate. Package requirements into releases – negotiate. I think you get the point. But as I reviewed the formal steps of negotiations and the key to making negotiations work, I seemed to find similarities between the steps in the negotiation process and those in gathering requirements. As I stress to my requirement workshop participants – focus on the why – the business reason or the need. Do not jump to solutions. But in negotiations the tendency is also to jump to solutions or to just state your position. The key to effective negotiations is that you also have to get to the why – the interests. If you don’t get to the interests then you are not giving much value to what you are negotiating for or giving each of you a chance for that win/win.

So learning negotiations can help a business analyst in many ways! You may want to check out the book “The Negotiation Fieldbook” by Grande Lum. Short read with some nice examples.

----Eugenia (Gina) Schwalm, Managing Partner at Lighthouse Consulting Partners, www.lighthouseconsultingpartners.com

When I wear two hats – Project Manager and Business Analyst

Thoughout my career, sometimes without realizing it, I played many roles in the IT world.


Most of the time I dealt with the multiple roles as just a combined series of tasks that had to be done on small low risk projects. But as my career in the IT field grew, so did my responsibilities and the complexity of the projects. Sometimes I was the project manager, other times the system architect and other times the developer or tester. It depended on that difficult balance of resources, effort, money, time and quality. When I was told I was the “Project Manager” (PM), I quickly figured out that it involved more than just managing the project. Sometimes it involved me doing the tasks. This slowly became a common problem throughout my career, trying to determine the roles in the software development lifecycle and who would fill those roles. Didn’t have a body to do the work? I would fill that role. Eventually I became a manager of consultants, auditor of software development projects and seller of IT solutions to clients.

So what?

Well, now that I am a Project Management Processional (PMP®) and a Certified Business Analysis Professional (CBAP™) I am deeply involved in transferring my knowledge in both these areas to others in the industry. I have put quite a bit of thought into this historical issue of mine – wearing the multiple hats. Many class participants have also brought up the problem – extending ourselves to multiple roles. In particular, I have found challenges when both the PM and Business Analyst (BA) hat is worn on a single individual. From my experiences the PM role typically wins out because of the pressures of reacting to project fires, but it is the BA role that can prevent you from falling into the fires in the first place. So, if you are a PM who also plays the BA role, have you considered:

1) Clearly defining each role and communicating the tasks by role at first– not by person – to ensure all tasks have been clearly defined and effort estimated (if you don’t ask for the time or money you won’t get it)?

2) What the business analysis tasks are in your project plan (throughout the lifecycle) – even if you plan to do them? Allowing time for traceability?

3) That a PM focuses on the work and what has to be done to deliver what is expected and the BA focuses on the product or solution and ensures it meets stakeholder expectations once it is delivered?

4) That both the PM and BA need to be concerned about tradeoffs throughout the project among the project factors of cost, schedule, quality and scope (both work and product)?

5) A BA must communicate requirement risks to the PM. Have you communicated those to yourself – well, I know I am trying to catch a laugh here, but seriously, have you considered these risks in your risk management process and considered different approaches to mitigate requirement risks?

So if you feel you are in this situation, I recommend that you get familiar not only with the Project Management processes (www.pmi.org) but also check out www.theiiba.org for their next version of the Business Analysis Body of Knowledge (BABOK™). Get familiar with the BA role and Business Analysis work – at least it won’t catch you off-guard!

----Eugenia (Gina) Schwalm, Managing Partner at Lighthouse Consulting Partners, www.lighthouseconsultingpartners.com