Subscribe via RSS Feed

Author Archive for Bob Zimmerman

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.

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.

Stay Inside the Lines to Manage Projects Effectively

Throughout the Getting Predictable blog, I talk about alignment. For many, the word “alignment” is a bit vague. Does it mean we agree? Does it mean I actively support you? If I don’t actively support you, but I don’t block you either, am I “aligned” with you?

As it relates to projects, doesn’t alignment simply mean we agree on what is in scope? Why are there so many books written on alignment, and why do they sound like “consultant speak?”

alignment

The cost of mis-alignment

Alignment is important because when a project team is not aligned, it can not only derail a project, but, in a very subtle manner, prevent the project from ever getting back on the rails.

Sometimes, keeping projects inside the lines can be challenging. In fact, it can be a lot like looking at a roadmap when you’re lost. You’re the driver, you have a navigator next to you, and GPS, and each one is doing something different. You’re not in sync, and it’s difficult to figure out where you’re going. In the confusion, you end up getting even more lost, and it takes you twice as long to get to your destination.

This example illustrates how bad alignment can steer a project – or a car trip – right off of a cliff. The concept of alignment is often a bit of a no man’s land – people don’t understand just how harmful bad alignment can be to a project.

Make Meetings More Effective: Stop Chasing Squirrels

Make-Meetings-More-EffectiveDISTRACTIONS!

I would like to discuss the challenge of distractions.  So many times we’ll be in a meeting when somebody says something that completely moves the discussion off topic.

For example, I’m in a meeting where the goal is to figure out how you’re going to schedule QA testing for a project and when you’ll need the users for User Acceptance Testing.  Then, all of a sudden, we digress. Now we’re talking about how our automated testing tools haven’t been effective and, before we know it, we start talking about evaluating a new automated testing tool suite.

That is the squirrel effect

If you want to understand what I mean by the squirrel effect, go ahead and watch this short, funny clip from the movie Up.

http://youtu.be/bBWrMQVsuak

In this video, you get a glimpse into the minds of dogs.  Dogs are with their masters, or with other dogs, and they’re doing what dogs do: Sniff, eat and dig at dirt.  All of a sudden, there’s a squirrel and the dogs forget everything else.  They look to the right, they look to the left, and they digress.

I was recently in a meeting where a totally off-topic detour occurred, and out of nowhere a colleague shouted “Squirrel!”

I looked at him like, “What the heck was that?”

He shared the video above and explained that meetings distractions are squirrels to dogs.

I decided that every time somebody went off topic in an ineffective use of our time, we would use that as our keyword to remind everyone to get back on track. Very quickly, this has caught on and allows our team to stay remarkably focused.

My Challenge To You

My suggestions for teams to be more effective in meetings:

  1. Everybody should learn what the word “squirrel” means.  Get them to read this blog post and/or watch the video. Discuss and understand the concept.
  2. When you start a meeting, write the objective of the meeting up on a whiteboard where everybody can see it.  Then when somebody gets off topic, point to the whiteboard and literally say the word “squirrel.”

This will help people stay focused on the objective, stop chasing squirrels, and make meetings far more effective.  I’d love to hear your thoughts and experiences.

Photo credit: Pete Birkinshaw

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?

So You Want A Promotion? “What Problem Are You Solving?”

So-You-Want-a-PromotionI recently had a conversation with a colleague about how to discuss career paths with employees. I had an “AHA” about a great way to eliminate the more painful conversations and how to focus on true opportunities for individual growth. It centered around the question: “In a particular role, what problem are you trying to solve?”

Before I share the insight, I want to share a few concepts about roles and their definitions.

Accountability vs. Responsibility

When I personally say that someone is ‘accountable’, I mean they own the results. When I say someone is responsible, they own an activity or  task.

The Vice President of Sales is accountable for delivering $xxx million in revenue to a firm.  However, the Vice President of Sales is typically not responsible for setting up individual sales calls. That responsibility sits with individual sales employees.

So, in your role, there are two things to consider: What are the expected results you are personally expected to deliver (accountability)? And, what are the activities and/or tasks you are expected to lead or participate in (responsibility)?

Now let’s revisit the original question:
“What Problem Are You Trying To Solve?”

Typically, the answer to this question is a result. A given outcome. That is your accountability. How you solve this problem is a list of your responsibilities.

I’ll share a quick story that I heard a while ago about a firehouse. Fire fighters were called to a six-story fire that had engulfed an entire building. They doused water on the right side of the building and were focusing on the sixth floor. They got the flames to go out on that floor and had almost won the war on the fifth floor.

All of a sudden the Captain screamed over the radios to stop and move all the way over to the left side of the building and put out a fire on the other side of the sixth floor. The fire fighters were frustrated. They said they just need another minute and the fire on the fifth floor on the right side would be extinguished.

The problem the firemen were trying to solve: Put out the fire.

The problem the Captain was solving:  Save the entire building and make sure the foundation wasn’t becoming brittle by too quickly changing the temperature.

The Project Manager Role

So as a Project Manager what problem are you solving? I believe you are accountable for clear visibility of progress, and enabling effective communication across the project.

Your responsibilities to accomplish these goals might include a Wall Gantt, daily stand ups, daily cycle testing and more. Keep in mind, however, that just performing these activities so you can cross them off your to-do list, does not mean you are being responsible. You still need to get the desired result.

 

How does the accountability vs. responsibility perspective help us understand opportunities for growth?  Let’s start by contrasting the role of the Project Manager with that of the Senior Project Manager.

The Senior Project Manager Role

A Project Manager recently asked me what it would take to get a promotion to Senior Project Manager. What skills would she need to learn and/or demonstrate? What conditions would she need to meet?

In my experience, this kind of conversation for many roles within a company is very common and often painful. This typically turns into a judgmental conversation, determining whether someone is ready to move up to a more senior role. For example, even if they learned a skill, there can be debate as to whether they have demonstrated it to the right level of proficiency.

But wait…

In my conversation with this Project Manager, I used a different approach.  I asked her:

“What problem does a Senior Project Manager solve?”

She answered that Senior Project Managers solve very similar problems to Project Managers. However, they can run larger, more complex projects.

AHA! After her answer, I was finally able to have a healthy conversation about the differences in roles, without the typical pain.

I started explaining that I expect Senior Project Managers to solve the problem of growing the PM organization to target staffing numbers and skill levels. That is their Accountability. They also are accountable to make sure the project delivers the expected results, but the “growing the organization” is something that this Project Manager never considered.

The Senior Project Manager’s responsibilities to grow the organization, I explained, include helping to figure out what gaps exist with the existing organization, how to train and close the gap, what is the required succession strategy for growth, and so on.

When we discussed the Senior Project Manager role in these terms, the Project Manager genuinely appreciated the new view and understood what she should work on. In fact, she said the first thing she needed to spend time on is getting a better understanding of what problems a Senior Project Manager is expected to solve. After she ‘got it’, she could focus on understanding what skills were needed.

This approach can help in any role discussion. For example, in subsequent conversations with developers, it gives us a framework for understanding what it means to be a senior developer or architect. They solve entirely different problems.

Going back to the fireman example, if any fireman ever wanted to get a promotion, they need to understand the problem(s) the Captain solves. It is different than “just putting out a fire”.

If you’ve been thinking about your own role at work lately, how does this perspective help you understand potential opportunities in different roles?

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?

Why Your Change Request Estimates May Be Out Of This World!

PenetrationIn my last post, I talked about why it is critical to have different roles involved in the Change Control process. Failure to include a larger team in change assessment is a common oversight that makes it harder to understand the total impact of a change request.

Staying with the Change Control theme, I see one other challenge that occurs across teams. It may not occur “every time”, but when it does, your estimate for a given change request may be off by orders of magnitude.

 

A typical approach to estimating change requests…

 

When developers receive change requests to estimate, they start by understanding

  • the current functionality that exists,
  • the desired change to this current functionality,
  • the impact of the change and effort to complete the change.

While I know this is over-simplified and obvious, I want to drive into the 3rd bullet, assessing the impact of the change request. I believe most individuals assessing changes do a fairly complete job in assessing the impact. But there is a hidden monster (or pothole) that can destroy the accuracy of an estimate.

Let me illustrate with a quick (and over-simplified) example. I’ll call it …

The Grid

Let’s say your application includes a search screen that allows a user to search through all of the employees in your company.  The search allows you to search for employees by office, region, tenure, etc.

A change request comes through that says they want to be able to hover the mouse over any employee record in the result and display the details in a pop-up bubble.

With a  mock-up of the bubble and a clear understanding of the data, the request seems simple enough.

You estimate the impact of adding this functionality directly to this search might be one to two  days to complete and have ready for business review.

 

 

 

 

Enter the hidden Reuse monster

As it happens, the employee search in this system is reused in several different areas.  One of the areas is the ability for any employee or internal contractor to search for an  employee’s name, office and phone extension.  Because it isn’t obvious that this search is reused when first looking at the code,  you may inadvertently add this functionality to all the areas where  a user  can search for employees!

But WAIT! Do you really want just anyone getting personal details of your employees? You probably only wanted the management group to have this access, right?  So when you add this functionality, you now have either created defects in other areas or  have to “break” the reuse and write this code separately.

For all my architect friends out there, yes there are better solutions to solving this problem. But here is my point:

Many times when estimating what implementing a change would take, we don’t verify that the code involved in the request is not reused elsewhere or that other dependencies exist.

We may do this when making the change, but we need to know this when estimating the change too!

It may impact our own estimate as well as the QA estimate for this change request.

So here’s the quick tip

When estimating for a change request, make sure you estimate the impact this change will have on functional or code reuse. It isn’t always obvious!

Can you think of any recent examples when your change request estimates were out of this world?

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?