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 »

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.

Inconvenient Truths & Dirty Little Secrets

Posted by Robert Merrill on October 1, 2013 under Office Relationships and Politics, Software Development | Be the First to Comment

I’m giving a talk about software at Madison Area Business Consultants on Tuesday the 8th of October.

I believe that a lot of software projects get in trouble because both the producers (“Geeks”) and buyers (“Suits”) have mistaken beliefs about each other. There are Inconvenient Truths that are hard for both Geeks and Suits to face. Geeks and Suits also have their own Dirty Little Secrets—which they think they need to keep in order to stay safe.

I’ve listed all of them that I can think of, but I’d like to hear yours too.

Or, if you’re a Geek with a question about Suits, or vice versa, I’d like to hear it. Maybe I’ll try to answer it in my talk, and then on this blog.


Inconvenient Truths for Suits

You can’t tell what a computer, even a computer full of business software, does just by looking at it. You also can’t tell if it’s in a good state of repair or about to cease functioning. It’s not like a building, a backhoe, or a bass boat.

Geeks really don’t know how long something will take or how much it will cost, at least not with the level of accuracy you want or believe reasonable. They really don’t.

Most Geeks have a higher IQ and a lower EQ than you. That’s why they were attracted to computers. That’s also why the communication problems are your responsibility—you’re better equipped to figure them out.

Geeks interpret uncertainty as a problem to be solved.

If you can’t figure out how to speak a common language with Geeks, you need a translator. Fast, accurate translators are rare and expensive. Slow, inaccurate translators are easily found and even more expensive, just not right away.

Inconvenient Truths for Geeks

Suits really don’t know what they want, at least not at the level at which you want them to. They really don’t.

Suits have reasons for what they say they want and when they want it. They really do. It has to do with making money. If they fail at that, you will be out of a job. They just don’t know what’s possible or how to ask. They expect you to tell them, though they will act unhappy about it. It’s called “negotiation.” Many Suits think it’s kind of fun; some do it for a living. If a Suit has achieved significant rank, they are good at it—sometimes too good for their own good, and yours.

Suits interpret uncertainty as room for negotiation.

If you can’t figure out a common language to speak with Suits, you need a translator. Fast, accurate translators are rare and expensive. Slow, inaccurate translators are easily found and even more expensive, just not right away.

Your employer is primarily trying to make money, not provide you with employment or interesting information technologies to work with.

Inconvenient Truths for Everybody

Computers are extremely powerful, totally obedient in a way that seems outrageously passive-aggressive but isn’t, and they have extremely bad judgment.

There are no IT (Information Technology) projects. There are business-change projects with a major IT component. To get the benefits, the Geeks have to get the IT right enough, and the Suits have to get the business change right enough, too.

When people feel unsafe, they get angry or afraid, and that drains the blood out of their frontal cortices, making them stupid. This happens faster with Geeks than with Suits, because most Geeks have a higher IQ to begin with (and farther to fall), and Suits typically have a higher EQ and can better manage their emotions. Geeks don’t want stupid people setting their project schedules. Suits don’t want stupid people modifying their production website on Cyber Monday. So help each other feel safe.

People feel unsafe when they don’t share a mutual purpose and have mutual respect, they feel unsafe. So maintaining mutual purpose and mutual respect between Suits and Geeks is worth serious coin, as well as peace and happiness.

Dirty Little Secrets of Suits

Suits are even worse at estimating the benefits of IT projects than Geeks are at estimating the costs, but Suits are better at staying out of trouble over it.

Dirty Little Secrets of Geeks

Most software salespeople know surprisingly little about their products.

Geeks don’t actually know how to do most of what they do. They know where and how to ask the question, are able to understand the answer, and know how to try out the answer safely in case it’s wrong, and how to repeat this process until it’s right.

How I learned Function Point Analysis

Posted by Robert Merrill on September 28, 2013 under Business Analysis and Requirements, Estimation | Be the First to Comment

I consider Function Point Analysis one of my secret weapons for software process consulting and project estimation (even for setting up agile projects), and it makes me a much better all-around Business Analyst, too.

Here’s how I learned:

  1. Took a day of training, to get the big picture
  2. Joined IFPUG, downloaded the CPM, and read it all the way through (not in one sitting)!
  3. Muddled through some counts on my own, looking things up when totally stuck, but generally just doing the best I could
  4. Read the CPM again, making notes about all of the things I had done correctly and incorrectly
  5. Did a few more counts, and had a few evaluated by the person who trained me
  6. Registered for an IFPUG conference, a one-day CFPS prep course, and the CFPS exam,
  7. Studied the CPM thoroughly for several weeks, went to the conference, attended the one-day prep course (highly recommended), took and passed the exam
  8. Did a few more counts in the several weeks after the exam to reinforce what I had learned

I found the certification process an essential part of learning. It drives out a lot of sloppiness, and refines your sense of judgement about ILF and RET identification. That was the hardest part for me, and the one that also really influences the results. Thanks to the CPM team for putting those great examples right in the CPM!

It might be different if you worked with an experienced, presently or formerly certified counter who could evaluate your work and give you some coaching—the certification process might not then be essential. Either way, you need someone who knows what they’re doing to evaluate and correct your counting.

I let my CFPS lapse because I couldn’t justify the cost of maintaining it in my own situation—yours may be different. I keep up with the latest CPMs and review them occasionally, but it seems a lot like playing a game with complex rules, once mastered.

What’s Wrong with Business Analysts (or Agile / Lean coaches, or …)

Posted by Robert Merrill on September 14, 2013 under Business Analysis and Requirements, Change Leadership, Office Relationships and Politics | Read the First Comment

Julian Sammy, head of Research and Innovation at the IIBA® (International Institute for Business Analysis), compared finding a place to belong as a BA with romantic relationships. One of his conclusions from the latter was that the only common element in all of his unsatisfactory relationships was him. So he looked at himself and learned to be a better partner. He also found a good partner for himself in the process.

In “What’s Wrong With Us?” on LnkedIn, Sammy points to recurrent BA woes—not enough time, indifferent stakeholders, rank-pulling PMs, no time with sponsors, clients who won’t follow the process, etc., and asks, “What if it’s us?” Read more of this article »