Monday, December 12, 2011

Planning and budgeting

(A story about personal responsibility)

The process of planning and budgeting has always made sense to me even long before I had a leadership role. I understood the need for planning and budgeting at work and in my personal life. Over the last few years we have implemented a process of planning out the number of hours it will take to complete each initiative at budgeting time. This allows us to make sure we have the hours for any project we have the dollars for and vice versa.

I have resisted this process from day one, and did it only under noted objections. Don’t get me wrong I truly understand and believe in the value of this planning. I just felt like with what I knew about my customers they would take this the wrong way. That as soon as I gave them an estimate based on almost no data if I was wrong, they would hold me to the number.

As I predicted my customers were upset when we could not live to our estimates. So after a year of saying to anyone that would listen that this process was broken, I was vindicated, I was correct. So I should have been safe from reprisal? Nope I was in trouble, my customers were upset, and many conversations were had with many hours spent about how we could “fix” this.

I was committed, the next year I would speak up in every meeting, I would make sure there was a something in writing saying that these were “Just estimates”. I did just that, ready for a year without this pain we moved forward, and as soon as we hit a project that had a major deviation from what was estimated, the world fell in around me again.

Here I am doing damage control again and it’s time to find someone to blame. I could blame Sr. leadership for not communicating the scope of these estimates, to other top leaders. I could blame our Project management office for not giving us the tools to plan this better or not defining what variation was acceptable. I could even blame my supervisor for not including a disclaimer about these being estimates in every message ever sent.

Let’s think about a general world situation which could be used to relate this sort of situation. If you see a baby carriage about to roll down a flight of stars (not your baby mind you). What do you do? Likely you first yell “That baby carriage is starting to move someone stop it” hoping that the parents will intervene. Well what if no one comes? You still see an impending problem, do you take action? How long do you spend your time yelling for help before you act? If the carriage rolls down the flight of stars whose fault is it? The parents yes, but yours? You could have prevented it, but you didn’t?

In the end if you can see something going wrong, communicate of course. Let others know if they have a share of the responsibility, but telling someone doesn’t alleviate your responsibility in the situation. You are responsible for taking action to resolve impending problems. Blame is easy to cast, but always start by casting it at yourself.

So how will I approach my problems communicating our planning expectations with my customer? Own them. My Sr. leadership is helping, but I need to communicate directly, my customers are reasonable they just need to understand what to expect. I need to spearhead the establishment of a numeric acceptable variation from estimates, to project completion. I need to engage my customers more in the estimation process, to help them understand when they present me with unknowns how that negatively impacts my ability to provide them with reliable information. I need to in general open more direct lines of communication with my customers.

The most important part of all the things I need to do is, “I” need to do them or at minimum take responsibility for them happening.

Why do I put this in a blog about leadership?

Because some leadership is by action and other leadership is by example. This is a situation where you need to set the example to take action, and in the void of action, take responsibility.

In the words of President Truman “The Buck Stops Here”, live that.

Tuesday, July 5, 2011

Ongoing Support Effort

When we put in a new system or build some piece of custom configuration, we spend time and money to implement. As any IT professional that has ever seen a contract or been involved in the budget planning process knows. When you spend money on a package you will eventually, if not annually need to pay for upgrades and support.

When you pay for a packaged product it’s common to pay in the range of 10-20% per year for that annual support. Most IT leaders agree that this price range is acceptable and expected for support costs of a purchased product. Then why don’t we accept and make sure we factor this for ongoing labor investment?

How do we find a range and factor it for staffing time needed to support something new. Larger software companies will give you an estimated number of full time employees (FTEs) required to support their product. These estimates tend to be conservative because the vendors realize that will be factored in the ongoing cost of the product and could result in them getting or losing a sale. In addition there seems to be a point around a fourth or an eighth of an FTE where they stop factoring it and just say minimal.

I think the “minimal” amount provided by vendors and the support for internal customization is where we put ourselves at risk.

My question is how do we know what percentage of the upfront work is reasonable to consider for ongoing support. I am sure this is not a one size fits all situations and that many factors can adjust this, but there should be a range that covers 90% of the situations out there.

The second part to this equation is how you keep the small projects from nickel and diming your support. It’s easy to ignore the small contribution that these items make to your overall support needs.

For example let’s make the leap of faith that the 10-20% we expect to pay for support can be translated directly into 10-20% of total hours used to deploy or customize a product will be needed to support that. In order for this to factor out to an hour a week, which is just about the smallest number we as leaders tend to think in. At 20% end of the spectrum and spend at least 250 upfront or at 10% end we are looking at 500 hours or more to account for one hour a week.

How do we account for all the small chunks of operations added to our teams from 50 to 500 hour efforts, and what is an acceptable standard range for the ongoing support of hours spent?

Figuring this out is critical to the support of our teams of professionals as it will slowly overburden them. I have heard the comment that as IT groups we should be able to reclaim this time by ongoing efficiency improvement. I agree that may be possible but shouldn’t we self-advertise our efficiency improvements? If we automate out 10% of our annul support load just to add 10% more from new development without mathematically showing our customers what we are doing. They never realize how hard we are working to deliver our services at on consistent level.

In addition to all the responsibility we have to identify this ongoing support demand from a team and management standpoint there is a business factor. Are we painting a fair picture of the ROI of a set of work or project if we don’t identify this? If we don’t account for the nickels and dimes they can add up and possibly tip the scales in favor of outsourcing some new work or for that matter not doing it at all.

Let me know what you think. Is there a range that can be used? If not are there good books, blogs, etc. on this topic.

Friday, April 22, 2011

Checking Boxes


Do you love checking things off your to do list? Do you like looking at a status bar and seeing it full?
I know I love checking things off, and I like the look of a full status bars (in particular ones that actually mean something is done, unlike most installation status bars). These are a simple actions and images but there are some complex physiological things going on when you check a box, or fill up a status bar.
This deep psychological drive to see completion is an example of one of the methods used in the video gaming community to communicate achievement. Operate conditioning is another method used in games to reward participants. Known as the “Skinner box technique” after the scientist who first identified; it is basically the process of random rewards triggered by a designated action.
These are some of the methods used to keep players playing video games. Why I am talking about video games in a leadership blog? This whole arena of action reinforcement is very similar to the processes preached in most positive reinforcement leadership books (i.e. thanks you notes, clear work queues, public recognition).
Gaming companies spend millions on finding ways to make games engaging. Many of these processes can be applied to professional and personal motivation. This process of applying game play reinforcement to life is commonly known as “Gamification”. We as leaders should keep an eye on this and take advantage of the investment from gaming companies in this arena.

Some examples of how we might apply this?
A 5% chance that we give a reward after closing a ticket.
A status bar on the top of our work queue “Progress towards closing all April requests”
After doing 1000 project hours you level up to a level 2 project resources and get a little certificate.

It’s hard to find a way to do this that is not overly “hokey” and we have to be careful not to promote one certain type or area of work over another.
Think about it. Brainstorm and share your thoughts. Is this real or just the start of yet another hype curve?

Wednesday, March 9, 2011

Big vs. Small Changes


Big changes, possible or realized surround me these days

One of my recent complaints on a personal level has been the lack of big changes in our government. Without getting too much into my personal politics, which is not the focus of this blog, I think it is fairly agreeable that our current two primary party systems lends itself to minimizing big changes. This happens because the two parties almost always take opposing views and drive compromise before implementation. If that doesn’t happen, the party that is in control normally gets replaced every two, four or at the outside eight years, and swing policy back the other way.
I have shared my desire for bigger governmental change with friends and colleges, to which I receive a 50 / 50 response. Half agree and half say it’s good that big changes are not taking place.
Regardless of your stance on each of these issues, this current situations brings up an interesting question about how, when, and if we do big vs. small changes.
I have never been one to be afraid of big change, I believe I thrive on them. Why then, am I more hesitant to see big change in our products at Ministry vs. wanting to see big change in our government? Maybe it’s that this change feels like its being driven by forces outside my control; although most changes are ultimately driven by outside forces. It could be that I feel responsible for my customers in the same way that I hope our government feels responsible to their communities.
I think it all comes down to the level of understanding of a change. It’s easy for me to sit in the “cheap seats” and read a few articles about something. Then want to government to fix “it” in a big way by doing “X”, when, in reality, the devil is in the details.
Looking at something I understand more, the possible replacement of our API systems in Ministry.
I agree with most of the forces that think this will ultimately come to a positive result for us. However I have lived through this type of change before and understand the negative side. It can take a long time to recoup the ROI of manpower and capital for the implementation. Most calculations to estimate this are greatly lacking in information and paint an overly optimistic picture. End users will feel "pain" in the form of the almost inevitable support issues, downtime and loss of procedural efficiencies that will manifest over the short term after such a change.
Still there is a point where all those negatives and even a possible five or ten year ROI still has to be accepted. Either because your hand is forced, or small changes have reached the point where they can’t take you forward anymore, and all you’re left with is a big change.

Friday, February 4, 2011

Documentation – Format and How Much?



I have been trying to establish a documentation approach for my team and there seems to be only varying well entrenched views, and no consensus on this. There are two sets of opposing viewpoint camps that I see. Agile Vs. Formal and Everything Vs. Minimal.

Format

Agile Documentation: When you document keep it informal. This makes documentation easier to create but harder to use as there is more searching in the documentation for the information you need. There is also more possibility that something will be missed in the documentation
VS.
Formal Documentation: Use a ridged template for documentation. It takes longer to create the document and there are commonly sections that go unused. In addition some section will be filled out with information that is being mandated but provides very little value for the application it’s being used for. The end result though is as the template is used over time it becomes easier to find information in all documentation.

How Much

Everything Documented: This is supported by the belief that most of what we do in IT is a reputable process and that this documenting will be reused many times there for demonstrating the ROI.
Example of good ROI: Deploying PC’s even in a small company this is a repetitive task that happens at least many times a year if not many times a day. There is no doubt that this displays the ROI for creating the documentation.
VS.
Minimal Documentation: This is supported by the belief that in IT most of what we do is so unique that the documentation provides little ROI and is largely created as a formality and will never be looked at again.
Example of good ROI: Installing a new centralized business application on a server. Most companies only have one install of these installs in their entire system. If they are done correctly and with a proper selection process this install should have a life span of at least 5 years. Yes there will be upgrades but an upgrade process and an install process are extremely different. There is very little ROI in documenting this process.

Prevailing Logic

I think in leadership we tend to lean towards the Everything & Formal approach. Excusing the chorus of our teams pressing for the Minimal & Agile under the tenant “IT people just hate to document”. I do think that's true, but I also believe as much as we trust our team to tell us what a server can and can’t do we have to extend some trust to them as to when there is value to document and when there is not.
We should also not overlook that we work with people, and we can “force” them to do things but just like the speed limit there may be a rule but it will be bent as much as possible, and we can’t be everywhere at once to police it. The more they agree with the rule as it
’s presented the more they will follow it. Why do most parents dive the limit in a school zone, when children are present?

So what am I going to do

This is yet
another topic where I wish there was a right and a wrong answer. I don’t know that there is and I don’t know that you can set one mandate for all teams and all situations. I have started on a path for my team to gather all documentation with a common search index and folder structure. Utilizing one primary application for making our documents but allowing flexibility to use other applications with a link to our primary where needed. I interpret that as a primarily agile method with a leaning towards documenting everything. Is this the “right” answer, I don’t know but it’s where I a
m starting.

As always I look forward to your feedback

Monday, December 20, 2010

What is the best way to spend your education time?


I recently had a conversation with a college about the value of post-secondary academic education for today’s IT leader. The discussion was cut all to short because we both had work to get back to. I really enjoy having a good honest thought provoking conversation about topics like this with someone I respect.
In retrospect I think our inability to finish the conversation due to other pressing needs was the basis for my side of the discussion. There are so many options for education and personal development out there, webinars, simulation software, blogs, podcasts, audio books, post-secondary academia, and on the job training.
It is not a matter of which one is good and which one is bad it is a matter of time management. Everyone has his or her own learning style and therefor will get a different ROI from each type of education. In addition the amount of work or personal spent on development needs to be balanced with all other pursuits in those areas.
I really want to apply a one size fits all educational approach to my team and personal development, because it’s easier to manage and understand. It’s just not that simple one person could gain more by listing to 20 audio books then they would from a year of academic study, yet another could get more out of a 2 year degree than 20 years of on the job training.
I think we need to keep an open mind when we are planning our education of evaluating someone’s credentials for a new position. All of these forms of education add something to the employee’s values in his or her role however we need to remember that the whole is more than the sum of its parts.

Friday, November 12, 2010

Am I a "Leader"


So I am by tittle a Manager, but what makes a “leader”, am I a leader.

I was once told:
Imagine you’re walking along with a group of people and, they have no orders to follow you. Then you turn and head off in a new direction without so much as a word, if the group turns to follow you, then you are a leader.

There are holes in that analogy but I think the base meaning is true. True leadership is trust

Trust by your team that you have the ability to lead them in a direction that is best for them even if you don’t tell they why. Do I advocate not telling your team why you go a direction, absolutely not, tell them everything at every opportunity you can explain it until they understand. The day will come when you need them to trust you, when you can’t tell them everything; you need have mental credits with them for when that day comes.

Keep in mind that if you think about this analogy and your team would not follow you, trust is a two Way Street you might not be giving them a reason to trust you, or one or two team members may have lost your trust.
There are many ways to build trust, team exercises, defending your team, getting them what they need to do their job, expressing empathy, rewarding good performance, and yes removing under performers. It comes down to, be engaged, be proactive, and don’t get bogged down with your “work”, your work IS your team.

What other things make a person a leader post a comment I want your feedback.