A Business Technology Place

Cast the bully out

We have a love-hate relationship with steering committees.

Do committees provide value that pays for the amount of overhead they create in workflows? If you are a committee member with voting privileges then the tendency is to support and agree with the both the decisions and procedural steps the committee follows. If you are a project requestor then your attitude about a steering committee is influenced by the amount of steps involved to get decisions as well as the amount of time it takes to reach a decision.

I have experience as both a committee member and a work requestor. I’ve observed both the value of a committee and the hindrance a committee can insert into workflow. A steering committee creates value when it buffers the amount of work that is given to a technology team to implement. The result of buffering work is protecting the downstream resources from becoming overburdened with too many concurrent tasks. Buffering work also prioritizes the backlog and technology team members want to work on what the business leaders designate as top priorities.

There is usually a bully, or two, that receives all of the attention of the committee.

But you’ve undoubtedly observed a myopic committee as well. There are usually one or two platforms/customers that usually receive top priority or seem get automatic approval. There is usually a direct correlation to the amount of revenue generated by the platform or customer and the committee decision.

Conflict arises when these projects take all available resources such that other projects or customers begin to starve for attention. A significant challenge exists for the employees who represent the smaller platforms and customers to be able to get work done. That’s not a good situation for the anyone. But the committee members feel justified because they have allocated resources to the work that tied to the most revenue.

Cast the bully out.

One way to remove the platform/customer that usually plays trump in the committee is to organize that work team around a hybrid technology model. In the hybrid model the business owner (product manager/customer manager) has day-to-day direction on setting priorities for the technology team. A centralized project management office can track the work backlog and work-in-progress (WIP). The business owner then reviews the WIP at the steering committee meeting to bring visibility and accountability to the direction and decisions of their group. So while the steering committee is not prioritizing work for the decentralized group, they do have visibility and the ability to influence work if needed.

This approach doesn’t work for all platforms and customers because that would mean that there are enough resources to have a dedicated technology team for each platform/customer. It does align the platform/customer work with the business line to promote a more agile approach to work. The business owners that used shared resources no longer get trumped by the bully projects. The bully projects are able to move more quickly because they don’t have the overhead of committee processing. It’s a win-win-win.

Steering Committee Bully

A Marketing Technologist does not fear change

What is an acceptable amount of time that a business process or model is in place before we can challenge the assumptions and basis for it?
Maybe this would be a good exam question in a MBA class. Answers are sure to vary and elicit a number of opinions. But  I would answer that as soon as a process is in place, it’s fair game for challenges. Every day I think about finding more efficient ways to accomplish tasks or even eliminating processes that don’t add value to the goal of the organization.

The most successful process challenges are sourced from measured results. If the results aren’t what we expect then the process is open for modification in an effort to change the results to be more favorable.  That concept seems so simple, but in reality it can be very difficult to execute.

I think the problem is that challenging an existing process or the assumptions that made the process is a bit like challenging the status quo. In many business environments challenging the status quo is akin to “rocking the boat”. It’s considered risky. It could impact baseline business metrics, people, and even the cash flow of the business. Big companies grow to be risk averse and create processes and procedures to minimize risk.

“Named must your fear be before banish it you can.”
Yoda was right. Before we can remove a fear in our life, we must call it by name. Marketing technologists (or really any person in position to challenge assumptions), must be ready to change assumptions, processes, and business model when they have data and results to support the challenge. An essential goal of the technologist is to understand how to deliver better business results for stakeholders by understanding how technology can provide solutions.

The technologist drives new work and solutions within an organization as a result of their everyday actions. The technologist sees patterns and variables in data that may not have previously existed. The technologist finds reasons that customers can’t complete the desired action and proposes ways to remove the barrier(s). The technologist identifies ways to make processes more efficient, regardless of the people involved with the existing process.

“Do or do not. There is no try.”

Three examples from my story.
I find myself with opportunities to challenge existing models each week at work. I’m not always successful in changing the model. Sometimes its because my idea was wrong. Sometimes it’s because others don’t agree with my opinion. Sometimes it’s because others are too busy to listen. But there are times when my challenge succeeds in making a better way. Here are three quick personal examples of challenging the status quo:

  1. In a B2B business model that does not sell direct to consumer the team thought they shouldn’t use sponsored search adwords because that would be considered “direct”. But what if we purchased ad space and sent the consumer to our existing site which honors the B2B contract with the client? It worked and the team found discovered a little about the click-through-rate of branded keywords in search results.
  2. Customer address changes are a touchy topic when you are selling a financial instrument because it can increase the likelihood of fraud. But address changes are part of life. So why not emulate the process followed at bank or credit union when their account holders need to update their address? It worked for my team and provided the single largest increase in customer conversion rates for any software release the team had ever released.
  3. In the early days of the internet I became the product manager for a web site where a customer order resulted in a notification to the call center. The call center would print the notification and then rekey the customer data into the order system. This print-to-key process was ripe for a more efficient method. So I suggested it and a few months later we integrated the web site to the ordering system. Bye-bye paper process.


Are you changing the model?
In the spirit of continuous improvement we all need to look for ways to challenge the processes that govern us. Adjust, measure, and react. I’m not talking about creating change just because some process is old. I’m also not talking about using technology for the sake of technology. I’m talking about using the tools of a technologist to understand how the purpose of the business process and how technology can make it better.

What say you?

Urgency is a two-face

What’s the goal of your organization?
Do this. Ask executives in your business what the goal of the business is. Is it to make market leading products and services? Is it to make and serve customers? Or is it really to make money?

Eliyahu M. Goldratt writes in his book “The Goal” that the goal of the organization “is to increase net profit, while simultaneously increasing both ROI and cash flow, and that’s the equivalent of saying the goal is to make money.”

The business may be about making a particular product or service. But the root goal is to supply money to its stakeholders and employees.

Is there an urgency within the organization to make money?
The farther you go up in the organizational chart the more you’ll find an urgency for making money. It’s sensible, because the higher the position the more responsibility it has for delivering results. Delivering financial results is directly correlated to keeping a job.

Yet you won’t find this same urgency in the lowest ranking levels of the organization. Those at the bottom of the organization are tasked with following procedures, gaining approvals, and struggling against organizational entropy. The processes we make, though well intentioned, often become the focus and goal of the rank-and-file. Getting through the day is not about making money, but about getting an approval and checking a box.

Urgency and bloated processes clash.
Let’s face it. Processes, by nature, grow with the aim of filling something that is missing. When something goes wrong human nature is to insert a new step so it doesn’t happen again. The process grows to try to cover it’s own inadequacies. Before long processes become filled with redundant and unnecessary steps. The irony is the process grows to account for exceptions and errors, but not to achieve the original goal.

Workers are rewarded for following all the steps and they soon find comfort and protection in the process. So it makes sense that the focus of the workers is on the process, not making money for the organization.

There should be an urgency to streamlining processes.
I’m not saying to abandon process and created an unstructured environment of work output. All organizations need some type of process to help create consistent work output at regular time intervals. Process is necessary. But leaders all the way up to the C-suite need to develop an urgency in keeping processes lean and focused on the goal. Help workers deliver more consistent work by making sure they are empowered and enabled to do the work efficiently.

Urgency comes from the top.
If an organization is to change it’s mindset about processes, it needs to come from the top. Management expectations do cascade downward. But if upper management is only concerned about the urgency of making money and not looking at how the organization can make it through operations, then inevitably the organization won’t make the money fast enough.

So spend some time thinking about current processes. Remove steps that don’t directly move work towards output. Remove redundant steps. Identify system bottlenecks, whether people or process, and determine how to alleviate it.

Am I missing something here? I just see big business has a big appetite for making money. But it can’t move fast enough because it trips over itself. So where is the urgency in that?

Are you hiding behind the process?

Some people depend on the process for making results.
I was involved in a situation recently where a software defect was found after the production release. A team member was quick to analyze the situation and indicated that the team had not followed all the steps in the process. They stated that this resulted in increased risk and was the root cause of the defect.

Don’t be afraid to fail.
It appeared to me that their behavior was driven from a fear of failure which often results in blame. If we work in environments that place blame for failures then how do we expect people to learn and correct mistakes? How do we expect them to operate at peak efficiency if they are focused more on the consequences of failure than they are on the results of succeeding?

I talked to the team member and their manager and explained that risk of defects and failures was part of the business of software development.  The particular change that our team implemented was low risk to begin with and the defect discovered was not disruptive to the financial aspects of the site. The decision to by-pass the full process was made based on reduced risk for the change and the potential financial return.

I had a similar conversation with my son about hitting a baseball.
If a baseball hitter has a batting average of .333 (one hit in every three at bats) it’s considered great. Think about that, that means the hitter fails two times every three at bats. Now, I understand trying to compare software development to baseball is like comparing apples to oranges. But it’s not the failure rate that I’m comparing; rather it’s the mindset of failure. A baseball hitter must approach batting with mindset of hitting the ball, not a mindset of swinging to prevent missing the ball. The same holds true for the software developers and testers. They should approach their profession with a mindset solving problems, not a mindset of being afraid of creating problems (defects).

It’s really all about focus.
Focus on the goal, the prize, and solving a problem. Don’t focus on not failing. The processes that organizations define exist to establish a consistent discipline to create a product or service. Problems arise when team members place more weight on following the process than on solving the problem. Don’t let the process becomes the focus and checking-off the steps the objective. That’s hiding behind the process.

A better way is to use the process as a guide for discipline. It helps to promote communication, consistency of purpose, and above all solving the real problem.

Be ye not afraid to challenge old ways

This past week I challenged a couple of existing business processes. One thing that I’ve never understood about business environments is why people and management continue to require and support processes that don’t add value to the service and production output of the organization.  I think most people prefer to not create waves and find it easier to just stay within the predefined boundaries that are set for them.

Challenging a process doesn’t mean we are against the team

If I challenge a process, something I try to convey right-away is that I’m against the team or trying to discredit anyone on the team. Asking questions such as “why are we doing this?” or “could this be done more efficiently?” are purposeful and intentional to create a conversation. The irony is that challenging the business process is really about making the team stronger. Make sure challenges are respectful and keep the conversation focused on the process and the results, not people.

Influencing factors for business processes change over time

Business processes are created at a point in time and many elements influence how and why those processes are created. The size of the organization, the functional departments, government regulations, audit requirements, GAAP rules, technology capability are a few factors that come to mind. Look at that this again and think how many of those factors are subject to change from one year to the next. They all can. A changing environment can lead to a fertile field for business process change.

Recognize other ideas, it’s at the core of the challenge

The very nature of a challenge to a process is that it introduces new ideas. If we are challenging something, then we need to be open to alternate ideas. The conversation we create should explore our own ideas and invite others ideas as well.  Remember, the end goal is more important than any one idea. It’s all about the value to the customer.