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 »
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!
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 »
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.
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.
I’m writing for a typical client of mine—a software team of a half-dozen people, and the firm that pays them to do projects of a few months to a year in length. Let’s assume it’s you.
You want to get better at making software. You know that change is difficult and that there are no silver bullets. But you also know that you could be twice as good as you are now. (If you’ve never intentionally tried to get better at making software, I can almost guarantee it).
You’ve looked at “Software Process Improvement,” and your head is spinning. Where do you start? You may not even have a software development process. (Correction—you may not have an intentional software development process. The fact is, everybody has a process for everything they do, whether it’s making software or taking out the trash. It’s whatever they do now).
You want to make some simple (but not simplistic) changes, and you need to understand why they will probably work. (You will see below why this is important).
So you hire me and ask me what to do. Read more of this article »
Back at Berbee, when we were working overtime at a loss because we’d over-committed on a fixed-fee contract, the client told us, “You’re not bad estimators, you’re just bad negotiators.” More than 10 years later, I’m as convinced as ever that the foundation of success, or failure, is laid very early, and that it’s the result of a negotiation. I’ve spent eight weeks writing about this because I don’t think it’s getting the attention it deserves. There’s too much waste and stress in software development, and that hurts everybody.
- I see Sponsors driving Commitments that they think are in their best interests, but aren’t.
- I see Delivery Teams not negotiating well, or not even realizing they’re negotiating, accepting low-probability Commitments, and then getting blamed for the outcome.
This post summarizes the best advice I have today for both Sponsors and Delivery teams. It’s based on
- My own model of the process as Target > Estimate > Commitment
- Principled Negotiation, as described in Getting to Yes (1981), and
- 10 years of focused software project set-up experience—5 as a Delivery Team business analyst, estimator, and proposal writer, and another 5 as a consultant, primarily to Sponsors, as they evaluate, select, allocate resources to, and oversee projects.
Vocabulary: Target, Estimate, Commitment
A clear vocabulary can help you.
- A Target is a project concept of scope, schedule, and budget, usually posed by the Sponsor.
- An Estimate is the probability of a given scope, schedule, and budget being achievable for a given team and technology.
- A Commitment is an agreement by a Sponsor and a Delivery Team to achieve agreed-upon results (a Position), or follow an agreed-upon process that converges to a result that satisfies all Interests (a bigger target).
You can make things better just by treating these steps separately. You can learn more in:
If you want to read books about estimation, I highly recommend:
Or I’d be happy to help you improve your decision support—your estimates—and how they’re used.
Guidelines: Principled Negotiation
Not being a trained, experienced negotiator myself, I’ve drawn on Principled Negotiation (Getting to Yes, 1981).
- Separate People from Issues
- Focus on Interests, not Positions
- Invent Options for Mutual Gain
- Insist on Using Objective Criteria
Success Tips: Delivery Teams
You have to make it happen. Given enough time and the right tools, you can. But that means negotiating for the time and tools you need, starting from the first whiff of a new project. It’s too important to wait for someone else to do it. By then, expectations may have hardened.
Here are some things I try to keep in mind:
- “Separate people from issues.” Your Sponsor knows things you don’t, and they’re probably not stupid or evil. Their life isn’t all beer and skittles either. Use your problem-solving skills to understand their problems and help them solve them. Ask “Why?” (“Help me understand” is gentler and will work better).
- “Focus on Interests, not Positions.” If you want a life—no more death marches—ask. If you want to work with some cool new technology—ask. Your chances of getting one or two things you want most are probably better than you think.
- “Invent options for mutual gain.” Do your homework. Come prepared with reasons behind your estimates, and the amount of uncertainty in them, and how a change in scope or other inputs would change them.
- “Insist on using objective criteria.” Strongly consider adding metrics-based estimation to your tool kit.
- Refuse a commitment that estimation shows is a low probability. If you’ve done your estimation homework and have established a reputation for not being a slacker, you probably won’t lose your job. More likely, you will improve your reputation in the organization, as well as saving you and your buddies a lot of misery, and your organization a blown project.
- Do good work and expect your teammates to do the same. If you want to be treated like a professional, be one! Credibility really helps in a negotiation, and knowing your stuff, and being able to communicate it, builds credibility.
Success Tips: Sponsors
You are the man or woman who has to decide which software projects to do and at what level to staff or fund them, and then you’re accountable for the outcome being worth more than it cost. I believe your role is the more difficult one. Here’s my usual advice:
- “Separate people from issues.” Most programmers love to write software. (If they don’t, that’s a serious concern for you and their management, but you won’t cure it by cracking the whip). Programming is like an addiction. I know. The real issue is that there’s a lot of uncertainty in how long software stuff takes. There just is. (“Accurate Estimates and Other Myths” explains why).
- “Focus on interests, not positions.” What do you really need out of the project? Explain the “why” behind your targets, especially deadlines. Engage your Delivery team in coming up with different ways to get there. The larger the target that amounts to Success, the easier it is to hit.
- “Invent options for mutual gain.” You’re more likely to be the trained negotiator, plus you probably outrank them. Draw the information out. Ask them how they arrived at their estimates, not to beat them down, but to understand the cost and value space.
- Remember that a low-probability commitment, even a seemingly willing one (remember, they’re mostly not comfortable with negotiation), does not guarantee a successful outcome. It might make you look good now, and let you shift the blame later, but wouldn’t you come out even better if there was no blame to shift?
I welcome your feedback, be it good, bad, or ugly. I’m putting these ideas out there because they’ve worked for me, and I think I understand why, and I think they’ll work for you, too. If you agree, please try them, and forward them to others.
And if you need my help applying them, that’s what I do. Thanks for reading!
Next week, we’ll get on the “Requirements Merry-Go-Round” and find out how to spot big gaps nearly every time.
Seeing software project set-up as a negotiation helps you get what you really want, whether you’re a sponsor or part of the delivery team.
We’re on the third of four emails (subscribe at the right if you would like to get those) and articles about the four Principled Negotiation pillars from “Getting to Yes” (1981).
In Software Project Negotiation: Interests, not Positions, we examined how “Focus on Interests, not Positions” can move our thinking from a specific Scope, Schedule, and Budget (a Position) to a broader, and easier to satisfy, pair of Interests. As a Sponsor, your interest might be, “Maximize value within time and money constraints.” If you’re a Delivery Team member, your Interest might be, “Do quality work, learn something, and have a life.”
Last week, in Software Project Negotiation: Feature-Based Estimation, I explained that what people see, they talk about. Presenting estimates in terms of tasks like Testing and Coding encourages “negotiating the process.” But presenting estimates by Feature encourages adjusting the scope until the estimate shows a high probability of success within budget and schedule constraints.
But how do you feel about the estimate, regardless of how it’s presented? Read more of this article »
“Is it Project Manager, Architect, Tech Lead?”
This question was posed on Experts-Exchange.com, a resource I frequently use myself, and where I sometimes answer questions. Here’s a link to the dialogue, but if you don’t have a subscription, you won’t be able to see my answer.
For those of you without an EE subscription, here’s my answer, judged “Best Answer” by the questioner.
(I hate self-promotion, but I also have this food addiction that I just can’t seem to shake…) Read more of this article »