Subscribe via RSS Feed

Category: People

The Networking Meeting That Changed My Life; And It Can Change Yours Too!

I remember when I was introduced to networking. It sucked! I was uncomfortable. I was actually shy and didn’t know what to say or do. Most people that know me today wouldn’t believe it. But it’s true.

Before I share with you what I consider the most important networking best-practice, I’m going to share the story of how I was introduced to networking. It has truly changed my life, personally and professionally.

Joe Made Me Do It…

Early in my career, I had a great mentor. Joe always looked out for me. One day, Joe asked me why I didn’t bother networking. I told him I didn’t know how and I didn’t know what was expected, so I was afraid.

Joe asked about the last work meeting I attended. I told him we were kicking off a project for the sales leadership team and we just had the kickoff meeting.

Joe sat in my chair and typed out an email to the VP of Sales that was in the meeting. The email said it was great having a project with him and I’d love to get a chance to network over lunch. Blah Blah Blah.  Joe sat me down and said the decision to send the note was mine.  After a few minutes, I pressed send.

About three weeks later, Joe and I were going to lunch. When he stopped by, he asked me if I ever heard back from the VP. I chuckled and said, “Of course not; I told you so.” Before we left for lunch, my phone rang. It was the VP’s secretary. She explained that his lunch date just cancelled and he wanted to know if I was free for lunch.

I put the phone against my shirt, so she couldn’t hear me. “He didn’t want to go to lunch with me, his date cancelled and I’m just a fill in!” Joe laughed at me and said, “Don’t be an idiot (he said that a lot), go to lunch.”

I lifted the phone back to my ear and heard the secretary laughing. She heard every word. “Barry will meet you at Friday’s in 15 minutes. Enjoy lunch.” I felt like such an idiot.

But Wait, There’s More

I met Barry for lunch. After the chit chat, he asked me “So what’s up? How can I help?” I told him I was learning to network and Joe suggested I ask him to lunch. “Joe gave me one rule. I was not allowed to talk about work, at all, unless you chose to do so.”

Barry laughed and told me Joe was very smart. He went on to ask about my background, my family, how I arrived at the company etc. He shared his background etc. It turns out we both loved magic and used the same magic shop in the city for supplies. We spent almost 2 hours at that lunch. And that wasn’t the best part.

The Payoff

Remember the sales project where I met Barry? A few months later, it was off the rails. We had another meeting with sales to discuss the issues. There were 8 folks from our team, including my boss and her boss. And there were 4 folks from sales including Barry. It was a painful meeting.  As everyone was getting up to leave, Barry looked across the room and said, “Bob, anything you can do to help us out would mean a lot. Let me know if you need anything from me.” And he left.

You could’ve heard a pin drop. We had our butts handed to us. And after what seemed like forever, I realized everyone was staring at me. My boss’s boss finally said “What the heck was that? How do you know Barry?” I simply responded: “I know Barry from Networking”.

Barry and I connected; I was more than just an IT dude that was frustrating him. I was “someone in his network” and he asked for my help.

There is a key rule that will make or break your networking meeting.
And so, I’m finally ready to share the rule:

The Rule…

It is the cardinal rule. On Shark Tank, Mr. Wonderful is known to say, “You’re Dead to Me”. If you break this rule, many new connections will feel it and you’ll be dead to them!

When Networking, You Are Not Allowed To Ask For Anything, Unless They Ask You Too…

Yup, it’s that simple. If you’re networking with someone in your office, you should avoid talking about relevant work. That would make it a working-meeting, not a networking meeting.

If you’re in transition, avoid bringing up that you are looking for a job. When they ask, you can share it. I can’t remember a time that the person across the table didn’t ask me “So what’s going on with you?” or “How can I help you?”.

When they ask, I emphasize, that’s not why I wanted to connect, but then I share. I make it clear that wasn’t the purpose of the meeting. And it really wasn’t! The beauty is that if they feel like we connected, they will want to help without my asking.

And if you’re in sales, this works as well. Don’t cold call or show-up-and-throw-up (I hate that slang). Network, connect and try to help! They will appreciate it.

The Challenge:

You will have to do this on trust. I know this may go against every need or fear in your body, but I challenge each and everyone one of you to have 3 network meetings. Here are the rules:

  1. Meet someone new. An acquaintance or a friend of a friend.
  2. Don’t bring your agenda. Go with the only goal of connecting so you may be able to help them.
  3. Resist the urge to ask for something. Let them ask you.

Give it a try at least three times. I’d love to hear about your experiences in the comments.

Stop Padding Your Estimates! There’s A Better Way…

When you pad an estimate, you typically increase your estimated effort/cost due to fear. I call this estimating from a place of weakness. You are afraid of the unexpected event, so hopefully padding it will cover it.

When asked why you think something might take 50% longer or cost more than expectations, it leads to an awkward uncomfortable conversation. And almost always, it creates distrust. How do I know you haven’t padded everything?

A Better Way: Contingency

Instead of padding out of fear or worry, add contingency instead. Let me clarify what I mean.

An example of padding an estimate: Your estimate is for 2 weeks to finish a straight forward project. Because you know stuff happens, you decide to say it will take 3 weeks. That gives you a full week to recover from delays or fix any defects.

How do you know a week is enough padding? You don’t. But you believe you can get away with it easily enough. Saying 4 weeks would be pushing your luck.

Instead, here’s the same example using contingency: You provide your estimate as being 2 weeks. You also explain that typically, there are delays of source material, and defects that need to be addressed before we are all done. So you are adding one week of contingency time, just in case.

You are sharing your estimate and “contingency” from a place of strength and confidence. You show it’s in everyone’s best interest to include the contingency. It builds confidence and trust.

It’s not uncommon for one of my full project plans to have contingency tasks added throughout the plan. If the customer wants to push back, here’s how the conversation goes:

Customer: “I see every time you are working with the API team, you show a task for 3 days, but you add a contingency task of 3 days as well. Can you explain what that’s for?”

Our team: “Typically, 3 days is enough time to integrate the APIs and move on to the next task. However, in the past, this API team is always overwhelmed with work, and some of the APIs are new and complex. So the contingency time is based on history and allows us to plan for those delays. If they can actually reduce turn around time and hit the 3 day mark, we’ll be ahead of plan and deliver early. After all, there are 5 API tasks and 5 contingency tasks.”

Customer: “I’m not sure I am comfortable with this approach. I think we should remove the contingency tasks.”

Our team: “We can do that. However, if in fact those teams don’t hit their tasks, we are going to say ‘We Told You So’ and you can’t hold us to the dates!”

And no we don’t say it this way – but that’s the message.

At this point, I can’t remember a time when the customer didn’t agree to keep the contingency in the plan. After all, they want to be successful too.

In summary…

Don’t pad your estimates. Clarify why you are padding by adding contingency and sharing the risk. Hope this helps you with your estimates. Would love to hear your experiences as well.

The 3 Great Interrupters: Meetings, Management and Drive-Bys

interruptors-300x199Recently, we’ve introduced Commitment Based Estimation  to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.

The Requirements Session Has Started. Do You Know Where the Business People Are?

When it comes to software requirements definition, engage the business … early, often and methodically

ClassroomLast week, I shared the results of a recent survey taken at a IT trade conference on the role of business in driving software requirements. Most of the people taking the survey stated that they consistently struggle in two areas: Connecting with the business and managing requirements throughout the development cycle.  They also admitted that at least part of their requirements process is broken.

This week, I’ll provide some thoughts on how to pinpoint some of these broken processes.

 

About to Start Requirements? Read this First.

During the requirements phase of a project, expectations and confidence run high. However, this is also the phase where lack of best practices begins to undermine success and worst practices rise to the surface.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics. In his white paper, “Doing More with Less: Best Practices for Processes, People and Metrics” [PDF], Geneca Vice President and Managing Director, Bob Zimmerman, suggests asking the following questions to draw out areas in need improvement.

How do you work with the business?

  • Do all business stakeholders agree on the goals of the project?
  • Who owns defining requirements? Is this different from who owns “documenting” requirements?
  • How do you know when a particular part of a project is complete? How do you know when the overall project is complete? Does your team have this information and does it align with business objectives?
  • In general, after collecting requirements, are Change Requests introduced during the first 30% of the development lifecycle?

How do you track projects?

  • Do project status reports show progress in terms the business understands or is it in “IT speak” requiring translation for the business?
  • Is project success determined by being on budget? On schedule? Meeting the original business objectives and ROI? Which one?
  • Does your team use one internal project tracking report for status while the external report is different? Or is there a common report showing progress on the project?
  • Do business and IT team members typically have a consistent view on project status and health?

Are project roles and responsibilities clearly defined?

  • Is there a single person and role accountable for technical issues?
  • If you deliver a solution that works but is missing key features required by the business, is there a single individual and role that is accountable?
  • Are your project managers accountable for tracking progress and making project health visible? Are the responsibilities for this role consistent across all projects and project managers?

By answering these questions, you should be able to hone in on the areas of your requirements practices most likely to impact your ability to satisfy business expectations.

For successful requirements definition, the various players need to be involved in ways they might not have been before. If the business is not 100% committed to making this happen, even the most talented development teams cannot predictably give the business what it needs.

Organizations that hold the business stakeholders accountable to define their needs enjoy better results. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, delivering exactly what the business wants.