Red flags

Business developer can't adequately describe any red flags in leads.

Your busi­ness devel­op­er should be well versed in recit­ing the ABCs of client risks and rewards. If your busi­ness devel­op­er can’t rec­og­nize obvi­ous warn­ings when speak­ing with a new lead, it’s time for some PM support. 

The fix

Try hav­ing a sit down with your sales team and work­shop some red flags togeth­er and how they might impact the entire project. At the very least, ask to be brought into all sec­ond calls with sales leads so you can ask open-end­ed ques­tions while jot­ting down all the flags you notice so you can chat with your busi­ness devel­op­er about them after the call. Bring up past exam­ples of how red flags impact­ed projects and profitability.

Business developer can’t determine if the lead aligns with your organization’s goals or mission.

Watch out: to effec­tive­ly vet incom­ing leads, your busi­ness devel­op­er should implic­it­ly know the orga­ni­za­tion’s mis­sion and goals and know whether or not that sales lead aligns with them. 

The fix

It might be time to do a group sit down and clar­i­fy where the com­pa­ny is head­ed, and what the min­i­mum require­ments to work with your org should be.

Business developer doesn’t bring in the PM after the first or second call to help vet the incoming lead.

If you as the PM only find out about a project the day it hits, your team needs to tight­en up its hand­offs. Leav­ing the PM (and the peo­ple doing the work) out of the sales process results in projects that are scoped at a frac­tion of the true size and red flags and com­plex­i­ties that get ignored or left out of the vet­ting process.

The fix

We high­ly rec­om­mend bring­ing in a PM (or sim­i­lar role) ear­ly in the sales process to help vet incom­ing projects and leads to pre­vent scope inac­cu­ra­cies, time­line con­flicts, and unnec­es­sary risk. They are valu­able at see­ing the macro and micro views and can help sup­port the align­ment of your com­pa­ny with its own busi­ness goals.

The business developer diminishes or overturns the PM's or team’s concerns about the client or project

As a PM, your job is to sniff out risks that could help or hurt your project. If your busi­ness devel­op­er won’t take your or your team’s con­cerns seri­ous­ly, this is a pret­ty seri­ous oper­a­tional break­down in trust and com­mu­ni­ca­tion. Despite the fact that peo­ple think sales is just about the close, it should be about a good close with a good client. 

The fix

The more you can talk through how the sales process and PM role work togeth­er to help strength­en good leads and suss out bad ones, the bet­ter your org’s chance of sur­vival. Talk to your team and busi­ness devel­op­er about the risks and ben­e­fits of work­ing togeth­er if you feel like you can and if not, seek some allies who can help you table that con­ver­sa­tion. If it leads nowhere, your org is prob­a­bly more focused on growth than sus­tain­abil­i­ty and might be a can­dle in the wind.

The business developer doesn't clarify timeline, scope, budget, or stakeholder details within the first call with the lead.

The soon­er your busi­ness devel­op­er has the oppor­tu­ni­ty to vet incom­ing leads, the bet­ter. Delays in find­ing out fun­da­men­tal infor­ma­tion drag out the sales process and lead to mis­com­mu­ni­ca­tions that have a huge impact on the project. 

The fix

If your team does­n’t have this core infor­ma­tion before a project starts, go back to the sales per­son and ask for anoth­er call with the client to clar­i­fy the details. Come pre­pared with any con­straints that might impact the project time­line, bud­get, or com­plex­i­ty. It’s also smart to have a non­ver­bal way to com­mu­ni­cate with your busi­ness devel­op­er dur­ing the call so as not to under­mine them but still to pre­vent any snap deci­sions (like a sign for yes or no or a sys­tem of doo­dles). Keep being a love­able hardass. It pays off.

The business developer or owner tells the team to just make the project work because 'we need the business.'

Um, this is not good. The pipeline is dry and des­per­a­tion has sunk its teeth into your lead­er­ship’s heart. 

The fix

Out­line the risks and con­se­quences of tak­ing on this work and find out if there’s any work you can drum up out of exist­ing clients (cur­rent ones are always a low­er ener­gy bar­ri­er than start­ing fresh). Hope­ful­ly, it’s tem­po­rary but if these awful but nec­es­sary projects become a reg­u­lar thing, it might be time to brain­storm some new busi­ness ideas togeth­er as a team to drum up some addi­tion­al busi­ness (as well as solid­i­fy a new direc­tion that might dif­fer­en­ti­ate your orga­ni­za­tion). Like work breeds like work, so if you take on one sick client, more will prob­a­bly follow.

The business developer refuses to talk about potential risks with clients and stakeholders.

If your busi­ness devel­op­er is too afraid or averse to talk­ing about risks and red flags with clients it could under­mine your project and lead to a bal­loon­ing scope and mas­sive client man­age­ment issues. 

The fix

Find out if there’s any­thing spe­cif­ic caus­ing your busi­ness devel­op­er’s dis­com­fort and share a few of these scripts to help ease the con­ver­sa­tion. If noth­ing changes, raise your con­cerns in the open and find your allies at work who can help rein­force ideas for bet­ter com­mu­ni­ca­tion. It’s a col­lec­tive effort to but­ton up your process­es and reduce incom­ing risk, and a strong busi­ness devel­op­er can do a ton to offload this work for the PM. Make sure that your busi­ness devel­op­er has a sol­id list of red flags avail­able to ref­er­ence as new leads come in the door and bring the PM in ear­ly to help vet them.

The contract requires multiple rounds of haggling or major revisions before it begins.

Heads up: the big­ger your clients are, the big­ger their legal team and expec­ta­tions. This is alright so long as your org is designed to endure length­i­er sales process­es and has a kick­ass lawyer who can nav­i­gate the legalese. The red flags come when there’s quib­bling over the finest con­tract details. It can be indica­tive of your lead­’s lack of trust or transparency.

The fix

You bet­ter be mutu­al­ly aligned with your client or this could be a real doozy.

The lead is a favour or demand from internal stakeholders and doesn’t meet the minimum scope, goals, or budget requirements.

Ever have an own­er or team­mate slip in a project because they know the lead? Yup, it hap­pens — and it can set an expec­ta­tion for low­er bud­gets, faster turn­arounds, and increased expec­ta­tions. This is tough on a team because their hands are usu­al­ly tied. 

The fix

If the lead will hurt the team, prof­its, or com­pa­ny account­abil­i­ty, doc­u­ment this in writ­ing and bring it back to your owner/​teammate with a clear out­line of the risks involved. Be very clear with the client lead about scope exclu­sions. If the project starts to slide or the client goes AWOL, see if you can bring in your owner/​teammate in ear­ly to help man­age expec­ta­tions. Tell your owner/​teammate you need their help and describe how this client project makes it very hard on the team to do great work.

The people doing the work aren't helping to scope it.

A big no-no. There is noth­ing more dan­ger­ous than some­one who does­n’t touch the work plan­ning and com­mu­ni­cat­ing to a client how long it will take or how much it will cost. Own­ers and busi­ness devel­op­ers will typ­i­cal­ly under­es­ti­mate the scope and have more opti­mistic bias about how long it would take them to com­plete it. 

The fix

Rely on your team to help nail down a high-lev­el esti­mate and sched­ule range when new projects come in and make sure you’re con­sid­er­ing how any red flags will impact your num­bers. The peo­ple doing the work are the best pre­dic­tors of its density.

The prospective client asks for a discount before the first engagement.

That’s not how you roll. Or it should­n’t be. Dis­count­ing work up front sends the mes­sage that you’re des­per­ate for the sale rather than con­fi­dent in the close. It also sets up an expec­ta­tion for future discounts. 

The fix

When­ev­er a prospec­tive client asks for an upfront cost break, make sure you’re only say­ing yes if you know the client will be in for a long-term rela­tion­ship and don’t dis­count the first project, dis­count the sec­ond — lightly.

The prospective client has no money or is a not-for-profit who wants free work.

Lis­ten, it’s a good thing to give back to the com­mu­ni­ty, but unfor­tu­nate­ly, unless you’re cov­ered by grants or gov­ern­ment fund­ing, it can put your org in a dan­ger­ous posi­tion when you take on free or very low bud­get work. 

The fix

If you’re going to go pro bono, be sure that the clients needs and goals align with your own and that you can finan­cial­ly afford to take the client on. It’s also a good idea to set more rig­or­ous con­tract terms that can cinch scope and time­lines since pro bono clients tend to be the ones who need the most support.

The prospective client has very strong ideas about what they’re looking for AND how it needs to look.

Dan­ger bay. If your lead thinks they know exact­ly what they’re look­ing for and how you should do it, they’ll like­ly be picky, need more time to make deci­sions, and they’ll tack on scope with addi­tion­al change requests. 

The fix

Be up front and ask this client how open they are to devi­ate from their ideas. If they don’t respect the busi­ness case or user research and did­n’t hire your org for its process­es as well as its out­puts, it might be time to hit the high road and walk away.

The prospective client is rude, demeaning, or distrustful.

The fix

Do not work with this client.

The sales and project teams do not have a clear handoff process for closing sales and starting the project.

If your sales and project teams don’t have a clear han­dover built into your process, it’s the worst kind of tele­phone: a dead one. 

The fix

To avoid sur­pris­es in scope, time­lines, and fea­tures, make sure you’re but­toned up. Gath­er project relat­ed ques­tions from your team and bring them to sales, or even bet­ter, have sales brief the team well before kick­off and don’t stop the meet­ing till every­one’s ques­tions are answered.

The salesperson completes full proposals for uncertain leads.

Pro­pos­als take a lot of work, and if you don’t know whether a lead will close, it can be a wast­ed effort. If you notice your sales­per­son writ­ing pro­pos­als for every uncer­tain project lead, your org is fish­ing too hard for the chance at a bite. 

The fix

Keep your com­mu­ni­ca­tions infor­mal and your notes short until you know if your lead wants to move for­ward and take the next step. They’ll appre­ci­ate your org’s can­dour, and your sales­per­son will appre­ci­ate the extra half day of time that mate­ri­al­izes when say­ing no to uncer­tain proposals.

Important stakeholders missed the kickoff meeting.

You worked hard to make sure the right faces were at the table, but your faces didn’t show. What now?

The fix

Con­duct the kick­off and find out as much as you can with a caveat that you’ll need to bud­get addi­tion­al time to make sure core stake­hold­ers are looped in next. Then put the project on pause until you can estab­lish what hap­pened and how to move for­ward. You’ll need to clar­i­fy stake­hold­er roles now that fun­da­men­tal deci­sion mak­ers were left out of the mix or it’ll lead to major break­downs through­out the project. Clear­ly, align­ment is out of whack and it looks like folks have dif­fer­ent pri­or­i­ties. Then again, your poor stake­hold­ers may have been dragged off a Unit­ed flight with­out their con­sent. Always get the facts before mak­ing assumptions.

Research reveals a hidden barrier or project constraint.

You’re half way through research and sud­den­ly real­ize your scope is triple what you thought it would be. Uh oh: this is sure to be death by scope creep. 

The fix

As soon as you know, it’s time to talk with your team and then your client/​stakeholders. If you know what your Min­i­mum Viable Prod­uct should be, tasks will be eas­i­er to pri­or­i­tize, but if you don’t, now’s the time to make some hard deci­sions with your client team. Do: Work togeth­er to pri­or­i­tize the items that will return the most val­ue to the peo­ple pay­ing for it. Come back to low­er pri­or­i­ty items lat­er with an addi­tion­al bud­get. Don’t: promise to do all the work any­way — or your com­pa­ny will lose its shirt.

This is why research is so grande. It lets you catch the zingers before they catch you.

Your client downplays the importance of research.

Aside from this being an egre­gious affront to the sci­en­tif­ic world, it’s just plain dan­ger­ous. Is your client omnipo­tent? She’d bet­ter be. Or you’re bound to build the wrong thing.

The fix

Most projects fail because of stake­hold­er mis­align­ment which often leads to a break­down in pri­or­i­tiz­ing project require­ments. Research is the buck­et that catch­es all the data so you know what your require­ments should be in the first place. Explain to your stake­hold­ers that research ensures you don’t build the wrong thing and it means you don’t waste your resources. If they push back or dis­agree, run for the hills. This client will be look­ing for a fin­ger to aim at you lat­er when denial gives way to reality.

Your developers zone out when you ask for help with kickoff questions.

If your team gets that deer-in-the-head­lights look when you ask for their help with ques­tions (or worse, shrugs and gives you the obvi­ous ones), remem­ber they’re human. Most of the day they’re eye­ball deep in code, and deep ques­tions require strate­gic focus instead of intense focus. Two very dif­fer­ent parts of the brain at work. 

The fix

Imag­ine your devel­op­ers are sub­marines and give them time to come up for air. Do an exer­cise to help them tran­si­tion from log­ic brain to strat­e­gy brain like a group puz­zle or esti­mat­ing chal­lenge (how many jel­ly­fish in this jar). Prime them with relat­ed ques­tions, work back­ward from a futur­is­tic launch, and ask hypo­thet­i­cal­ly ​’what went wrong’ along the way. The more your team whole­heart­ed­ly under­stand the depth and scope of the work they need to do, the bet­ter the chance you’ll break down silos and cre­ate bet­ter, more effi­cient solutions.

Your interviewees never seem to be available or won’t make time for the project

Warn­ing, you could have a case of stake­hold­er mis­align­ment on your hands. That, or your client isn’t real and we’re all liv­ing in the Matrix.

The fix

Talk to your point of con­tact and find out if they can wran­gle some times on your behalf — if they’re able to put pres­sure on, inter­vie­wees are more like­ly to com­mit. If not, con­sid­er how you can get this info from anoth­er research can­di­date and pro­ceed with cau­tion. We all know folks are busy, but sab­o­tage is anoth­er lay­er which indi­cates prob­lems deep­er down in the struc­ture of the org. Tread lightly.

Resources disappear during your project.

You sched­uled in your resources just like a good PM should but they’ve been pulled onto oth­er projects. What now?

The fix

Clas­sic. You’ll need to either hire, out­source, or real­lo­cate those nice humans on your project team. Your best option is to have a sol­id plan­ning con­ver­sa­tion with oth­er leads who book resources and deter­mine the pri­or­i­ty and order of those projects so you can see if time­lines should shift or more peo­ple need to be added. This is a plan­ning and sched­ul­ing issue more than a capac­i­ty issue — But make sure you know what prob­lem you’re solv­ing by explor­ing how busy your team­mates are over the next few months and adjust­ing accordingly.

Several projects are set to launch in the same time frame before a major holiday.

A cou­ple late starts and a cou­ple late fin­ish­es and you’re stuck with a sit­u­a­tion where all your projects are launch­ing at the same time.

The fix

Find out if there’s any wig­gle room to launch lat­er and if not, clamp down on the scope and con­sid­er ded­i­cat­ed sprints where you focus on dri­ving one project for­ward at full team capac­i­ty (to reduce dis­trac­tions) before switch­ing to anoth­er. Have a con­ver­sa­tion with your stake­hold­ers and deter­mine if you can re-pri­or­i­tize any items after launch to save a week or two. Make sure to cel­e­brate with your team once they hit the fin­ish line, and by Zeus, don’t launch on a Fri­day before a major hol­i­day unless you want to be the least liked per­son at your org. Good luck.

The client shortened the timeline on your team.

A sud­den project change has bumped up your project dead­line but your cur­rent scope will make it impos­si­ble to com­plete in time. 

The fix

Have a pri­or­i­ti­za­tion con­ver­sa­tion with your stake­hold­ers and find out if they’d rather reduce scope or add bud­get to accom­mo­date the addi­tion­al resources you’ll need to fin­ish the project in time. If they balk at the con­ver­sa­tion, this is a big red flag: you can’t expect an org to do dou­ble the work in half the time and not feel the con­se­quences. Set some clear expec­ta­tions around scope and bud­get or get out before it’s too late.

Too many projects scheduled at once or surprise projects land on top of a planned schedule.

Your busi­ness devel­op­er hit you and your project team with anoth­er project on top of your already brim­ming schedule. 

The fix

When a team is over capac­i­ty (e.g., work­ing on more than three projects at any giv­en time) they will have trou­ble focus­ing and pri­or­i­tiz­ing which will put time­lines at risk and will increase their stress. When sur­prise projects land on top of a team, it’s a sign of poor plan­ning or poor cash flow (aka des­per­ate mea­sures). Try to block out a few days per sprint to tack­le this extra project and see if there’s wig­gle room to extend your oth­er project time­lines. It’s also a good idea to stag­ger your project starts and launch­es by and build in a good-sized chunk of buffer between them.

Urgent deadlines with no clearly defined reason for the urgency.

Your stake­hold­ers set a firm dead­line for your project but nev­er gave you a rea­son why. Uh oh.

The fix

Always find out why a project is due and if that due date is flex­i­ble. Find out if there are any relat­ed projects that are launch­ing in the vicin­i­ty. If not, make sure to ask about the con­se­quences of a late launch and make a back­up plan for pri­or­i­tiz­ing scope just in case — many times a dead­line is a false assump­tion which puts unnec­es­sary pres­sure on the team and client.