In the Society for Professional Marketing Services (SMPS) Wisconsin Chapter newsletter, Melissa Opad writes, “Picking a web developer is like picking a spouse…While that’s not exactly true (at all), it is a very important decision that will have great implications on the success of your website project.” Ms. Opad then goes on to list 10 Steps to Take Before Hiring a Web Developer.
Ms. Opad has a lot of good advice, but there are also a few things that I think are a lot more like choosing a spouse than writing a tight Hollywood-style pre-nup.
Based on my experience as a web application (primarily eCommerce) developer, web/software project definer and estimator, and consultant to firms hiring outside help for their web and software projects, here’s my take on Ms. Opad’s 10 steps: Read more of this article »
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.
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 »
Just keeping Targets, Estimates, and Commitments (TEC) separate can go a long way towards setting software projects up for success. But getting from Estimate to Commitment is still tough. Sponsor(s) and Developers have to agree on what to do and how to do it.
(Briefly, Sponsors are those who pay for software development and are responsible to their organization for its benefits. Developers are those who make the computers do something new on the Sponsor’s behalf).
Especially when it comes to scope, schedule, and budget, this has the feel of Negotiation. When Sponsor and Development organizations are different, especially if they are different business entities, the Estimate-to-Commitment conversation is most definitely a Negotiation.
Guidelines for successful negotiations are well established, originally in Fisher and Ury’s long-running business best-seller, Getting to Yes.
- Separate people from issues
- Focus on interests, not positions
- Invent options for mutual gain
- Insist on using objective criteria
In this series of posts, we’ll look at each principle as an aid to get from Target through Estimate to a Commitment that, at the very least, is achievable—that will deliver working software every time.
A lot of problems can be avoided if both parties admit two things, from the heart:
- Failure may not be an option, but history shows it’s always a possibility, and
- Except in the most toxic of political environments, a software project that fails to produce any software at all is not an outcome either Sponsor or Developers would choose.
Ask most people what success means and they’ll say, “Promised scope delivered, on time and on budget.” So that’s where most software project set-up negotiations focus—Scope, Schedule, and Budget. But according to Principled Negotiation, that’s a Position. What if we instead focused on Interests?
- The Sponsor wants software and an accompanying organizational change that’s worth more than it costs,
- The Developers want the opportunity to do quality work, improve their skills, and still have a “life” if they so choose.
That’s a bigger target. There are typically many Positions—combinations of Scope, Schedule, and Budget—that will satisfy both parties’ Interests. A solid, transparent estimation process will tell you, even with all of the uncertainty on both the cost and benefit side, the region where they are found. At least at the start, aim for the low-risk middle of that sweet spot, and only start optimizing when actual progress shows that at least small-s success—an outcome that satisfies both Sponsor’s and Developers’ interests—is in the bag.
Aren’t I Just Taking the Developers’ Side?
I’m guessing that the Sponsors among my readers are thinking, “You’re a Developer, and it shows. You’re taking the Developers’ side!” You’re right, and I am, directly. But indirectly, I’m taking your side, too. Dear Sponsor, how would you feel if you could:
- Take the possibility of big-F Failure off the table, and
- Be certain of at least a minimal return on your investment?
“But if I don’t negotiate maximum functionality, aren’t I essentially leaving money on the table?” Maybe, but only if:
- Your projects consistently bullseye the Negotiated Scope, Schedule, and Budget, and
- You never say, or hear, “Now that it’s in production, I wish it could do X, instead of this Y feature we never use.”
If those two things are true, forget whatever I have to say and get back to work. (And, would you be willing to meet with me and let me in on the secret?)
But chances are, you will be better off if you (and the Developers) focus on Interests instead of Positions when setting up software projects, and choose a way of working that lets you optimize as you go.
In TEC project set-up, a Commitment is accepted accountability for an outcome. The Estimate, like “25% probability of adding Shop-With-A-Friend by fall peak,” supports (or doesn’t) the Commitment decision.
Commitments should follow Covey’s “Win/Win or No Deal” rule. Pressure to do otherwise is based on mistaken beliefs or is self-serving, and is not in your organization’s best interest.
When Estimation shows the proposed Commitment—a Target—has a low probability of being met, the Win/Win approach is to modify the proposed Commitment to increase the probability.
I suggest “Maximum Value, subject to Schedule and Budget,” instead of fixed scope.
Part 1 | Part 2 | Part 3 | Part 4
On 9/7/2012, Esther Derby reminded me of something when she wrote, “Focus on ‘commitment’ is a poor proxy for focus on results.”
The Commitment I’m talking about is an achievable Commitment to deliver a result, not Trying Really Hard.
In Target-Estimate-Commitment (TEC) project set-up, an Estimate is the probability of an outcome—Scope, Schedule, Resources. “The probability of adding Shop-With-A-Friend by fall peak with the three people available is about 25%.”
An Estimate is not a Commitment. An Estimate is decision support. Numbers without probabilities aren’t Estimates.
But if you answer, “Give me an estimate!” with a probability, brace yourself! You might not be playing their game. If they’re negotiating for themselves and not deciding for the organization, and you commit at 25%, they win and you lose either way. The organization only wins 1/4 of the time.
Part 1 | Part 2 | Part 3 | Part 4