Subscribe via RSS Feed

Category: For Practitioners

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

I clearly 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.

What Projects and Airplane Flights Have In Common: Turbulence

I love this metaphor to help leadership, management and project teams all see the forest for the trees. Here are the key points I share:

Nobody will remember the turbulence, if the plane arrives on time and in the right city!

I used to fly quite often. One of my frequent destinations was New York. Depending on weather and other factors, it wasn’t unheard of having a flight to Kennedy re-routed to Laguardia or even Newark. In those days, it happened. But the one flight I remember best was one returning home to Chicago.

I remember one bad storm that caused our plan to circle O’Hare for what seemed like 2 hours. That delay, by itself, wasn’t out of the ordinary. The reason I remember this one trip is because when we landed, I found myself in Cleveland.

I’ve had my share of turbulent, strap-yourself-in and hold your breath, flights, that landed late. I don’t remember any specific ones. But, you better believe I remember when they re-routed us and we landed in Cleveland. I rented a car and drove ½ the night to make it to Chicago by the end of the day.

So What Did Success Look Like for My Many Trips?

  1. At a minimum: Land safely!
  2. It’s better if we land in the right city.
  3. It’s even better if we land in the right city at the right airport.
  4. I consider it a successful trip if we land within 60 minutes of our planned arrival time, in the right city in the right airport.
  5. It’s almost too good to be true if they had my preferred meal, I got a great view of a sunrise or sunset, and there was little turbulence.

And this is exactly how our stakeholders feel about our projects

  1. At a minimum, deliver “something of value”, even if late, without cancelling it due to budget and delays.
  2. If I can get all the functionality needed for the market, we’re doing better. Even with some bugs, I can work with that.
  3. And if it’s on schedule (or close to schedule) and budget, we’ll be celebrating!

But the one thing the teams should remember. Most flights have turbulence, and they run out of your preferred meals, and there’s unexpected weather and other challenges. In a year, no one will remember those details.

Make sure the project lands safely, with the appropriate functionality. Because everyone will remember the project that crashed landed.

I have another post that compares the PMO to Air Traffic Controllers. It shares best practices that helps you put in practice the lessons shared in this article. Stay tuned.

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.

Project Retrospectives: When looking forward makes more sense than looking backward

iStock_000016701854SmallRecently a consultant asked me if I encourage teams to do a project postmortem or retrospective once a project is done.  The goal is to review what worked well and what didn’t.

Winning with “Project SD”

Winning-with-Project-SDEvery team needs a process they can embrace because they know that process will get them to the desired result.

Project Glossary: The Right Way to Create One

Project-GlossaryDuring the course of most projects, at some point, someone starts creating a project glossary of terms.  Typically, most of us are well into the first or second requirement document before we realize that people don’t understand some of the terms or acronyms being used.  When that happens, the Business Analyst or Project Manager starts the glossary so everybody can understand these specials terms and acronyms.

I have come to believe that a project glossary really should be created right at the beginning of the project. In other words, on day one when you start working with the business, collecting initial high level requirements and defining the business case.

The project glossary is critical. And even though everybody uses it just to explain acronyms, I think it should do something a little different.  How about a project glossary that is used to actually explain the intention of a word, not just to define it?

What is CRM really used for?

Let me give you an example. “CRM” is a term that many people in the industry are familiar with.  Although CRM stands for Customer Relationship Management, many organizations do not use their CRM system to track existing customers. They’re using it to actually track prospects or non-customers. So if  “CRM” wasn’t as ubiquitous and somebody brand-new (who never heard the term) came in, they might say, “Well, why are we in the CRM system to track prospects? Why wouldn’t we use the CRM system just to track customers? Isn’t that what the C in CRM stands for?”

Ideally, our glossary would have an entry for CRM that explains CRM stands for “Customer Relationship Management”. However, it would also go beyond defining the acronym and actually explain that on this project, or in this organization, we use CRM as a business development tool for prospects as well as to track dialogues with existing customers.

Then there are some companies that use the word “customer” to represent certain customers and use the word “client” to represent special VIP customers. This should also be explained in the glossary so that everyone understands the difference between the customer and client and the perception around those two segments.

But Wait, There’s More

Another tip about project glossaries: Don’t just define or explain how you’re using a term or an acronym. Also explain what the term doesn’t include. For example, if “word processing tools” were in my glossary, I’d say, “This term describes the spell check, formatting and print tools but does not include the process of sharing documents via e-mail.”  This way there’s less confusion.  You can read my previous post on ambiguity here.  It’s an interesting story on how ambiguity can create grave problems in any project if you’re not careful.

To summarize, the glossary is critical to good project communications and should be used for more than just explaining acronyms. Other things to keep in mind:

  • Create your project glossary at the very beginning of a project.
  • Use your project glossary to explain ideas, including how the term is specifically used within the organization.
  • Include the scope of the term, specifically what the term does not include.

Do you use glossaries from day one? Do you have any best practices with your glossaries?

Announce Changes and Avoid Wig-Outs

breaking pencilIn previous posts, I have discussed best practices around Change Control. Or, maybe I should say “lack of best practices” since so many organizations either fail to follow a defined process or simply don’t have one.

What Taking-a-Hike Can Teach Us About Business

Hiking in autumn forestSomething Special…

This week I have something special for you. A guest post from one of my best friends. Dave Katauskas regularly shares insights that  make a huge impact on a team’s performance and success.  The story below has changed how he and I make choices within our daily work.

So, without further ado, I hope you enjoy the following blog post as much as I did.

Have I got a story for you!

Recently, my friend, we’ll call him “Bob”, and I decided to hike on the Ice Age Trail in Wisconsin. This was in preparation for our bucket-list-goal of walking a portion of the Appalachian Trail.  We knew any hike would be a challenge merely because we were non-active desk jockeys, 50+ pounds overweight and past middle-aged.  If you’ve ever seen the “before and after” photos in most health diets, we would be in the “before” picture.  I believe that sums it up.  Yet, we were determined and eager to get started.

Let’s get going!

On the first day of our 2-day hike, we set out on the Ice Age Trail to explore the wilderness and just enjoy ourselves.  We saw many great sights and regularly rested with food and water from our backpacks.  It was a great day with perfect weather.  All of the elements indicated that this day would run flawlessly.  In an eerie sort of way, this was strangely similar to the optimism and energy we have when starting a new and exciting project.

Knowing that this first leg of the hike was only a day hike, at some point in our journey we would need to turn around and track back to our car.  The morning went well. We felt strong, full of energy, sharing a great time on a beautiful day. The morning was going quickly and before we knew it, we reached the five mile mark. It was just after lunch that we started to think that turning back at this point would be smart. The second half of the hike would probably go slower.

After looking at the map, there was a ridge ahead that would provide some interesting views and a shelter.  Feeling physically able and still eager, I suggested that we squeeze in a few more miles before turning back.  Bob had a gut feeling that we needed to turn back because we may be reaching our physical limits.  He’s older and more out of shape. Of course, he was also being risk adverse. We all have a Bob on our project!

We clearly weren’t in agreement, so we discussed it a bit.  But without the definitive proof that we were actually reaching our limit, we decided to press on. His version of this story is that I convinced him to press on. We agreed to turn back at mile seven.

Around mile six, the path changed to a steep incline. I mean a painful, slow, incline.  But we made it to the top and to mile seven.  We felt great at arriving at the top of the ridge and rested on the trail near the tall grass.  Unfortunately, the view wasn’t as spectacular as we had imagined.  In fact, there was no view at all except for tall brush and grass.  But we still felt great at making it to mile seven!

So we took a break and decided that it was time to turn back.  The first seven miles were great so the next seven should be equally great…right?  As you’ll read later, we were oblivious to the fact that we were just short from the real “point of no return”.

It’s really not that much farther…

Well, about two miles into the return trek, we realized that we were out of water.  In addition to that, our legs and feet were starting to become very fatigued and sore.  But press on we did, not that we really had an option.  So, another two miles later (that’s 11 miles total for the geeks doing the math…like I just did) we were now becoming worn out. The storm clouds started rolling in, the wind was picking up and our flawless day was no longer looking so flawless.  We now had as additional sense of urgency to stay out of the impending storm.  Yet, we still had about three miles to go.  We saw the coming gloom, we still had plenty of trails in front of us and we were in pain. Talk about a “Death March”! (Have you ever experienced a software project similar to this?  Doesn’t this really sound like the beginning of a death march?)

Houston, we have a problem

The next mile became a struggle as our bodies were not actually equipped to deal with the demands which we had placed upon them.  This next mile was truly indicative of what the final two miles had in store of us.  Our legs started cramping, each step was actually painful and we were thirsty.  We limped along, well aware of each and every step. We genuinely weren’t sure if we would make it back to the car without some assistance.  (How many times have we committed to more than we can successfully handle?  Or actually know what we are really committing to?  On the plus side, we did know that were very close to needing to ask for help.)

And then it happened…

It became apparent to us that our short term view of what we thought was feasible became a decision that ultimately created pain, anxiety and the possibility of failure.  To add insult to injury, it started raining. (The “death march” continues)

After a long while, we finally reached our destination and found a covered bench.  We sat for a few minutes, then headed toward the car; a distant 12 feet away.  Limping and cramping is what I remember mostly.  After what seemed like an eternity, we walked from the bench to the car.  Now we just needed to get in.  We somehow managed to hold back the man-tears. Well, at least I did!

The residual evidence was apparent by our pampered and ginger walking around the office over several days.  A trip we’ll never forget!  (I’ve certainly been on projects where we limped across the finish line). Yes, pain is certainly one of the best teachers.

How we changed our views

A few weeks after our hiking experience, we were able to reflect again upon our journey and we noticed similarities around how making decisions for short term goals, or decisions based on lack of insight, can have significant effects on long term outcomes.  The decision to continue after mile five was clearly a bad decision.  We talked about the moment, that specific choice, which led us to continue on.

Then I thought about all of the bad decisions that I’ve witnessed and made on project work. But instead of the conversations centering on making a bad decision, we would state that it was just poorly executed. We would never challenge our decision approach or conclusion.  For this hike, our execution was fine; the decision was bad.

We then started discussing some of the decisions that we’ve personally made in directing business objectives and how some of those decisions created pain for ourselves and others.  And, in some cases, it established additional barriers for corrective action.

Our take away…

So, when making business decisions today, I now ask “how can we prevent this from becoming our 14 mile death march?” and “are we just kidding ourselves?”  I was actually able to put this into practice one day when our leadership group was discussing strategic staffing.

We knew that a decision to handle a short-term, non-bulls-eye opportunity would certainly hurt our capability to engage in an on-target opportunity in the future.  So, we had good discussions around that topic and looked at the varied perspectives with our eyes wide open.  We stuck with the strategic goals in spite of a small immediate win.  And since then, we’ve been able to apply that same concept to other growth challenges.

In addition to all of that, Bob and I have since hiked again.  This time, it included a change in our behavior, thinking and knowing our real capabilities.  It was a more pleasant experience.

So next time you have a tough choice and everyone is debating an approach, consider you may be at mile five of your hike, and sometimes, it’s better not to push the limits … because you’ll feel the pain for quite some time afterwards!

Solutioners are from Mars, Supporters are from Venus

Solutioners-are-from-marsRecently, I was asked to facilitate a team-building session for a group of directors.

It started with the normal “storming”, “norming” and “forming” that takes place when teams form. But then I had a huge AHA – a major breakthrough that, for some reason, has eluded me for quite some time.

In this meeting, there were nine directors who collaborate with each other across projects.  One of the directors, let’s call her Mary, began to explain how her team members were struggling to get their deliverables done on time. One particular customer, she explained, was beginning to get a little frustrated with their inconsistencies.  As soon as Mary finished describing her challenge, one of the stronger directors on the team, we’ll call him Joe, responded with his idea: “Well, can’t you work around the issues this way?  Shouldn’t this solve the problem?”

Joe continued to explain his ideas and approach.  He was talking for about 45 or 60 seconds before Mary deftly interrupted him and started explaining to him why she was frustrated and continued to explain her challenge in more detail.

Mary and Joe started talking at each other in  an extremely painful conversation.  At some point other people in the room said, “Hey guys, do you see what’s happening?  You’re talking at each other.  You haven’t heard one word that the other person has said.”

I think we’ve all experienced that.  We’ve all faced a situation when we’ve seen two people talk at each other.  Until they feel heard, they can’t hear the other person.  This is not a new concept.

We asked Joe, “What did you hear Mary say? Did  you hear her?  Because she didn’t think you heard her.”  In response, he effectively repeated some of the words that Mary said.  “So you’re having quality issues, and you’re missing your commitment so you’re getting beat up.”

We then turned to Mary and asked, “Is that what you said?” And she said, “No, that’s not what I meant.”  This went back and forth a couple of times. We’ve all been there.

And then I had the AHA!

Look at what really happened here.  Mary was sharing her situation.  She accepted ownership for the situation, and even though she was struggling a little bit, she wanted to work through it.

Joe loves solving problems. He wanted to share a solution. That’s his job! He immediately tried to help Mary solve this problem by offering her solutions.  But Mary didn’t want him to solve it for her.  Rather, Mary was just looking for people to provide support. Mary wanted to hear, “That’s got to be painful. Is there something we can help you with?”

Supporting vs. Solutioning

Many times when a colleague (especially a peer or direct report)  first shares a challenging or frustrating situation, they are  looking for your support.  They don’t want to be perceived as “giving up”,” out of ideas”, or relinquishing ownership for the situation.

There are other times when the individual may truly be asking you to step in and help solve the problem. They may feel they are in over their head. They need your help to find a solution.

What Joe did was fail to ask, “Do you need help? How can I support you?” He assumed the way he could support Mary was to give her a solution.  This approach made Mary feel insecure because she felt like Joe was going to take control of the situation and undermine her authority. It may have even made her feel stupid.

I think back to two leaders within my own company, both of whom have an affinity for solution mode regardless of what you want to talk about.  If you approach them to talk about how bad traffic was on the way to work, they don’t say, “Oh yeah, I ran into bad traffic too.”  They will actually say, “Did you consider taking a different expressway so you don’t hit traffic?”  They’re actually giving you alternatives to which you might go, “You’ve got to be kidding!  I’m not looking for alternatives! I know how to get to work.”

If you take two people who live in solution mode and put them together, they may struggle to understand who owns what and how to collaborative more effectively.  They both assume they personally own and are accountable for solving the problem because that’s how they’re wired.  Although they might have good problem solving skills, solutioners can make others feel like they’re not as good at their job or they’re failing because the solutioner had to grab ownership of the problem and solve it.

Unlike solutioners, supporters are not pulling ownership and accountability away from someone, which makes it safe to interact.

My current thinking is that if you take a solution person and a support person and put them on the same team, then they tend to really complement each other. You have to be careful, though, about putting two strong solutioning individuals together, especially if they don’t know how to throttle it or are unaware of what they are doing.

Bottom line, when you interact with your team or a colleague, I’d be aware if they are asking for you to be in support mode, or actually solution mode. This can help you be more effective at setting the team up for success!

Mars vs. Venus

I recently shared these thoughts with several colleagues who validated my thinking. One of them chuckled and said I just  summed up the book, “Men are from Mars, Women are from Venus.” (The bestselling the book that explains that sometimes all your partner really wants is for you to simply listen and be there for them.) This really made the concept hit home, and in fact, it helped me out at home too!

Do you have any solutioners on your team?

Change Control: Do You Own It or Does It Own You?

Change-ControlOver the last year, I have noticed a myriad of projects that begin to struggle once they begin the change control process. Doesn’t matter the type or size of project – they all appear to drop-the-ball when it comes to following the change control process. This pain surfaces not only in the schedule and budgets, but also in the lack of trust that builds between the business and technology teams.

I want to share some best practices than can help teams manage change control in a more disciplined format. In this first post, I discuss the key roles that should be involved in change control.

What is the typical change control process?

In a typical scenario, the business or project stakeholder comes to the table and says they want to change some functionality. This can be a change to something already built, or it could be a change to some requirements you have collected but haven’t implemented.

When asking for the change, the stakeholders typically want to understand any impact to cost or schedule before committing and asking you to “implement” or “deliver” the change.

What are the roles typically involved in change control?

In a typical change control process, the roles look something like this:

After a change request is submitted, someone is responsible for tracking and reviewing (think triage here) the change request. Acting as an editor, they review the change request and make sure the request is complete and without ambiguities. If there are any gaps or missing information, they go back to the “requester” or to the stakeholders to get the missing information. Obviously that’s pretty standard practice.

Next, one of the technology team members needs to assess the change request and determine what, if any, impact it will have on the current plans. By assessing, I mean sitting down and evaluating the impact of this change request against schedule, budget and staff. They may also identify questions for the stakeholders that need to be answered before they can complete their assessment.

This is where you typically have a “go to person” to do this initial assessing. This resource will typically be asking questions like:

  • Are we short on staff to handle this request?
  • What impact will there be to schedule?
  • What additional risk and/or dependencies does this add to our project?
  • Do I need any “specialists” or unique tools for this request?
  • And so on

The Changing Roles of Change Control

This is where I suggest including a larger team to do the change evaluation. Many of you may already use this approach. Kudos!

But for the rest of us, I suggest that we get a total view when assessing the impact of a change request. This means include a business analyst, quality analyst, etc. in the assessment.  I know there are some Agile teams that do this with all team members. Woohoo!

Why is this so important? Because one person probably can’t truly know the impact this change will have on other parts of the development or the development process.

For example the change may be trivial for the developer because it will take just two hours effort. However, the Quality Assurance team may have to rerun all of the regression tests, impacting the schedule by up to two days. A business analyst may actually look at the change and say, “Given the change, do we need to change three other things in the system so they’re all behaving consistently?” All of a sudden, the business analyst may have to modify other requirements. The dominoes may begin to tumble.

I suggest you make sure all roles on your team are included. It would be sufficient if a single team member plays multiple roles as long as this person knows they’re representing these other roles and thinks through the implication to other scheduling, staffing and costs.

Communicating Change

Make sure change requests are communicated across the entire team. Communication to and within the team is a discipline. Some of my experiences this year have reinforced that communicating changes isn’t optional.

Many team members think a trivial change (like a cosmetic change) doesn’t require informing the entire team. Again, this is NOT optional. It must be understood that we as a team are committed to each other and we’re not going to ”surprise” each other with changes requests. Once that is established, we need to educate the business, clients, and  stakeholders about our change control process and that they, too, must follow it.

Three Key Take-Aways:

  • If you don’t have a change control process, implement one quickly.
  • If you have one, but you’re not using the discipline to enforce it every single time a change comes through, you need to introduce that discipline to the team.
  • If you have a process and discipline, make sure that when you do the assessment all the roles are included (even if it’s one person representing the roles). Reinforce that the efforts of the QA, BA, etc.  have to be taken into consideration.

Do you have any other key best-practices for handling change control?