The Requirements Merry-Go-Round© is one of those pictures that I started drawing on whiteboards before I gave it much thought.
I found myself drawing this picture when:
- I was explaining to software project sponsors and subject-matter experts about how the development process would start, or
- I was training people how to communicate with each other about what we wanted to make a computer do, i.e. how to do Business Analysis.
Before the Merry-Go-Round, my mental model of the requirements process looked like this:
I ran into two problems when trying to do requirements this way:
- People sometimes refused to start at the beginning, and
- The resulting requirements turned out to have a lot of gaps, leading to cost and schedule overruns and “death march” projects.
I would interview someone from Marketing, and they wanted to draw (or already had drawn) screens. Web designers always wanted to start with screens, or get there as soon as possible.
Then I would interview a subject-matter expert from Operations, and as often as not they wanted to talk about data and maybe functions, or rules. (I’ve recently added the rules). But if there was an old system, they would show me screens.
Now, it’s both rude and ineffective to make people communicate my way, so I learned to let them lead and talk about the element they wanted to. If it’s screens for them, we talk about screens. I infer what I can about functions and data. Then, as the interview goes on, I start asking questions about the other elements. “What else do you do from this screen?” “What information does the system remember when you save this screen.” (Say “information,” not “data.” It’s less likely to put people off. For the same reason, I usually say screen, or form, or report and not user interface unless they’re already saying user interface).
To explain why I am asking about these other things, I draw what I started calling the Requirements Merry-Go-Round©:
I explain it like this:
“We need to understand all these things to make the software, so that’s why I’m asking about them. We can get on the merry-go-round wherever you want, but we have to ride all the way around at least twice to really understand this project.”
Over the next few weeks, I’ll write about how I help people talk about each element, and finish with how I use the Requirements Merry-Go-Round© concept to detect and fill gaps, early and quickly.
Syed Raman asked the IIBA LinkedIn group,
“Which way should i cover? Vertically ? Or horizontally? I have to meet my deadline..!!!” — most of the BAs face this part …Need some expert’s opinion.
If you can’t negotiate an extension, you have to perform triage. “What will cause the people downstream the most problems if left undone?” My starting answers, not knowing anything about the context, are:
- Requirements with a high architectural impact, and
- Requirements that are essential, but implied
If I don’t provide adequate guidance about #1, they are more likely to make a bad architectural decision, and those can be time-consuming and costly to fix later.
#2 might need some clarification. Suppose the stated requirements call for the system to provide information about X. But there are no stated requirements for putting information about X into the system. But without information about X, the primary requirements can’t be met. I should be asking, “Where does my system get information about X?“ That might uncover a whole interface to another system, or a set of input screens, and a team that will use them, and a whole new stakeholder! A gap this big could totally blow a schedule that’s probably already too “aggressive.”
That’s what I do. And when I get some time, I go upstream and find out where the schedule came from that didn’t allow me the time to do my job in the first place. That’s how I got involved with estimation and negotiation, a vital BA responsibility, IMO.
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.
One of my first posts was Who I am Not.
So, “You annoy me—You’re Hired!” on StaffingTalk.com immediately caught my eye.
The premise is that you should hire people who aren’t like you, even to the point of rubbing you the wrong way, if you want to build great teams. (I would add that they must still be trustworthy, competent, of good character, and otherwise worthy of respect). Now, getting that team to jell—getting through the Storming stage of Forming, Norming, Storming, and Performing—might take longer and be more challenging, but the results will be worth it. And if the team’s mission is a worthy one, jell they will. And when they do, they will totally kick.
So, if you have a software-related mess, or better yet, you don’t want another software-related mess, listen to Uncle Albert (who was in fact just about the sharpest knife in the drawer):
We can’t solve problems by using the same kind of thinking we used when we created them.
I promise I’ll try not to annoy you. But helping you straighten out your software problems, and prevent them recurring, will my top priorities.
I hope this helps you make better decisions for your organization, whether they involve me or not.
And I think I just gained some additional insight into my sales problem.
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 »
In Software Project Negotiation: Interests, not Positions, I introduced the idea that setting up a software project is a form of negotiation. 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.
Now let’s look at how a simple change in how we prepare and talk about software project Estimates can harness the power of two principles from the famous negotiation book Getting to Yes, namely
- Invent Options for Mutual Gain, and
- Insist on Using Objective Criteria
Feature- vs. Task-Based Estimation
We all know how to tackle a big project—break it down into a series of little ones. Read more of this article »