Subscribe via RSS Feed

Author Archive for Bob Zimmerman

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

Wont-Hold-You-To-ItI have to be honest on this one.  Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate.  I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point  in the future, management gets the  real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way.   How can you go from $100k to $125 or $150k?   Or from two months to almost four months?

And, inevitably,  the creator of the swag estimate is asked,  “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the  first question you have to ask yourself is:  What was management thinking?  When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

  • Go/no-go on a project, or
  • Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
  • Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions.  That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive.  No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks.  I am not looking for a plan with milestones and staffing requirements.  I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you.  Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details.  Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for.  Are they looking to free up resources?  Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%?   Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done.  Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it.  I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan

March 2, 2011 | 1 comment | View Post

Forrester Webinar Uncovers the Ugly Truth About Project Failure

This afternoon, I participated in a webinar with Forrester Research (full recording embedded below).  The turnout was great and, as expected, the energy on this particular topic was high.  After all, who among us hasn’t lived through the pain of project failure?

We spent an hour with Forrester Analyst, Mary Gerush, who shared some valuable insight on why requirements definition is the key to avoiding project failure. Says Mary, requirements “must be a collaborative, business driven approach” in order to get the business what it needs.

Some of Mary’s key points included:

  1. Finding and fixing a software problem after delivery is often 100x more expensive than finding and fixing it during the requirements and design phase.
  2. Slide07-300x225In addition to the financial impact of project failure, the damage done to the entire organization can be brutal:  End users go elsewhere. The trust of your business partners evaporates.  The development team loses confidence.
  3. Business and technology teams struggle to work together for many reasons: Economic challenges; consumer insistence on instant satisfaction; business and technology silos; multi-channel product distribution; third party partnerships; and new integrated environments.  Now we have many stakeholders with varying motivation and needs … often at odds with each other.
  4. Unfortunately, these varied groups of stakeholders may or may not know how to tell you what they need. There’s often a gap between what the stakeholder wants … what the project team has to understand … and what really has to be done.
  5. Business-Technology (BT) partnerships can change this game. A BT approach requires business stakeholders to take ownership of requirements and make the time commitment to be proactively involved.
  6. Business success is all that matters.  Instead of measuring business success in terms of on time/on budget, we should measure it by benefits realization, customer satisfaction and ROI.
  7. Slide23-300x225The BT Requirements life cycle starts by establishing a clear business vision and measuring success in terms of business impact.
  8. Success means recognizing that requirements live before, during and after a project.

When it comes to requirements, I continually emphasize the importance of creating a shared vision of success between the business stakeholders first, and then between business and IT.  When all the business stakeholders agree to exactly what they need, it makes it easier for the development team to deliver it!

We heard in the webinar that in order for the business to get what it wants, it must commit the time to collaborate on the business issues. One of my favorite parts of a project is when the business perspective on success criteria begins to emerge – without geek talk or specifications. This is when everyone involved feels totally confident for the first time that a common vision of success is achievable and will get clearly communicated to the development team.

Within the next couple days, we’ll post a recording of the webinar here. So, come back for a review and feel free to pass it along to your colleagues.

How about your team? How do you keep your business stakeholders committed and engaged in the requirements process?

View the webinar in it’s entirety:

July 13, 2010 | 1 comment | View Post

Is This Obstacle Real? A 4-Step Process to Deal with Obstacles.

This is the second in a two-part series: “Obstacles”

Last week I introduced my approach to increasing a team’s RPM and predictability by identifying and removing obstacles.

Now, let’s go further and look at a four-step approach to help a team effectively deal with the obstacles they uncover.

As a member of a team, you probably see obstacles all the time. You complain and then ask for help. However, when you ask for help, you have to sell others on why this issue should be dealt with. You may very likely be told to “work around it”.

Air Cav infantry Soldiers compete in company challengeSo, once you identify an obstacle, first and foremost:

1. Get a clear consensus that this is truly an OBSTACLE.
Obstacles and issues are different things. Obstacles aren’t risks either. So what is an OBSTACLE? A detriment to success. Something that prevents you from being effective at delivering on a commitment.

Make OBSTACLE a reserved word. Use it only to identify key challenges that need management support in order to remove.

2. Next, clearly identify what the obstacle is.
Is it a procedure that unmistakably interrupts the team’s performance and rhythm? Is it a tool that requires you to do all sorts of work-arounds and forces you to spend eight out of every 40 hours working around it? Is there a person being disruptive because he/she isn’t working on the same problem as the rest of the team?

These are all issues and risks. What makes it uniquely an obstacle, is that you are “working around” these issues and risks and creating unpredictable results. These issues and risks shouldn’t be here. It is reasonable to ask your organization for help in eliminating them so you don’t spend any time on them.

3. Clearly identify what the difference would be if the obstacle is removed.
If the difference is “your day will be better”, you probably did NOT find an obstacle. But, if removing the obstacle allows you to deliver a proof-of-concept two weeks early, then this is tangible and of common value.

4. Finally, directly identify how to successfully eliminate the obstacle.
For example, if this means you no longer need to use the tool – and you can “write your own” – then be clear: We can delete the tool and I do it myself.

If you are the manager of a team that is identifying obstacles, then use the above four steps to clearly test: Is this a real obstacle? Are the benefits of removing the obstacle worth it? How do I support my team?

Let the team deliver for you.
Management’s role is to remove obstacles — not to micro-manage the team. If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

And that is exactly what this blog is about — sharing the different best practices and thought leadership around improving your team’s RPM, helping them become more efficient, and, eventually, more predictable.

I’m excited to participate in a blog devoted to my lifelong passion — making software development predictable. How do you identify, understand and remove obstacles? Do you have results to share? Add your comments below. I’ll be keeping an eye out and look forward to everyone’s contributions and the discussions that follow.

July 6, 2010 | 0 comments | View Post

Dealing With Obstacles That Slow Down Team Performance

This is the first in a two-part series: “Obstacles”

Welcome IT Leaders and Teams. Getting Predictable is a blog devoted to helping leaders and teams jointly develop a no-surprise partnership. We do that with best practices that help us identify, understand and overcome the obstacles that prevent teams from being predictable. This is the first of a two-part introduction about the spirit and mission behind this blog.

3639604882_b2b2ef6fc6_mAre You Being Set Up?

Imagine the reaction if you told your CEO the reason your team was late and over budget on his project was because the team was “set up for failure” … that they didn’t have a reasonable chance of being successful.

In my career, I’ve experienced this dreaded feeling more than I care to admit. In fact, I’ve worked with teams that are continually frustrated because they truly, legitimately feel they are being set up for failure. We’ve all been there. Leadership frustration rises because their teams are always missing schedules or are over budget.  To them, the only thing consistent (or predictable) is the team’s lack of predictability and a steady stream of unwelcomed surprises.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  What (or who)  can we change to fix our team?

Get Set Up for Success

I’ve dedicated most of my career to answering this question … to finding ways to help teams get set up for success rather than failure and to achieve a “no surprise” approach to delivering business value.

The truth is, technology teams are very tired of being told they’re late, spending too much money, or missing the boat when it comes to getting the business want it really needs. When something outside of their control changes, they’re tired of fighting physics and trying to stuff 10lbs of work into a 5lb work-week.  You may have a highly talented team that feels like they are in a no-win situation. What a loss of talent!

Many of us have a passion to find these best practices.  Our drive in this area has yielded some very powerful best practices and rich peer-to-peer discussions that have been truly rewarding for me,  my network and my co-workers.  Now, it’s time these practices are shared and some new ones are learned. Along with other contributors, it’s time to engage in conversation as a technology community … hence, this blog. A blog  devoted to identifying and fixing  the obstacles that prevent our teams from producing their very best.

For starters, let’s paint a picture of obstacles.

Suppose you neglected to change the oil in your car. The oil will get thick and sludgy, right? It affects the performance of the car.  At one point, you determine the problem and you change the oil.

In other words,  you effectively remove the obstacle that is holding back the performance of the car. And by simply removing the obstacle, the entire car, and all its parts now hum at a higher RPM.

Identify the Obstacles

This is what we, as leaders, need to do with our teams. We need to identify obstacles. To do that, we need to listen carefully to the obstacles our teams are pointing out. Then, using best practices, we need to help remove the obstacles, ultimately raising the RPM of our teams.

In my next post, I’ll share a way for a team to identify and communicate obstacles. And I’ll share one way I’ve worked with leadership to remove these obstacles and improve overall team performance and success.

Until next week, I’ll leave you with this:

 

Let the team deliver for you.

One of Management’s most critical roles is to remove obstacles.  If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

What about you? Can you think of any obstacles you wish your leadership would remove from your personal day to day processes?

June 29, 2010 | 0 comments | View Post
« Previous Page