Subscribe via RSS Feed

Category: Team Dynamics

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.

Silence is not agreement; Don’t let others hold their breath

speakup2It’s not often, but I believe we have all experienced the meeting that goes too smoothly.

There’s anywhere from four to eight people, trapped with each other for an hour, around our favorite conference table.

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.

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.

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?

Facilitating A Panel Is Not So Different Than Facilitating A Requirements Session

My First AHA Moment of 2012

panel-discussion-150x150Facilitation appears to be a hot topic these days. After blogging about facilitation a few months ago, I am getting many questions about best practices and how to handle certain situations. At the bottom of this post I’ll provide links to my past articles on facilitation that should address many of these questions.

Today I want to share an AHA!

Recently I was invited to speak at an event on the topic of facilitation. One of the other presentations at that conference was a typical panel presentation.

Panels are very common at conferences; they usually have three to four people and a designated moderator who helps facilitate the discussion among the panelists and engages the audience. The session typically runs about 60 minutes.

These panels tend to be very dry (yawn)

For most panels, questions are devised ahead of time and shared with the group so they can prepare their agenda, personal messaging, and so on. I should clarify, that some panels are engaging and are very interesting. But at times, I come across a panel where each person seems to be coming from his or her personal point of view. Their views may not be clearly aligned to the question. So you get someone speaking strategically, while another may be extremely tactical or even not directly speaking to the question.

Let me magnify my point. Each member of the panel will work with the moderator to identify the question(s) they would like to be asked so they can share their viewpoint on a topic. And since three or four different panelists do this as individuals, possibly at separate times, it can be dry, without a clear set of takeaways.

I want to be clear, that there are many panel presentations that are engaging and valuable. But more often than not, I personally find them dry. As an audience member, you are trying to get a grasp of the discussion topics and understand the panelists’ points of view. However the very disparate nature of the moderator’s Q&A prevents engagement between the audience and the panelists.

Changing the dynamic of a panel…

This makes me want to try something new the next time I am invited to be a panel moderator.

I would want the audience to engage more with the panelists on stage. To get more energy, the format of the panel would have to be a little different. We are used to a panelist getting asked a question, then answering their question, followed by each of the other panelists attempting to provide answers to these preset questions which they may or may not have a valuable answer for. Then it starts all over when the next question is thrown out.

With my new approach, after the question is asked, instead of always asking all the other panelists to answer the same question, I will ask the audience members to give their perspective on the panelists’ thoughts. This would raise the engagement level of the audience with the panel.

My job as a panel facilitator would be to facilitate the rhythm of the discussion between the audience and panelists. This means I must meet with the panelists before the conference to create an agenda that would allow us (facilitator and panelists) to agree on a common objective. This would enable the panel discussion’s rhythm to flow more smoothly, be less fragmented, and not break the energy of the room.

I have already outlined in past posts, that the key to the most effective facilitators is that they monitor three things: energy, rhythm and objective of the room. The same can hold true for panel moderators (aha!)

  • Energy in the room: Everyone is engaged, participating and making constant progress toward accomplishing objectives. (For panels: Keep the audience engaged)
  • Rhythm of dialogue: The dialogue flows, but stays focused on the initial goal of the meeting. (For panels: Make sure energy does not get broken by unrelated, fragmented questions)
  • Objective of the room: Make sure the meeting stays on track and accomplishes its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective versus topics that derail the goal.(For panels: Make sure the questions address a common theme)

I think there would be huge value in using these fundamentals when moderating a panel discussion.

When did you last attend a panel that really impressed you and what was so unique about it?

What are your thoughts about changing the dynamic of a panel presentation?

You can find more details on facilitation best practices in my past blog posts here:

They are some of the fundamentals that I present in my regular class on Facilitation Best Practices.

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment below.

Are You Holding Back Your Team’s Success?

Damaged WallRecently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail.  As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike.  I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.

We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked  the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.

We focused on setting ourselves up for success.  And even with all the planning, we still learned a lot about what to do differently on our next day hike.

Learning From the Hike…

I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles.  Or what would have happened  if we only had half our water ration (we used it all).  It would have been one embarrassing, failure of a hike.

This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success.  We may actually be holding our team back from the start.  And because of that, our team  may be digging out from this “team debt” for the majority, if not all, of the project.

Hold Up There

If you don’t agree, let me  give you just two common scenarios  that prove my point:

  • You  are starting a project. The  team is staffed and eager to move forward. The technical team is building out the environment and frameworks.  The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.

This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.

  • Another example: You  are staffing up a project quickly so you can hit a set of aggressive dates for the business.  In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.

While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.

These are just two common examples. You could probably start listing off a couple more.

What Are They Thinking?

So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?

I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.

So What Are We To Do?

I think one of the most basic things we can do in these situations, is to be vocal.  Share your clear and honest explanation of what the cost and impact is.  It is important to be accurate and not embellish or magnify the challenges.

For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01.  Your  goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.

If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22.  This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).

If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.

What do you think?  Have you found other approaches to help set teams up for success?