A Business Technology Place

Monkeys on our back

A tribute to the never ending projects.

You know those projects that seem to never end. The projects that extend well past their anticipated delivery dates. The projects that can’t catch a break or that can’t find sustained momentum. These are the projects that become the monkeys on our backs.l-Monkey-on-your-back

My experience is probably not so different from yours. There are projects throughout my professional career that I can describe with words like unlucky, doomed, slow, or unsupported. This isn’t necessarily because people dislike the project objectives. But for whatever reason, these projects stick in the portfolio and start to carry a heavier weight to the team that is involved.

Why do some projects hit their scope, timeline, and budget while others flounder?

I wrestled with this question after a discussion this week about the “monkeys on my back”. Thinking through my project experiences, several common themes were present with projects that failed to meet the original expectations of the stakeholders:

  1. Underestimating the complexity – Team members and/or stakeholders underestimate the complexity required to complete a project. Software projects are prone to this issue if the project team underestimates the complexity of business process flows impacted by the software coding. It’s one thing to change code and make systems talk to each other. It’s another thing to consume the new changes and impact process flows of people and equipment.
  2. Shifting the priorities – When a “more important” project takes team members away from an existing project then momentum is lost and work effort is delayed.
  3. Staffing with the wrong people – Sometimes the wrong people are on the team to complete the job. This could be a skills gap for what is necessary to complete the requirements. But sometimes its about cultural fit between team members. Cultural is influenced by factors such as personalities, temperaments, and ideologies.

There isn’t a one-size-fits all answer to getting the monkey(s) off our back. But knowing why the monkey is there may help us to think of ways to get him off!

What are the origins of the phrase “Monkey on my back”?

I did some brief research and could not pinpoint the origin. If you know or find anything different on this let me know.

The 1854 edition of the Glossary of Northamptonshire Words and Phrases contains this:

“MONKEY. ‘I’ve put your monkey up,’ is a phrase implying, I’ve roused your spirit, or offended you. ‘I’ve put up your back,’ is an equivalent, which see. A child is said to have the monkey on its back, when in ill humour, or out of temper.”

The 1874 edition of the The Slang Dictionary contains this:

“Monkey, spirit or ill temper; ‘to get one’s Monkey up,’ to rouse his passion. A man is said to have his Monkey up or the Monkey on his back, when he is ‘riled,’ or out of temper; this is old, and was probably in allusion originally to the evil spirit which was supposed to lie always present with a man; also under similar circumstances a man is said to have his back or hump up.”

There are other passages where the phrase is used as a reference to being in debt with a mortgage.

In more recent times the phrase is used to describe a heavy burden or even a drug addiction.

This much we do know.  We’d like to get those monkeys off our back. So take some time to think about why they are there. Then see if you can shake them loose.

Onward and upward!

Interactions over Processes (user story template)

The first value statement in the Agile Manifesto is “Individuals and interactions over processes and tools”. Mike McLaughlin, of Version One, questions the role and influence the growing agile tool set has on individuals and interactions. McLaughlin states that the capability of Agile based software tools adds scalability and efficiencies, but that this does not remove the need for team members to interact with each other. His point is that we need to stick to the original intent of the manifesto language. Focus on the interactions, not the process.

It pulls like gravity.
It is human nature to gravitate toward stricter process and away from individuals and interactions. Organizations want to be lean to contain costs. Organizations want processes to provide consistent and efficient deliverables. These forces pull organizations toward larger processes and push employees away from the importance of the human interaction.

In my experience, the downside of a process is that it tends to become the goal of many who follow it. I’ve seen employees feel like they have accomplished their goal simply because they followed the 10 step process and populated the fields on a form. Usually when people reach this point they stop thinking about the people and interactions on the other side of the process.

Recently, a co-worker shared with me that she went to an in-network doctor for a procedure. The doctor chose to use a second medical provider for a part of the medical services. When the insurance company received the claim, they said the second medical provider was out of network, so the insurance company charged a different amount for their services. They penalized the insured as if it was the choice of the insured as to what secondary service the primary doctor chose to use. The process in this case missed the mark of the original intent. But it took over one year of appeals to get a reversal of course from the insurance policy.

A user story.
I recently wrote a project charter to frame-up an upcoming project. I chose a traditional project charter template because the original request for the project work was vague enough that it included a large number of possible outcomes. So I wanted a document format that could aid me with getting clarification for the project goals and better define the boundaries of the project project. To compile the charter I had to interview several business stakeholders to learn about program rules, pricing rules, and system constraints.

I used the project charter as a basis to then move into agile user stories. Now, I’ll be honest. I have not used the agile user story approach previously for requirements gathering. I have created use-cases in the past and user story follows a similar type of approach. But true to the agile manifesto, the user stories put less emphasis on a grand template and more emphasis on a conversation. I like the user story approach because it is setup to get requirement information from a project stakeholder through the use of everyday language. “As a , I want , so that . This type of approach encourages user interaction. It encourages natural dialogue to document requirements.

The result of interactions.
At the end of the user stories, I had a document that showed how the people involved in the project would interact and use a system and what they expected to get from it. To get there I had to interview and interact. Dare I say that’s a good process to follow for software development? 😉

But seriously, I think it steers discussion towards the benefits of the project work and away from the fields in a form. There is a structure to the user story template. But the structure is almost invisible because it adheres to natural language. I wasn’t even aware of the form structure while I conversed with the business stakeholder to gather input. At the end of our discussion, I had a user story. I had an artifact that could be used to begin design and coding. I had experienced the value of the first value statement in the Agile Manifesto.

User Story and Acceptance Criteria

User Story and Acceptance Criteria

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?