Live from BAWorld: What To Do With Interfaces

Mary Gorman from EBG Consulting presented “Integrating Interface Analysis into your project: Just-enough, Just-in-time”. This talk was one of the advanced topics, with the intent of teaching about how to do interfaces – software, hardware, and user interfaces. I’m going to capture some summary points from her talk, either the key points or the ones I found most important:

1. She talked about just-in-time interfaces, specifically of interest is that idea that you can identify interfaces early in the project (first days even). A lot of projects wait on these, but there is no reason for that and you may miss things if you wait.
2. Do just enough. In some cases you can do minimal formal documentation, just enough to build and demonstrate the system, whereas other times you need very formal structured documents.
3. Business rules are at the center of all models. They are used by all models, and you will discover them in most models.

Mary talked about interfaces in various types of projects. For example in COTS projects, interface work is usually not about the user interfaces, but rather more about system-to-system interfaces since the COTS software has to integrate. When working on a project to update a system, existing interfaces have to be looked at for updates, and new interfaces or users might be added.


And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.


My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.

I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.

Live from BAWorld: A BA Mentoring Program

I heard a talk on building a mentor program for business analysts (BAs) by Dave Ramauskas from HTSC, along with 2 people from his mentoring program. They started by describing a challenge which we’re familiar with – that it is hard to recruit really good Bas, and very few of those found are hired. That’s why it’s important to use mentoring to grow the junior BAs and retain the senior ones.

They did a nice role playing skit to demonstrate what the mentoring relationship might look like in a specific scenario. As a side note - there were only a few talks I’ve seen here that did something like this, and they are all my favorite talks.

They walked us through the details of their mentoring program. And like with most companies, it’s a challenge to get a program up and running certainly, but they seem to have done well for a first cut. Here are the things they did, with my comparisons to how we handle this at Seilevel.

1. How to match mentors and mentees: Some suggested using personality profiles, others suggest just matching based on skills. They tried a variation on “speed dating”, they call it “speed matching”. In our organization, we let them pick each other. The mentors decide to be mentors, publish a little piece about their mentoring style, and mentees get to leisurely browse the profiles and talk to the people until they find someone they want as a mentor. The two parties then decide if there is a fit.
2. Implementing the program: They suggest using a written development plan for the mentee to help focus the mentoring efforts. They referenced a Harvard study to demonstrate the value in writing goals. We use something similar where we have mentees work from an organized list of skills areas for the growth path we want people to go through.
3. Wrap-up: They do a graduation from their mentoring program. This is different than our mentoring program, which is always ongoing. I believe their structure to it suit their need of growing a set of highly talented newer resources for a period of 9 months each year.

Mentoring requires time and resource commitment from both parties and management to put time in it, and for the most part they seemed to have that. Also, it’s worth mentioning that some of the specific BA skills are not trivial to mentor. They didn’t really address this aspect at all, but from my own perspective that the average person isn’t necessarily going to be good at mentoring something like elicitation or facilitation skills. In the end, I think they do some things very well. I cannot stress enough that our mentoring program is a work in progress to say the least, so I'm thrilled to hear about some others trying to set this up as well.

They suggested a couple of books on mentoring:

1. Strength finder 2.0 - Apparently there is an online tool to help you identify your strengths, and the book helps figure out how to apply those at work.
2. Mentor and Mentee Guides

Live from BAWorld: A Case For Visual Models

I heard a presentation at BAWorld, but for this one I won't mention who it was, because I'm going to critique it in a very specific way. The talk wasn't bad per se, but one thing about it really bothered me. You see, the speaker displayed a slide that was supposed to convey traits of an effective team. The slide contained a circle with 16 lines coming out from it (like a sunshine almost). Each line had a trait on it, for example "committed", "conflict management", "self directed", etc.


The speaker then asked us "What traits are missing?" And my immediate reaction was to go to a place of "Seriously? You want me to read a list of 16 things and tell you something meaningful that is missing?"


So this is another fine example of Miller's Magic number, aka 7 +/2, where the human brain can only hold that many things. So by the time I get to item 10 out of 16, it's unlikely I remember the first.


Add to that, the ideas around the wheel aren't parallel ideas, so it's even more frustrating. If you are going to make a list like this, make them the same type of word - i.e. verb, noun, etc. Ideally they should be of similar type too, but that's harder to measure.


And finally, if you are going to use a visual to display your list, that's great, except that it needs to be one that actually organizes the information in a way that is useful. A circle of lines did not help organize the list. Maybe if he had grouped items together, there would have been 7+/2 items at the first level, with a few branches off each of those.


People did play along and shout ideas, but honestly, I thought the ideas overlapped with what he already had up there. Who knows.


This whole example is simply more justification for why we use visual models to represent information. With an appropriate model choice, we wouldn't have to remember 16 things, it might have helped force a parallelism, and finally it will help organize the information.

Live from BAWorld: Getting Your Stakeholders to Help You

Marie Bankuti from Tether Free Vision presented “Help Me Help You! How to Proactively Educate Your Business Stakeholders for Greater Project Success” this morning at BAWorld Boston. She discussed the typical challenges to project success that we see on projects and had the audience contribute. The ideas the audience came up with included conflicting interests, trouble articulating a vision of success, business users were cocky and thought they could do it without IT’s overhead, no time from the business, and pressure to hit dates and cannot focus on what is really needed in that time.

To summarize Marie’s suggestions:

1. Understand your stake, meaning vision or mission. Understand yours, your users’, your IT groups’, your and company’s.
2. Nurture your relationships, including understanding the people who you work with, their pains, and even what they do outside work.
3. Explain your process. Do this through things like case studies of it working or not, and just explaining why it’s needed.
4. Define expectations. Make sure it’s clear how you each will communicate, what the roles and responsibilities are, and what accountability there is.
5. Ensure credibility. This means things like disagreeing tactfully and with respect, collaborate, follow through on commitments, but in general model the behavior you seek from the teams you work with.

All in all, Marie gave a nice general overview of how to get teams to work with you.

Live from BAWorld: A Funny Start to the Day

A couple of us from Seilevel are representing at Project Summit & BAWorld Boston this week. So in typical form, we’ll be blogging live from BAWorld as the inspiration hits us.

This morning’s keynote talk was by Simon Cotter and it was on “The Power of Humor in the Workplace”. He’s a real estate/sales guy turned standup comedian. Now, I have to admit, it was a bit early in the morning for me to be laughing out loud, but I did find him amusing. It was a creative keynote. Frankly, I tend to find keynotes typically too broad to be applicable or by people who have big names but aren’t necessarily great at presenting. This guy actually kept me engaged for an hour and certainly handled the crowd well. His general point was about how to use humor to develop relationships. If you do that, people simply will want to work with you. And then he had more practical tips about how to do this if you don’t think you are funny - things like using safe jokes, quick wit, self-deprecation, and physical objects.

I completely believe in this concept. You know, I look forward to the funny people coming into the office every day. Who doesn’t love a good laugh? And you don’t have to be an overall comedian, just amusing sharing anecdotes with the crowd can make your coworkers chuckle and bond a little. In our training, we try to add some bits of humor to keep the students awake.

Anyway, there are 2 points I think are important in using humor – keep it appropriate (sexist and racist jokes are off limits) and keep it in check (we are here to get a job done, not just to be funny). Can you think of times where people were relying so heavily on their humor that they keep you from actually getting to the point? You just want to make sure everyone is engaged with your humor and move on to complete the task at hand.

Ok, so I feel like I should end this with a joke. Here goes:
A Business Analyst and a Project Manager walked into a bar....
Ok wait, unfortunately, I got nothing! Feel free to add some funny comments though.