Greetings from Business Analyst World Chicago

Posted by Robert Merrill on November 16, 2014 under Business Analysis and Requirements, Estimation | Be the First to Comment

I’m really here! I’m presenting one of my favorites, “Room to Breathe: The BA’s Role in Setting Realistic Budget & Schedule Estimates,” at Business Analyst World Chicago.

My goal is to get Business Analysts to consider taking ownership of early-lifecycle effort (cost) and schedule estimates. Here’s why:

  1. Cost and schedule are often primary nonfunctional requirements; we’ve been trained not to think that way, and that’s a mistake.
  2. Unrealistic cost and especially schedule expectations remain a primary cause of project failure; by the time a Project Manager is on scene, these expectations have often hardened.
  3. The Business Analyst role is becoming more holistic and value-focused, and it’s impossible to assess value without assessing cost and schedule.

I’ll also be teaching an early-lifecycle estimation technique that can be used even when very little is known. And I’ll be introducing some presentation and negotiation skills that focus the conversation on scope, where it belongs.
Read more of this article »

The Bad Boss Paradox, and an Idea for a Cure

Posted by Robert Merrill on September 10, 2014 under Office Relationships and Politics, uFunctional Values | Be the First to Comment

As an Upper Midwesterner born in Texas who found his way home as soon as he could, I love Garrison Keillor’s interesting, witty observations. “Norwegian bachelor farmers. They don’t reproduce. Why are there still so many of them?”

In Are You a Bad Boss? Here’s How to Know, Naomi Karten begins by saying that if reading articles about how to be a good boss were all it took, there would not be so many articles about how to survive a bad boss. Naomi goes on to cite what I have learned as the First Rule of HR; people do not quit jobs; they quit bosses.

Garrison Keillor might say, “Bad bosses. They’re easy to spot and do so much damage. Why are there still so many of them?” Call it, “The Paradox of the Bad Boss.”

Maybe it was Naomi’s article, or maybe it was just time, but tonight a penny dropped. Maybe there is a simple cure. Read more of this article »

7 Top Traits of Star Employers

Posted by Robert Merrill on August 25, 2014 under Office Relationships and Politics, Software teams | Be the First to Comment

I just read 7 Top Traits of Star Employees on inc.com.

They are:

  • Happiness
  • Creativity
  • Hustle
  • Honesty
  • Flexibility
  • Passion
  • Confidence

Hard to argue with these. But which is more important, that a candidate have them on interview day (assuming you can tell), or that an employee have them after a year working for you?

Every senior leader has beliefs about nature vs. nurture. If it’s nature, star employers hire stars. If it’s nurture, star employers develop them.

The author of the inc.com article writes as though it is more nature than nurture. Is Mr. Hendricks right?

Here’s a straightforward assignment for your HR people.

  1. Evaluate candidates for these traits.
  2. Evaluate employees for these traits after a month.
  3. Evaluate remaining employees for these traits after a year.

Here’s how to interpret the results:

No change or increase in first month Decrease in first month
No change from first month to first year You win!. It’s nature, and you’re good at hiring! You lose. It’s nature, and you’re seeing the traits when they’re not there.
Increase from first month to first year You win!. It’s nurture, and you’re developing (or rescuing) stars!
Decrease from first month to first year You lose. It’s nurture, and you’re dousing stars, even if you were hiring them to begin with.

My Typical Business Analysis Pattern

Posted by Robert Merrill on January 16, 2014 under Business Analysis and Requirements, Requirements Merry-Go-Round | Be the First to Comment

I started doing “business analysis” before I knew there was such a thing. We called it “Getting the requirements” or “Making sense of the requirements” or (often) “Who came up with the requirements (and the schedule)?”

I read books, went to conferences, thought a lot, and tried things out.  A decade later, here’s how things typically go, when the client and I jell as a team, and I do it right, and it works.

By “works,” I mean the new (usually software-enabled) business process has been running for a while, and all stakeholders (including the makers and the person who paid the bill) are saying, “I’m glad we did that. That was worth more than it cost. Let’s do another one!”

So, here’s the candidate pattern.

  1. A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
    1. Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
    2. Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
  2. Using questions and active listening, I help my would-be sponsor back up to Who and Why? Who’s going to use the new or changed product or process? Why would they want to do that? Why would you want them to do that? (Be careful with literal “Why.” It can feel confrontational).
  3. I then lead an examination of possible Whats that might satisfy the Whos and Whys, from four perspectives, using another pattern, the Merry-Go-Round™ :
    1. User Interface (UI)
    2. Function
    3. Data / Information, and
    4. Rules / Constraints.
  4. Most often from the Rules and Data, I infer additional Whos affected by the proposed What. Often they are not clearly beneficiaries. What additional changes, either part of the What, or alongside it, are needed to make them whole?
  5. I then see that an Estimate of cost and timeline is prepared, independent of the Target from #1. Target-Estimate-Commitment is another pattern I’ve observed and use.
  6. If there’s still too much uncertainty regarding the cost and benefit of the What to proceed, I then recommend where we should “buy a vowel” (a metaphor from the decades-long American game show, “Wheel of Fortune”), typically in one or more of Team, Technology, and Requirements.
    1. For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
    2. For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
    3. For Requirements, that means further elicitiation and analysis of those portions of one or more of UI, Function, Data, & Rules where the cost / benefit sensitivity is greatest.
  7. I then provide decision support for a Commitment regarding the Essentials, Value-adds, and Delighters (Kano model) of the What, helping tie those back to Whos, their goals, and the associated costs and benefits (from the Estimate, with associated ranges and probabilities).  I encourage variable-scope thinking. Resources usually are more tightly constrained than scope, and those constraints need protection from the remaining uncertainty (and there’s always more uncertainty than we would like, particularly if it’s potentially a high-impact What).

I have a typical Implementation pattern too, but that’s Out of Scope for now.

That’s how Business Analysis usually goes for me. Like all potentially robust patterns, it’s come from observation, not prescription. I didn’t read or decide, “This Is How It Goes.” Rather, I’ve observed, “This Is How It Usually Goes When It Works Well.”

I hope this candidate pattern works well for you, too. I believe it’s only a real pattern if it’s worked three or more times for three or more people. Please share your stories!

I’ll add two pictures when I get the time. That might make the pattern easier to see.

Should Business Analysts be responsible for cost / benefit along with requirements?

Posted by Robert Merrill on January 12, 2014 under Business Analysis and Requirements, Estimation, The Quantitative BA | Be the First to Comment

If you’re too busy to read this, please complete the 10-question survey by Friday 1/17/2013 instead!


Practitioners of Business Analysis, as represented by the International Institute for Business Analysis® (IIBA®), are following in the footsteps of Project Managers and the Project Management Institute (PMI®). BAs want to expand and professionalize their discipline. They believe, and I agree, that there’s more to Business Analysis than developing software requirements.

What I see the IIBA® not yet emphasizing, and Business Analysis practitioners not embracing, is perhaps the highest-impact expansion of the Business Analysis role: Cost / Benefit analysis of concepts, before they even become projects.

Expectations of implementation cost and schedule form early. By the time a project is approved and a Project Manager assigned, these expectations are hardening. The result is often an “aggressive” schedule, with all of the associated downstream problems I present on SlideShare in Room to Breathe: The BA Role in Project Commitments (my 2010 presentation at WI BADD®).

As the first person “on the ground” from the delivery team, the BA is uniquely positioned to help shape expectations of cost, schedule, and benefit, as well as requirements, into something achievable. Estimation, business cases, and cost / benefit analysis are hinted at in the BABOK®, but they are not emphasized. Further, many BAs limit themselves to the subjective—requirements elicitation and analysis—and leave the numbers in a vacuum. Nature abhors a vacuum, so numbers—often optimistic cost and benefits to get the project approved—appear from somewhere, and become a check that the delivery team has to cash.

I’d like to revisit this topic for my 2014 presentation at WI BADD®, and I’m seeking feedback everywhere I can. Please complete my survey by Friday 1/17/2014, and comment below.

Should BAs be involved in creating these early numbers? Do they have the skills and knowledge to do so effectively? Would it help their careers?

If you want to go into more detail, please complete my  Project Estimates and Cost / Benefit analysis.

I’d like to propose and give the most useful talk I can at WI BADD®, and my proposal has to be in by the 20th. Thanks!

A Fatal Flaw in Big Agile?

Posted by Robert Merrill on December 19, 2013 under Agile Methods, Estimation, Uncategorized | Be the First to Comment

In Ways to Implement Agile Without Breaking The Bank, James Sullivan explains how Agile practices can be applied, piecemeal, to yield benefits even on big projects, where one of the Big Agile framework like SaFE or DAD might be called for, but not affordable. Though I’ve catalyzed several Agile adoptions, I’m not yet that familiar with these Big Agile techniques. So I read the article with great interest, to understand how people like Mr. Sullivan are thinking. I believe I have a pretty firm grasp on why Agile works, and therefore, what its Load-Bearing Walls are. So I read, checklist in mind, looking for what’s not there.

  • Iterative development, with regular reviews of running software. Check.
  • Control of technical debt through automated testing, integration, and deployment. Check.
  • Frequent evaluation and adaptation of the process through structured retrospectives by the people doing the work. Silence, but maybe that’s just an oversight. A practitioner could add that later without rocking the boat too much.
  • Variable overall scope, based on observed progress. UH-OH.

Read more of this article »

Software Selection–An Overview of the Tall Nails(c) Process

Posted by admin on December 12, 2013 under Business Analysis and Requirements, Software & Integrator Selection | Be the First to Comment

A video called The Vital Importance of Software Selection to the Enterprise by Gabriel Gheorghiu, available on Technology Evaluation Centers, inspired me to describe a few powerful adjustments to the RFP / Demo / Negotiate / Implement process. I have a white paper about Tall Nails© in the works, but meanwhile, I’d like to get some ideas out there.

Do your business-value homework first

It seems obvious, but it’s indeed critical to start with your own requirements. What will remove constraints on your present business processes, or enable whole new ones? Vendors will gladly help, but your “requirements” might come to resemble their product’s feature set. But will those make you money? Only you can know that, so do your homework.

Evaluate the partners at the same time as the vendors and the software

Mr. Gheorghiu makes an excellent and often-overlooked point: most software you select and purchase (license) will be installed, configured, loaded with data, perhaps customized, and put in service by one of the vendor’s partners. It’s common practice to select the vendor and software and then, weary and worn from that process, accept the vendor’s recommended partner. I suggest evaluating partners and vendors together. Unless there are critical features (Tall Nails©) lacking, I would rather have an awesome partner and the second-best software.

Focus on the Tall Nails©

I agree with Mr. Gheorghiu that demos are critical, and that you must provide a script to see what you need to see. He suggests designing the script around the high-priority requirements. I take that one step further. Design the script around those particular high-priority requirements that not every system is almost sure to satisfy—what I call the Tall Nails©.

Another good piece of advice, and I can’t remember where I heard it (thank you, whoever you are!) is focus your evaluation, especially demo scripts, on business processes, not just features. Write out scenarios. Provide your own data. Ask to see how the features work together to support that process, and be prepared to learn from the vendors and partners. They may have things that are better than you imagined! Your business-driven requirements homework will have prepared your minds to know those when you see them.

Don’t Overload the Vendors and Partners

This occurred to me when a vendor flew in four people for an early presentation of their software. I thought, “If they do this with every prospects, that’s a lot of cost-of-sales, and the people who actually buy have to cover that for all of the others who didn’t.“ It’s tempting to look at pre-sales as “free consulting.” But someone pays for it—those who actually buy their software.

It’s also tempting to make vendors jump through serious hoops during the RFP process. Tightly constrain their responses, ask everything you can think of, and give them a very short window in which to respond. You want to find out who’s hungry and responsive, right? Well, yes, but what you really want is the strongest software and best implementation, not the world-record RFP-response-writers.

By all means ask the tough questions that you need to make a good decision, but don’t make them jump through unnecessary hoops. What if the best candidate for your solution is not even in the running?

Start the Change Process at the Same Time

New software systems change processes. The payoff doesn’t come when the new software goes live. It comes when it’s in effective use, opening a new sales channel, or increasing throughput and decreasing error rates on a process that makes you money. Get the organization involved, early, in the process of change. Present the vision of a better future for the people that will benefit. Address the concerns of those whose jobs will get harder, or be eliminated, and make them whole. Even though you can’t give them details, make sure training and support know what’s coming.

I highly recommend Fearless Change by Manns and Rising.

Finally, Get Help (You Will Eventually, Regardless)

Big companies are selecting software all the time, so they have the people and the know-how (I hope you’ve gotten some good ideas all the same). But they still might need extra heads and hands to avoid skimping, and an outsider’s objectivity to help mitigate the effect of politics (personal preferences that don’t benefit the organization).

Small companies face an even greater challenge, because software selection might be something they only do every three to five years. Proportionally, the investment (and risk) might be even larger. Plus, with a smaller staff, there’s just less slack in the system to take on the extra work of developing requirements, screening vendors, setting up demos, interviewing and evaluating partners, closing the deal, and overseeing the implementation and process changes. That assumes a small organization even has the know-how on staff to do all these things, even if they had the time!

So, get help. If you don’t get help with your software selection and implementation now, you’ll wind up getting help for your stress-related illness or troubled relationships resulting from an insane project later!

 

Inconvenient Truths & Dirty Little Secrets, Part II: MABC Speaks

Posted by Robert Merrill on October 9, 2013 under Office Relationships and Politics, Software Development | Read the First Comment

I gave my presentation, “Inconvenient Truths & Dirty Little Secrets: What Suits and Geeks Wish the Other Knew (or Felt Safe to Say) about Software,” at Madison Area Business Consultants on 10/8/2013.

During my Q/A session and from my follow-up survey, I received the following. As I blog about them, I’ll add links. Subscribe to my newsletter and be notified.

Inconvenient Truths for Suits

Dear Suits,

  • IT won’t solve all problems—it’s a tool, among others; planning.
  • How can I help you, help me, to help you?
  • Scope needs to be managed, and all of the system needs to be tested even if we only changed a little bit of it.

Inconvenient Truths for Geeks

Dear Geeks,

  • The business process always has exceptions.
  • How can I help you, help me, to help you?
  • The business moves faster than you do.

Dirty Little Secrets of Suits

We Suits wish it was safe to say:

  • We don’t know everything.
  • We don’t really understand the business problem completely.
  • We generally ignore or work around things requested by people we don’t like.

Dirty Little Secrets of Geeks

We Geeks wish it was safe to say:

  • We really don’t know how the entire system works, or will work.
  • We generally ignore or work around things requested by people we don’t like.

Your “People Problems,” and How To Solve Them

Posted by Robert Merrill on October 3, 2013 under uFunctional Values | Be the First to Comment

For all its geekiness, software is an intensely “people” business.

Ask programmers to tell horror stories and they will indeed talk about irreproducible severity-1 bugs and traffic spikes that took down their website.

But more of the horror stories have to do with the insane scheduler, the requirements yo-yo, the scope creep (it’s also a noun, you know), and the User From The Nether Regions.

Unfortunately, we who are attracted to software development in the first place have “people problems” of our own. We’re quick to “flip the bozo bit.” We get into religious wars over the One True Coding Style (or text editor—are those days passing? It’s vi, just in case you’re wondering).

Once you recognize that software is a people problem (and thought leaders in our industry have been writing about it for years), you still have a problem. Advice seems to fall into two categories:

  1. “You just have to know how to talk to them.” Understanding motives, dialogue, and all that. I posted this because of an article called How To Cope With Troublesome People on AgileConnection.com. I recommend Crucial Conversations: Tools for Talking When the Stakes are High because it helps us all with our inner game—how to avoid dropping into lizard-brain Fight-or-Flight and triggering a destructive feedback loop when things get tense.
  2. “When the going gets tough, get tough.” These can be helpful and constructive, like Cloud & Townsend’s Boundaries (it speaks Christian-ese at times, but you don’t have to be a Christian to use the principles and techniques). Or they can be systemic, like The No-Asshole Rule; great if you’re the CEO, but among the rest of us it encourages bozo-bit-flipping because we can’t do anything about the subject. And then there are various books about winning at office politics, which remind me that, “The Winner of The Rat Race is Still a Rat.”

I believe it’s always best to start by controlling your inner game (a learnable skill) and striving for dialogue, but I’ve also encountered people who, over time, demonstrated by their actions that they weren’t the least bit interested in me or my &%@! dialogue. What to do?

Enter Alan Godwin’s How To Solve Your People Problems, with a map of the swamp.

  1. Conflict is inevitable
  2. Conflict can be either good or bad
  3. How we engage has a significant impact on whether conflict is good or bad
  4. The rules of engagement for good conflict depend on whether the other person is exhibiting reasonable behavior or unreasonable behavior.
  5. Reasonable behavior consists of humility, knowledge, awareness, responsibility, and reliability. (Dr. Godwin explains these very clearly). To the extent these are absent, you are dealing with a person who is acting unreasonably.
  6. Start with your dialogue skills, from Crucial Conversations or similar. That’s what How To Cope With Troublesome People recommends, too. If you get a measure of reasonableness back, use your skills to stay in dialogue, even if things get tense. Meet Reasonableness with Dialogue.
  7. But if you get sustained Unreasonableness back, in the form of Drama (there are four–I won’t spoil the surprise), then switch from Dialogue to Boundaries. Meet Unreasonableness & Drama with Boundaries. In extreme cases, Boundaries may have to be in the form of Lawyers, Guns, and Money.

Dr. Godwin’s book is also from a Christian perspective, but like Boundaries, you don’t have to be Christian to apply the principles. And don’t be too quick to flip the bozo bit.