The end of the birthday tax in Georgia (House Bill 386)

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

My birthday is coming up next month and that means I get to pay the annual birthday tax, also known as the automobile ad valorem tax. The Georgia vehicle ad valorem tax is combined with the annual tag fee each year. This year I received a notification in the bill regarding new legislation passed in the 2012 Georgia General Assembly.

Effective March 1, 2013, House Bill 386 removes the sales tax and the annual ad valorem tax on newly -purchased vehicles. It replaces these taxes with a new title tax of 6.5% in 2013 and 6.75% in 2014.

For existing vehicles, the owner will continue to pay the annual ad valorem tax. The new tax phases in each time a vehicle is sold, whether used or new. But wait there’s more. The basis for the new title tax is the fair market value of the vehicle, not the sales price.

My interpretation of this legislation is that it accomplishes two things:

1. It puts automobile private sales on par with sales from a dealer. An advantage that private sales have today is that they there is no sales tax with the transaction. At 6% in Georgia, that’s $600 of sales tax for every $10,000 in a sales price. In the new system, all vehicle sales pay an equal tax and you can’t get around it by selling your family members an automobile for under market value. Dealers will surely like this and my guess is they were part of the lobby to pass the legislation. It undoubtedly creates more tax revenue as well because it captures invisible private sales.

2. It gives the tax authority more cash flow because they are collecting a larger amount of money for the vehicle up front rather than spreading the tax collection out over many years. For vehicle owners that like to trade their car every four or five years this means they will pay more tax than they would under the current ad valorem tax rules. On the flip side if people keep their vehicles for an extended period of time they could pay less tax. It’s a math game and quite a clever move by government.

The Bottom line is that this move is sure to help the government’s bottom line more than mine. But at least I won’t get taxed on my birthday any longer after I sell and repurchase different vehicles.

 

 

 

Reducing work-in-progress for software development

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

One of the important concepts of the Theory of Constraints is to reduce the amount of inventory in a system to help with the overall goal of increasing the rate of throughput of the system. Inventory is defined as the money that the system has invested in purchasing things that it intends to sell. In software development, inventory is things like software licenses, equipment, or even process artifacts that comprise the components of a release.

The typical start of software development processes is to estimate requests for business stakeholders. The requestor wants an estimate of cost and time while the software manager needs the estimate for planning people allocation, time, etc. Once labor is expended on the estimation effort and some type of answer is generated then the system has a level of inventory in it (the estimate becomes an artifact and money is spent to generate it).

If the request is rejected at this point it becomes process waste because money was spent that will have no investment return (although better to spend a little money early than to realize you need to cancel later). If the request is moved into a queue that awaits the next step in the process then it becomes inventory. The problem arises when the requests hit the process bottleneck and start to queue. The work-in-progress  becomes a growing inventory which extends the time before the company can start to realize a return on their investment.

A growing inventory of estimated work in queue
A growing inventory of estimated work in queue

Thinking back to the Theory of Constraints, we want to reduce the amount of inventory in the system. One way to do this is to control the rate at which requests are released for the initial estimating step. Instead of estimating every request that enters the system and then placing the estimated effort on the backlog, we can place new requests into the product backlog. The product manager is responsible for prioritizing the backlog based on the business value, not cost. Then when the team is ready to start working on a request the product owner and the team work to estimate the scope of work of the top items on the backlog. Think of it as pulling the top x items off a shelf. The idea is to pull as many items of the top of the list that the team can fit into one cycle of the software machine (an agile sprint).

This technique closely mirrors the agile methodology of Scrum. I like it, because it also helps to reduce the inventory in the software machine and works towards delivering software for an earlier return on investment to the business. The product backlog acts as a buffering mechanism to control the release of work into the system.

Work queues outside the software machine (buffer) to reduce inventory
Work queues outside the software machine (buffer) to reduce inventory

Do more with less by working smarter

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

I haven’t kept count of the most commonly used phrases I’ve heard in my professional career. But “limited resources” has to be at the top and this phrase talks about people more than objects. It’s a given that there is always more work that businesses want to do than they feel like they can accomplish with the current number of people. If that were not the case then the business would let go of people to match capacity with demand.Resource Constraints

In my experience, most business leaders typically approach resource constraints by trying to hire more people or by ignoring the situation and letting the day-to-day tasks run as-is. Hiring more people is a difficult battle in most businesses and ignoring the situation certainly doesn’t provide answers.

I try to approach resource constraints by examining the underlying processes of how people work. Maybe I’m wired differently and don’t mind examining processes to find opportunties for improvement. Maybe I don’t mind fighting the battle of getting people to change existing processes. But if an organization is to work smarter, then it must examine underlying processes and not be afraid to make adjustments.

In the book Blue Ocean Strategy, Kim and Mauborgne describe this technique:

“instead of getting more resources, tipping point leaders concentrate on multiplying the value of the resources they have.”

The Theory of Constraints looks at the underlying process as well. This management paradigm teaches us to first find the constraint within a process and then to exploit the constraint by shifting resources, managing work queues, and possibly adding capacity.

At the end of the day, changing existing processes within an organization can be as difficult as justifying new hiring. But I would argue that it’s a more worthwhile endeavor. Throwing more people at some problems might provide a brute force solution. But the underlying process will eventually bog down the productive output and you’ll soon here again the infamous phrase “resource constraint”.

Find a way to multiply the value of what you have by first examining the underlying process for inefficiencies and also by making sure that underlying processes contribute to the overall goal of the organization. Easier said than done, but if it were easy then everyone would do it.

Thinking about predictable software development

I was talking with a mentor this week about software development and the challenges of aligning IT ideals with business expectations. From a high level we agreed that the purpose of the software development process should be to produce software that generates monetary value, by revenue increase or cost decrease, for the business. That’s really just stating alignment with the goal of the business and may seem obvious. Yet in reality, people tend to drift towards different goals for software development. That’s what creates misalignment between stakeholders and often results in inconsistent output.

One of the key principles that he wanted me to take-away was that the production of software should be predictable. A definition of predictable is “behaving or occurring in a way that is expected.” So what do business owners expect from software development? What do IT owners expect?

In my experience, an IT group tends to define predictable software through quality measures. There is a heavy emphasis on requirements to create a detailed specification with the goal that the software will do exactly what the business stakeholder requests. But business stakeholders tend to define predictability in terms of the cadence of the output. They want to have a comfort level of when something will be produced that solves a problem for a customer and ultimately generates revenue for the company.

Are the metrics of a predictable cadence and predictable quality incongruent? I don’t think so. But to achieve predictability with both of these attributes requires a different mindset from all the team members. It means that requirements may not be defined exactly according to a specification. It means software output may take multiple iterations or not be exactly right the first time. Are business leaders and IT leaders willing to live with that level of inexactness?

And does it seem counter intuitive that inexactness can provide predictability? It’s a mindset change. But I remind myself that satisfying predictability is also not the goal. It’s a means to achieve the goal to produce working software that sells and provides a monetary value for the company. That’s something everyone expects.

Those two big things

I watched Groundhog Day (Bill Murray and Andie MacDowell) with the kids to start 2013. I remember watching the movie when it was in the theaters. My birthday is February 2, so naturally the movie was a must see. I hated it when I first saw it. The movie script finally annoyed me about ½  of the way through. I think I was annoyed by the time loop as much as the main character Phil Connors.

Are driving your life in the right direction?
Are driving your life in the right direction?

But watching the movie again tonight, almost 20 years later, I had a different perspective. I told the kids that Phil was reliving the day until he got it right. Phil ends his time loop when he realizes he needs to improve himself by helping others through service and by continually learning more.

That sounds like a good recipe for a new beginning and a new year. Better than resolutions, which we may forget by the end of January, is a more fundamental goal to continue learning and to serve others. If you’re like me, your best memories and your most important interpersonal growth come from learning and service events.

“What would you do if you were stuck in one place and every day was exactly the same, and nothing that you did mattered?”

Don’t sit still. It’s 6am, and a new year. Go make yourself better.