Subscribe via RSS Feed

Tag: "performance"

Is Your Software Development Team Set Up for Failure?

Obstacle - Man Jumping Over Word on ArrowI talk to CIOs all the time and I can tell you that there is one common concern keeping them up at night:  Am I getting the best RPM out of my team? Often the answer is no.

Unfortunately, many of the teams I’ve worked with are continually frustrated because they truly, legitimately feel they are being set up for failure. They’re 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.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  Who or what can we change to fix our team? If these concerns are on your mind, I highly recommend taking a look at my white paper: “Doing More with Less – Best Practices for Processes, People and Metrics.”

This whitepaper will help you identify opportunities for optimization based on your specific organization, business situation and culture. Some of the concerns I address:

  • Is your methodology getting predictable, repeatable results?
  • Do you have legacy practices and tools that actually hinder performance?
  • Are the right “heads” in the right “hats”?
  • Is everyone on the same page as to who owns the success criteria for projects?
  • Are you tracking the things that make a difference to the business?
  • Are metrics visible and “common” across IT and business?

This white paper will get you started in one of the most critical roles you have: Removing 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.

Please take a look at this white paper as soon as you can and feel free to post your comments right here.

Geneca Whitepaper – Doing More with Less

CEO for a Day

A Simple Decision Making Tool: What if I Were CEO for the Day?

CEO-for-a-DaySometimes I find myself thinking inside the box too much. I automatically enforce rules and behaviors based on what I believe an organization would do as opposed to what it actually could do in a situation. For example, it is easy to think that your company would never “buy in” to your idea and execute them. You may think that there is no time, no resources or no to a whole bunch of other things.

The truth is what a company does or does not do is usually up to people like you.  A good idea is hard to beat down. The difficulty is finding the mindset to help break out of our everyday self-imposed box. I have a technique I use called “What if I were the CEO”.


If you were “King for a Day”, you might not have to answer to others and face fewer challengers. This is not necessarily a helpful decision making perspective.   Unlike the King, the CEO has owners, internal staff and external staff to answer to on a daily basis and is always dealing with repercussions. However, the CEO can still help steer a company to start a new initiative and execute on the “right idea” at the “right time”. For a decision-making perspective, I like to look at something and ask, “If I were the CEO, how would I consider this problem? Could I direct some of the company’s resources to make it happen?”

I give you a mythical instance. Say you work at a custom software development company and your client (who has been a long-term partner) wants something done in less than a month. Although you think it should take six weeks, the client is coming to you with that expectation. Do you agree to the gig, try to find a way to solve the problem, and then tell them “Hey, it will actually be six weeks the way we have it planned — or we could do two weeks with half functionality.”

Or do you sit back and really try to make sure you are thinking about all of the opportunities. If you were the CEO, is this client worth more than the standard answer? Will this affect your reputation as a business? Can this be more than a vendor relationship? Is this really the business you are in and not something that got mangled in the sales process?

Now, you are truly looking at all of the options. What if you could shrink the schedule by adding more people even if it was on your own dime? (Mythical Man Month people get in that line over there, but some problems can be addressed with man power if you manage and architect correctly.) Can you do that with more people, different people, partnering with another firm, working in a completely new way to achieve the outcome? Do you contemplate redefining the engagement with the client as a true partner between businesses as opposed to a transaction? What would you learn? What options might this create?

Thinking along these lines has helped to remove my own mental obstacles. It generates creativity without irresponsibility. The goal is to come up with more than just the standard answers and then see if you can validate them with your client and your management. But what if you acted like you were CEO for today?  Could you make a difference?

The Predictable Mindset Test by Geneca

20 Questions Every Software Development Professional Should Ask

Pencil-Pot-Dave-NicholasDo you have a predictable mindset? That is, can you consistently deliver without surprises?

Some teams deliver on time or on budget, but this alone is not predictability. Being able to deliver exactly what the business needs with no surprises each and every time — that’s a predictable mindset.

Whether you take this self-assessment test alone or with your team, take it with an open mind and be brutally honest with yourself. Your score will tell you how well your team is set up for success. Answer each of the questions either “TRUE” or “FALSE.”

Note: If you’d like to take this test online and have your score calculated for you, visit:

Relationship With the Business T F
I won’t start a project until the business stakeholders can clearly articulate their objectives for the project.
I am confident that the business stakeholders on my project are in sync with each other on the organization’s strategic business objectives.
I make it a priority that my entire team understands the strategic business objectives for the project.
I make sure that everyone on my team knows when their part of the project satisfies the organization’s business objectives.

A “common vision” of success with the business goes way beyond sharing the same status reports. Predictability requires practices that get different business areas on the same page with regard to organizational goals. These goals must be clearly articulated to the delivery team and serve as their compass.

Clearly Defined Roles & Responsibilities T F
I look to the business to define what needs to be in the project solution.
I make sure everyone on my team understands the roles and accountabilities of the project.
I hold my technical teams accountable for determining the effort to deliver the solution.
I have a single point of accountability for ensuring that the capabilities required by the business are delivered.
I have a single point of accountability for the design and performance of the technical solution.
My project managers are accountable for escalating material changes to the health of a project as soon as they know about it.

For many organizations, clarity around roles and accountabilities is frequently an underlying source of project frustration and even failure. Even the slightest ambiguity here can hurt an entire team’s ability to perform. When responsibilities are clear, our colleagues can drive forward, deliver, and truly create a win for themselves and their team. Ensure you have individuals taking pride in their pillar of delivery: technology, functionality, quality, and leadership.
Predictability happens when the business is held accountable to “define” its need and IT is accountable for delivering a solution that supports it.

Defining Requirements T F
I make sure that requirements are built interactively (with the business) and driven by dialog between ‘us’ and the business.
I always discuss with the business what functionality must be in the first release, using their definition of success as the key criterion.
I make sure project estimates are based on a thorough analysis of how required business capabilities are translated to technical components.
I am always crystal clear with the business about what is out of scope.
I make certain that my team is committed to the project schedule based on a clear understanding of scope.

Before specification begins, ensure your requirements are defined. In other words, Business and IT have worked together to establish the goals of the project and agree on what is and is not in scope. The business can take ownership of the technical estimation when components are in their language and clearly tied to business outcomes.

Managing Requirements & Changes T F
My project team manages change in terms of how it affects revisions to business functionality.
I make sure that the business stakeholders understand the relationship between change requests and the effort needed to make those changes.
I make sure that Quality Assurance and User Acceptance play a role throughout development – not just at the end of a project.

When Business and IT have defined requirements and have worked together on estimates, they no longer feel scope management is done to them. Important decisions around change can be made smartly together.

Metrics that Make Sense to the Business T F
I make sure that my team has a common, transparent method for communicating progress for all project stakeholders … before development begins.
I make sure that project status reports show progress in terms of the business capabilities promised.

When the project is done, it is the business functionality that matters. So why should progress be measured and reported any other way? Agree on milestones and how progress is to be reported, before that reporting begins.

Score Interpretation: Give yourself five points for each TRUE answer and add up your score.

80+ Outstanding. You’re doing a number of great things to set your teams up for success and predictability deliver business value.

60+ Good. Refinement of your requirements processes, people roles, and metrics should eliminate any unexpected occurrences that interfere with your success.

<60 Poor. You are likely finding that your teams are not working predictably. It’s time to take a close, hard look at the obstacles that are interfering with the success of which your teams are capable.

If your score wasn’t what you hoped, the good news is that predictability is “learned behavior” and can be managed like a process with clearly defined best practices, roles and responsibilities, and performance metrics that make sense to all the players.

Take the test. Let us know if these questions stir up some new ways to improve your team’s performance.

If you’d like to refer colleagues to the test, you can pass along the link to this post, or to our Predictable Mindset test online at:

Photo Credit: David Nicholas

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.

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?