A Business Technology Place

Visual Management Board for Lean IT

A note from my Lean journey

A few years ago I was introduced to Lean concepts and principles at work. After several months of studying the topic I realized that many of my professional activities for both managing processes and people already mapped to some of the core components of Lean. That makes sense as many of the leading management philosophies and programs of our time share foundational elements.

One of the important principles of a Lean is visual management.  Visual controls are used to communicate information to people that indicate if the current condition of a system is acceptable. The Toyota Production System says to use visual controls so that no problems are hidden. It’s like the old phrase, “you can’t fix what you can’t see.”

On my personal Lean journey, my next task is to develop a Flow and Performance Board.  This will be a form of visual management that displays information to use at recurring team meetings. The contents on the board support the Lean principles of continuous flow and reducing waste. Effectively, the board becomes a visual control to see how flow of product is progressing for customer value-added activities and where waste exists in the system.

Flow and Performance for IT – My 1.0 version

I used the following guiding principles when designing the 1.0 version of a Flow and Performance Board for my IT shop:

  1. Show elements of product flow – At what stage work is in the system.
  2. Show key metrics – If possible show actual vs expected. The focus of the board, and Lean, is process flow and eliminating waste (as opposed to traditional boards that focus only on results).
  3. Show flow influencers – These are items that may influence the production system such as holidays and customer audits. The intent is to make the influencers visible ahead of time so it’s possible to manage through them instead of reacting to them.
  4. Show audit results – Part of the Lean journey is having leaders that inspect our work to see if we are following standard process. IT also has a rapidly growing set of requirements for compliance, which customers require, that fits in this space.

My 1.0 version of a board looks like this:

Since IT team members are geographically dispersed and most of our tools report data electronically then this will be an electronic board. Content will vary for different groups within IT. My first board is targeted towards and enterprise level view.

The board is intended to be referenced during recurring team meetings so that team members have a visual control as they inspect pieces of the product flow. As such, it should be easy to read and process information. The contents of the board must be current to be relevant. Ideally the board will updated dynamically to reduce the amount of non value-add work of administrative processes.

I anticipate I will wrestle with screen real-estate, content, and compactness with each future iteration.

Onward and Upward!

Rethink boarding airplanes

I don’t travel on airplanes often. For me this is a good thing. The airport routines of parking, security checkpoints, boarding, and rental cars typically leave me feeling like herded cattle. For the most part, all the players involved in each of these steps do a good job moving masses of people onto the next station. But this past week I was reminded about one of the peculiarities of air travel that makes me ask wonder why doesn’t someone change this.

The airplane boarding process

My experience:

  • About 20 minutes prior to the first call passengers start forming a mass of people near the gate to board the plane.
  • First call is for those needing extra assistance or time to board.
  • Second call is for families traveling with small children.
  • Third call is for the premium cabin ticketed passengers.
  • Fourth call is for priority status members.
  • Fifth call and subsequent is for zone boarding.

Here’s how all the major carriers approach boarding an airplane. There is no consistent method.

The result is a long line on the jet way that extends into the main cabin. The line constantly stops when the lead person puts their carry-on into the overhead storage. Then the flight crew usually comes on the overhead and starts fussing at the passengers that in order to make an on-time departure they need passengers to sit in their seats.

“It’s really a chaotic random mess where you don’t get the same results twice. Airline employees shouldn’t be griping at passengers about boarding when they use a process setup to achieve random results.”

There has to be a better way.

Ask why.

I started asking myself why is it this way and why do the airlines let the process exist like this.

Now remember, I don’t travel frequently. But this is what I observe:

  1. There is not enough overhead storage space to fit all the carry-on luggage/personal bags. Passengers are incented to want to board the plane first to get overhead storage.
  2. Many carriers are not charging additional fees to check luggage which makes more passengers carry bags for boarding.
  3. The carriers want to reward loyal passengers and those paying the highest fares with perks so they create priority boarding zones.

I’m just sayin’.

I believe the root cause for all this is the lack of overhead storage.

“What if every seat had an assigned cubby for storing carry-on baggage?”

Imagine if every passenger is guaranteed a spot for their extra personal item. This accomplishes several things:

  1. Carriers could use a process where the plan is boarded from the back to the front. This would minimize the delay caused by passengers stopping in the aisle to store their bags while others who are sitting behind them wait.
  2. Passengers would know exactly where their baggage is to be placed instead of randomly choosing a location. That will speed the process of baggage storage.
  3. It would alleviate the need for passengers to congregate at the boarding counter in an attempt to get on the plane ‘first’ because they know they have a guaranteed spot for their luggage.
  4. Quicker boarding times would increase on-time departures.

Certainly there would still be exceptions. Passengers needing extra time to board (handicap, elderly, families with small children, etc.)

You say it’s not possible.

That’s not possible. There isn’t enough space on the plane to do this. The carriers need to maximize the number of seats to maximize revenue per flight. There is considerable investment in existing fleets that don’t have this.

Engineers can solve this problem. We put a man on the moon and you’re telling me we can’t figure out how to create storage for every seat on an airplane? Sure there would be some trade-offs. Maybe it means losing a couple of rows of seats. Maybe it means finding ways to store luggage in addition to overhead bins. Maybe it means enforcing the maximum size of carry-on luggage. It is possible.

Air travel carriers would have to decide it is important and then work with equipment manufactures to make the investment to change.  The opportunity is there for someone.

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!

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