Gestalt Thinking and The IT Department

gestaltLast week I spoke to someone who was doing some consulting work at an international school. They were trying to assess what was causing the various problems. It was not money or resources. It seemed the administration was trying to make things work. So as we began to speak she asked me a few questions about the organizational structure. I gave her a very clear answer and opinion. She told me what I told her was contrary to every other person she has interviewed about these problems.

I told her I firmly believed that if a school can support and afford it, the technology structure should be formally defined as Educational Technology (EdTech) and Business & Operations (BusOps).

I told her that certain plans and projects should fall into each of those divisions and be managed according to strategic plans and initiatives. In other words, the IT Department needs a clear focus, people need to know their main roles, and the regular school administration should be involved in tracking and accounting for the IT projects.

If a school cannot afford the staffing to support a real separation, then the policies in procedures governing the IT department should clearly define priorities, standards, and
any and all division of work.

In my current role I have a 70 page policy manual that is growing. It will soon be, after much debate, split into an EdTech/BusOps model. Various types of projects will start to be filtered directly to people who can do those projects autonomously, because those projects were planned and budgeted.

Does this mean as a department we will never meet and plan? No. It means after we meet and plan with the school administration, we each should be able to do our work with some oversight. I ask for oversight all the time from the network engineer, and he asks for my oversight on projects that impact the classroom. As a team we make timelines, we debate over priorities and resources, and we constantly allocate jobs to each other.

However, when the year is coming to a close, and it is time to reflect, we have projects that each group of people has completed or failed to complete. We can report on issues related to EdTech separately from issues related to BusOps.

But here is the problem, and I know this all too well because I use to be “the problem”. I was the IT coordinator and integration specialist who would blame the IT engineers and support staff for everything. I accused them of not being diligent and focused. I believed they did not care. I saw them as the weak link, and eventually I took it upon myself to manage them from that perspective.

It worked. Things seemed to be better and more organized, but there was a huge downside. Firstly, I was still completely dependent on them for supporting the school, I could not actually do all the work alone. Secondly, they were so afraid to make mistakes that I could not expand the technology past a certain point.

So I had to change. The first thing I had to do was listen. I found that these people had not always been the way they were. They had been marginalised, blamed for issues they predicted but were unable to resolve due to funding, and no one had given them any sort of additional training or time to pursue learning.

Of all these things, the last one I consider nearly insane. I do at least 6 weeks worth of training a year just to stay even, if I want to really grow, I need a solid 8-12 weeks of training. I do this mostly on my own time and spread the training over the entire year. My contract allows for professional development, and in the past, my contract also allowed for professional development. The engineers and IT support people were allotted nothing. No time. No training. How could they improve?

The next move I made was to make a list of everything they had done, and done well.
I clearly started communicating these things to everyone, and in every way I could. I wanted them to be able to own projects and successes as individuals in a department.

Finally, I started telling teachers and staff to back-off. No more verbal demands. No more undocumented communication. No more narratives about slow internet. I made reporting issues a formal non-email process, and jobs were assigned based-on skill set and location. If we were short staffed, everyone did their best to cover any and all jobs.

Essentially, I split the department by separating the projects and responsibilities.  I was able to see who had skills that needed development, and I planned and funded professional development for the team.

The end result was also a huge policy manual and a smooth running department that could walk into a problem and walk out with a plan.

This was along time ago, but I still follow the same practices. A team should be able to do things that are greater than the sum of the individuals’ qualifications.

Plan. Budget. Divide. Conquer.

Tony DePrato

Rants on Accounting Part 1: Flat Terms are Flat Tires

Flat Terms, is a TERM I use to describe the policy of telling everyone that all bills will be paid within a certain time frame from the delivery date. For example, if I ask for 90 Day terms on Apple Laptops, and then vendor delivers on August 1st, then they can expect a check from me on November 1st.  It does not matter if I buy 1 laptop or 200, the terms are flat.

I suppose in some businesses this might work, but in a business focused on revenue generated from tuition cycles and application fees, this is not only a bad model, it is a lose-lose model most of the time for everyone involved.

Classic game theory teaches us the setting up a win-win or win-mostly win situation is always important. Suppliers have be considered in the game as allies, not enemies. Alienating them by repeatedly hurting their cash flow is not a good idea. Suppliers are finite for most things, and by reducing them down to smaller numbers (sometimes that number is 1) a dependence is created which will turn into an exchange of fists and elbows instead of an exchange for goods and services. Not only that a false monopoly could occur in the favor of the vendor.

The ideal situation for purchasing things, especially IT gear and software, would be to have an approved cash reserve with target dates. The idea being that a percentage of the budget would be set aside and spending would be conducted during targeted intervals using cash on delivery and/or wire transfers for the majority of purchases. This gives the buyer the most power and leverage. The policy allows for larger stocks of slightly older gear to be purchased resulting in a net savings against the budget.

In a perfect world the revenue cycle of the institution would determine when spending can start and when it must stop to avoid carrying outstanding payments and damaging credit and credibility, the latter often being more important.

The concept that all vendors should be pushed to the same payment terms for every transaction is mathematically unsound. Terms should be determined based-on the size of the order and the date the goods need to be delivered.

For example, it is November 1st. 95% of all tuition has been processed. I need to buy a quantity of 100 laptops from Apple. The Apple vendor will offer me an additional 10% on new stock and a 20% discount on stock in their warehouse if I can pay the full amount within 30 days.

Based-on the math, and the fact I have money available, it would be insane to insist on terms longer than 30 days. I am going to save money in the budget on a significant order.

Now assume the same purchase needs to be made, but it is May 1st. Tuition notices have just gone out, and 60% of all revenue I might have is going towards salaries and summer expenses for renovations etc.  In this case, I would have to decline the offer. I am focusing on the revenue cycle and the size of the savings, and not the flat concept that every purchase is equal.

Now look at something completely different, a niche product like a large streaming server. I am never going to really save on a single product. It will always cost about the same all year. So how do I decide the terms?  Well looking at the whole relationship with the vendor I might be able to tell them, “We are spending money with you in November on 100 laptops with terms of 30 days plus discounts. So we would like to pay for this server at that time, full price of course.”

I am considering the whole games, and trying to leverage a large purchase to get an early acquisition on niche product. Ignoring the game for one significant play is a mistake.

An accountant might claim this is hard to manage because there are SO MANY VENDORS. In fact I have found that most schools rely on a small number of vendors for the majority of their purchases. The policies used should be based-on reality and not on a textbook version of purchasing.

Keep in mind that if you get what you want within your budget, or with net savings, you win. If the vendor gets paid ON-TIME and gets more orders in the future they win. However, if you apply FLAT TERMS during the entire school year then orders due May 1st will probably not get paid until August.

This means you have created a policy that hurts vendors, and in the fall when you need orders quickly, you will find vendors have very little sympathy. All the past orders will have to be paid before anything else is even processed. In some cases equipment and services would not be received until November or December.

Teachers and students need resources when school starts, not half way into the year. Accounting should not be undermining educational initiatives with inefficiency that is not saving money.

In PART 2, there will be more of a focus on the revenue cycle and how it should be a cornerstone of all conversations and decisions.

Tony DePrato