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:
- Cost and schedule are often primary nonfunctional requirements; we’ve been trained not to think that way, and that’s a mistake.
- 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.
- 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 »
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.
- A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
- Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
- Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
- 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).
- 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™ :
- User Interface (UI)
- Data / Information, and
- Rules / Constraints.
- 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?
- 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.
- 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.
- For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
- For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
- 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.
- 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.
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 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!
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:
- Took a day of training, to get the big picture
- Joined IFPUG, downloaded the CPM, and read it all the way through (not in one sitting)!
- Muddled through some counts on my own, looking things up when totally stuck, but generally just doing the best I could
- Read the CPM again, making notes about all of the things I had done correctly and incorrectly
- Did a few more counts, and had a few evaluated by the person who trained me
- Registered for an IFPUG conference, a one-day CFPS prep course, and the CFPS exam,
- Studied the CPM thoroughly for several weeks, went to the conference, attended the one-day prep course (highly recommended), took and passed the exam
- 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.
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 »
Another thread on the IIBA® LinkedIn forum, this one called, “Disturbed by seeing a raft of costly projects with no projected ROI – thoughts?” (you might have to be a group member to see it) prompted me to write a reply that I didn’t want to bury in the LinkedIn forums.
The author, Lance Latham, reported that of 32 projects, only 6 had any cost-benefit analysis at all, and 4 of those only looked at the costs of doing the project in different ways. I’m not surprised. Here are some suggested reasons why this is, and a thought on why it’s not a complete disaster.
Fear of being wrong
If I’ll be punished for being wrong, and I know that early estimates of cost and benefit are likely to be wrong, I won’t create them, or I won’t publish them. If I think the project is a good idea, I’ll create just enough supporting documentation to get it funded.
Ranges and probabilities instead of hard numbers
If I’ve never learned, or am not comfortable, working with numbers that I know are imprecise but not meaningless, I will struggle to come up with them, especially if the scope is vaguely defined. And the scope is always vaguely defined at first.
The very process of refining the scope requires decisions about whether a particular outcome is in scope or not, and that involves some kind of cost-benefit analysis of the thing in question. Or it at least means a guess at the cost of the thing, and a comparison of the uncertain total cost of all the things in my scope basket with a vaguely known budget. (The budget itself is subject to negotiation.) And at this point, the outcome or feature in question is itself only vaguely defined. It’s like a nested Russian doll of chicken-and-egg problems. How do I deal with that?
Organizational natural selection
People who are good at working with nested chicken-and-egg problems using uncertain numbers don’t seem to climb the corporate ladder to the height where they’re approving major projects. Or they lack other traits which are needed to keep from falling (or being pushed) off the ladder. Or they don’t want to climb the ladder at all.
But maybe it’s not the end of the world
If we believe Jonah Lehrer (“How We Decide”), maybe we shouldn’t be surprised. When analyzing complex decisions, we reach the point of diminishing returns relatively quickly.
Of Latham’s 32 projects, how many were turning out to be not worth the cost (the Ultimate Non-Functional Requirement)? How many projects that were shelved in favor of the 32 would have been winners? How much would additional analysis have helped?
I sometimes advise, but I’ve never ascended to the heights where I approve major projects. But I’ve watched (and been downwind). Here are my impressions.
- We do two levels of initial cost-benefit analysis: a) none that I can see, or b) way more than the uncertainties in the numbers justify.
- We’re not quick enough to radically re-scope or even cancel projects based on their actual progress.
London Transport passengers are exhorted to “Mind the Gap” between the platform and the train. The gap’s dangerous.
Likewise, I exhort business analysts to “Mind the Gap” between the Stated Requirements and the Implied Requirements. If you don’t, you’ve doomed your team to scope creep (more like scope avalanche) and probably a lot of budget and schedule pressure, and it won’t be the sponsor’s fault.
Minding the Gap—getting the implied requirements close enough—is the difference between a requirements order-taker and a Business Analyst.
So, how do you come up with requirements that no one’s stating?
I got the idea from Doug Rosenberg’s & Kendall Scott’s “Robustness Analysis” and Ellen Gottesdiener’s “Multi-Modeling.” I invented the Requirements Merry-Go-Round© as a way to explain it to others. I’ve since found it useful for the other things I’ve been writing about.
The original Merry-Go-Round© had only two horses—Function and Data.
You start with Function—say Use Cases or User Stories. Imagine some (very simplified) software to help pilots with flight planning and navigation. Functional requirement elicitation turns up:
- As a Pilot, I can select my departure, arrival, and alternate airports when preparing my flight plan.
- As a Pilot, I can enter the departure runway when I’m given my departure clearance.
- As a Pilot, I can enter the arrival approach to the arrival airport, and the assigned runway for landing at the arrival airport, when I’m assigned them by the air traffic controller.
- As a Pilot, I can select Voice Mode and the software will read me the waypoints, altitudes, and speeds for approach and landing.
Now, you head off to your lonely analyst’s garret (if you’re just learning) or let your Subject-Matter Experts (SMEs) take a break (if you’re a rock star) and head around to Data.
Everyone who makes software learns to look at the functional requirements for nouns: Airport, Flight Plan, Departure Runway, Arrival Approach, and Arrival Runway (I left out a few to keep it simpler). Then, sketch a logical data model. Then, re-convene your SMEs for some more elicitation.
The crafty BA will have noticed the sloppy use of sometimes “enter,” sometimes “select,” and found out that there are lists of Airports, and each Airport has a list of Runways, and each Runway has multiple Approaches.
Then, for each entity on the data model, ask three simple questions:
- Where do these data come from?
- What are all the possible uses for these data, and by whom?
- When and how are these data disposed of, and by whom?
You’re checking for CRUD—Create, Read, Update, and Delete. Data have to come from somewhere, and be read by someone.
The Pilot enters the Flight Plan. That’s one of the stated requirements. And s/he selects Airports, Runways, and Approaches. This we know.
But where do the lists of Airports, Runways, and Approaches come from?
“Oh, I guess we’ll need screens to enter and edit them.” Inspired by Ruby on Rails, modern application frameworks in many programming languages, and modern programmer tools like Microsoft’s Visual Studio now have “scaffolding;” when you create a data entity, it just creates plain-vanilla versions of these screens for you.
“We get them in a file from the government.” I’ll leave it to you to imagine what you would need to find out next!
“That’s a good question. I was hoping you could tell me. I’m just the marketing guy—I’ve been going around to air shows, talking to pilots about what they would like our software to do.” Someone, maybe you, now has a research project that could invalidate the feasibility of the whole project. Disaster averted.
To summarize, here’s how to Mind The Gap and find the requirements that no one’s mentioned:
- Elicit the functional requirements—the ones that are driving the project
- Infer a logical data model from the nouns in the functional requirements
- Infer the implied functional requirements from the entities in the logical data model using the CRUD check (Create, Read, Update, Delete
You’re not done, though. Your implied functional requirements are just a first draft for another round of elicitation. Involve additional subject-matter experts (SMEs) and expect a flow of additional information. If the implied requirements touch another part of the organization, you may have a new senior stakeholder. Get the sponsor’s help in developing that relationship and working out a potential change in the business requirements as well.
You still might not get a bonus though. Disaster averted is disaster disbelieved.
“You can get on anywhere you like, but you have to go around at least twice.”
So far I’ve been emphasizing where to get on the Requirements Merry-Go-Round©. Start with Function if it’s up to you, but if the Subject-Matter Experts (SMEs) you’re working with want to get on at Data or User Interface, let them.
(I’ll come back to Business Rules in a future post because I need to find some misplaced material from the last WI BADD® first.)
But the first trip around is just the beginning. Like any other kind of research—scientific, historical, journalistic—requirements work has two main activities, which the BABOK® calls Elicitation and Analysis. Elicitation is about sources. You’ve read about how to help your subject-matter experts (SMEs) talk about Function, Data, and User Interface, and how to use one to get them talking about the others. That’s Elicitation.
Analysis happens when you go back to your lonely garret and try to make sense of it all. It’s the second and third trip around the Merry-Go-Round. On the second trip, I “freeze-dry” everything, by transcribing and annotating my source material. This sounds fancy but it isn’t. Read more of this article »