A Business Technology Place

Finding spaces with different views

This week my son ended his baseball career after 13 years of playing the game through spring, summer, and fall. Our high school does a nice job with the senior recognition ceremony. It includes a lap around the infield to shake hands and hug the freshman, JV, and returning Varsity players. Then the player meets his family and walks to shake hands with the coaches while a player bio is read over the PA system. Next, a recorded message from the senior is played over the PA system. It’s a message the player leaves for their teammates, coaches, and family. The ceremony ends with each player making one final baseball toss to a family member.

Our school has a volunteer photographer who no longer has a son that plays baseball (8 years removed). He goes to every game home and away. He arrives before the game to take warmup photos and stays until the end. Then he posts probably 900-1,000 photos of each game online for parents and family to download. All of this free of charge. He takes pictures of other high school sports as well.Baseball1

At the end of the year, I was talking to him about the love of the game. Obviously he wants to find ways to stay around game long after his son was a player. It’s personal to him. He told me that taking photographs at the games fills a need in his life. It’s an outlet for a hobby. But on top of that, he told me,

“Taking pictures during the game allows me to find new spaces with different views.”

He is energized by seeing a game from different angles than what a fan sees in the bleachers. He sees the facial expressions of the boys, their body language, the dugout conversations, and even the silly moments. He often captures angles of a play that reveal new insights. His photos capture technique that can be used for instruction and learning. He is constantly probing for new angles and thinking about how to position himself for a different look.

Having an inquisitive nature to find new spaces with different views at work is a trait we all need but few exhibit. In IT and Operations, most attention is given to creating repeatable and predictable processes. Employees are focused on improving efficiencies by incrementally reducing lead times and delivering work faster starting from the same processes. Thinking about different views if often left for the process engineers or visionaries.

But it doesn’t have to be that way.

Just like my friend taking pictures of a game, we can all look for new spaces and different views. But it requires that we fully engage with the subject matter of our work.  It means getting out of our box and thinking about the customer, the equipment, the service, and the people from different angles. It means getting out of our offices and cubes to experience the business from another place. It means using the telephone to hear a customer or colleague instead of emailing them. My friend has to move around to take pictures of the game. He searches for places to stand and examines the view. He takes photos and then examines the results before adjusting to the next angle. That’s the rush of the experience and the involvement with the subject matter. If we aren’t excited about our jobs and careers to do this then it could be we are playing the wrong game.Baseball2

Go find your new space. Stretch out!

Onward and upward!

 

The truth about IT processes.

Part 3 of 3 – The Truth is…. I’ll share some truths about developers, managers, and processes in IT.

Writing about processes in business and technology has a gravitational-like pull.

I’ve written more on the topic of technology processes than any other topic since I began blogging in 2008. Some of my favorites include posts on process improvement, hiding behind processes, simplifying processes, and the purpose of processes. Process management is a topic that we’ll always have because it creates the model and basis for the underlying flow of business transactions. Unfortunately it’s at the forefront as an underlying contributor to some of the dysfunction between IT groups and their partner business functions as well.

I have always aimed to create environments that use processes with the goal to allow employees flexibility to make decisions that help the customer. That statement sounds so obvious that you could say it’s a given. But I don’t think it’s a given because many processes I’ve been a part of in the past seem to be centered on the process itself rather than the customer. My career has been influenced by what I considered overly burdensome processes and watching employees make decisions for the sake of checking-off a process step instead of getting done what needs to happen. Jim Collins in his book “Good to Great: Why Some Companies Make the Leap… and Others Don’t” states that “Bureaucratic cultures arise to compensate for incompetence and lack of discipline, which arise from having the wrong people on the bus.  A culture of discipline involves a duality. On the one hand, it requires people who adhere to a consistent system; yet, on the other hand, it gives people freedom and responsibility within the framework of the system.”

Finding the right mix.

The duality that Collins speaks of is goal I set when I define a process within a group of IT professionals. That’s not easy in an IT group because programmers think in 1s and 0s or black and white. Something is or it isn’t. Here are a few examples:

  • Define a process that sets the criteria for when a work request is treated as a help desk ticket and when it requires review from a steering committee.
  • Define a process that set the criteria for when it is necessary to run a full regression test on a software product.
  • Define a performance management process for how to evaluate desktop/voice services personnel that use a job ticketing system for work management.

Some truths about IT processes.

  • Your opinion about processes from the IT group is highly dependent upon your role in the process. Those that have to follow a process to receive a service tend to try to find ways to take shortcuts. Those that have to follow the process to provide a service tend to like the process because it protects their time commitment and is correlated to their performance ratings.
  • IT processes are influenced by multiple sources. Standards organizations, litigation, process and frameworks are the most common sources. But sometimes processes are created to counteract bad behavior from IT employees and business customers. Processes that continue to add steps to offset bad behavior will lose sight of servicing the customer.
  • Every standards organization believes their process is the best. There are variations to software development lifecycles and spirited debates about what works best. The reality is that business environments and cultures vary. The best processes are the ones that fit and mold to the culture in which they exist and that stay focused on the customer.
  • Most people don’t avoid a process because they don’t believe it will help them. They avoid the process because they think it will take too long to get what they want. It’s the same concept as a driver that intentionally chooses to not get in a traffic line (stop light or interstate backup) and move forward only to cut-in-line later.
  • IT processes, like every other type of business process, exist to create standardized work, efficiency, and quality. They should never be considered complete but only in a state of production that includes measurement to see if adjustments are required.

Onward and upward!

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!

Repeating software processes. To attract and repel.

Are we attracted to repetition?

Yes.  We all are. It touches every facet of our lives. As a few examples, we eat the same types of foods each week, we watch the same TV series, and we read books that belong to a series. A study and report from Alix Spiegel of NPR captures the power of repetition in music that attracts us. Spiegel reports that “90 percent of the music we listen to is music we’ve heard before. We return again and again to our favorite songs, listening over and over to the same musical riffs, which themselves repeat over and over inside the music..” She then gives the result of a study that shows how people preferred music with repetition over the same song without repetition.

Repetition in Software Development.

Software development has the same draw for repetition. Managers spend time and thought to create a software development lifecycle (SDLC) that fits their company culture and team skill sets. They want something repeatable to drive efficiencies of a process, consistency of work output, and reliability of estimates. These are the attractiven features of a SDLC.

There’s an entire business industry built on repetition in software development. Books, training, and consultants feed us new ideas and different ways to think. But the end game they seek is adoption to a standard method that works within the framework of our business culture. This is all for good reason. As a professional in the world of software development, I recognize that we must be disciplined. I recognize that we have to think and find more efficient ways to produce software so that we can stay competitive and drive results through the business.

But there is a repelling force to repetition as well.

There are two danger zones that software managers should consider with repetition in process. Both of these creep-in an organization silently. Ironically they destroy the very things that repetitive process can build.

  1. Repetition can stagnate creativity. When we follow a script, we don’t think much about the ‘why’. We don’t think about better ways to do things. We just follow the process because someone already did all that thinking. Worst of all is that we don’t see it. We think we are accomplishing our job because we followed the steps.
  2. Repetition can become the end goal. When checking the boxes on the process flow becomes more important than the final product then the process has become the master. If employees are consumed with following every detail of a process and only satisfied when they mark steps as complete then the process has become larger than the importance of the end result. You’ll recognize this in an organization when the meetings about the process outnumber the meetings about the solution, the who, and the why.

Watch for it!

Watch for it in your organization and life. It’s like two magnets with forces that attract and repel. We have to find a way to both pursue and guard against the powers of repetition in the workplace. This means constant examination. It means living with shades of gray within process. It means we need write with a pencil, allowing for a both a sharp and dull point. The eraser is nice to have also.  🙂

 

 

Attacking process waste

I don’t like process waste.

Who does? But how many of us really try to change processes to eliminate or reduce waste? In my experience this is a tough topic, and I dare say an unwelcome one, most of the time. The problem is that in an organization processes are tied to job existence and security. So the people in charge of setting the processes and administering them really don’t see the incentive to make adjustments.

I’m nearing my 20th year of software development experience, so I’ve observed and talked to many practitioners about software development process philosophies and techniques. Process waste starts to build when the people within the organizations place more importance on the process steps (requirements, estimates, and schedules) instead of the process output. The ultimate goal of software development is to make money by producing output. Waste takes away from the output.

Business case modeling and estimates are a common area for waste.

Let me start by saying that business case modeling and estimates are a necessary part of software development. The problem arises when the business case and estimates begin to consume a large percentage of the organizations time and a large percentage of the work is rejected. All of the work becomes throw-away because it has not created a return. Ironically the entire point of the business case is to prevent waste. We don’t want our organizations to produce product that does not yield a financial return.

Think about it. If the software development team is constantly estimating and scoping projects that are not approved then it reduces the amount of usable output created for the business.

The theory of constraints is a critical teaching to understand.

The Wikipedia entry for the Theory of constraints quotes Eliyahu Goldratt.

The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput.

In a perfect world, everything the software development team touches is processed into work output that generates money. We don’t live in a perfect world, but we do want the throughput of the system to be optimized. So it should produce money making output as quickly as possible. Work that is started and later thrown out is like throwing away inventory and only increases the overall operational expense of what it takes to get good output.

You have to work the constraint.

I’m a strong advocate that software development needs to focus on features, not projects. Projects are by definition unequal in size and length. Features are smaller in size, easier to understand, quicker to estimate and assist with providing more consistent system output. Bloated projects tend to have large price tags, take weeks to estimate, and are more likely to be rejected by management.

Think about the project approach. A team may spend two weeks creating a business case to review with management. Then the development team spends another two weeks estimating umpteen features. If the project is rejected then there is four weeks of effort that creates $0 of sellable output. The exercise devolves into a discussion about a single cost to build and the the time required to do so. It’s all or nothing and the focus on the goal of making sellable output is lost.

So if we want to work this particular constraint in the system then we need to evaluate each feature on its ability to achieve the end goal. Everything else is really just noise waste.  I hate waste.