Making !T Work

It doesn't need to be this way

2010-11-03T17:02:00.001-07:00

The last little while has seen the full spectrum of management and leadership. I would like to explore these two words that seem to be abused of late in an effort to assist the young executive, manager or supervisor.

I had the recent joy of having a few drinks with colleagues and the discussion invariably turned to leadership and management. The other parties knew this was like throwing fuel on an open fire with me.

As stated in earlier blogs, I have a very strong opinion on leadership and management. My basic position is this. Management ensures the work is done. Leadership ensures the work that is done has purpose. Managers inspect and leaders motivate. This may seem simple but trust me it is not. Leaders can be taught to be better leaders. I firmly believe you cannot make leaders, you can only make them better. Managers can be created, taught and guided. Being a manager does NOT make you a leader. Being a leader does not make you a manager. Hence the dichotomy of the words.

I would like to use two recent major incidents to emphasize my position.

The first incident is the BP oil spill and the second is the Chilean mine incident. Both topics are overused but I believe my use of them may be different. BP is an example of excellent management, truly. The mining incident is an example of excellent leadership based management. Let me explain.

THE OIL SPILL

The media has covered this story to death and I will not go into all the details but some serious backdrop is needed before the press makes some lazy engineer's email into a hero story.

Background on the management decisions without leadership that were made.

Drilling into the deep trough instead of the shelf. This was purely done due to cost saving. It is easier to drill water than rock. Yes, it is sad but true. This is why it took so long to dig relief wells. This also added to the extreme complexities due to depth and going too deep. Leadership management would have drilled on the shelf with a relief well being deployed in the trough. The accountants won the first round and the engineers too enamoured with the cool toys won until the disaster happened. Further evidence that engineers and accountants are just really high profile score keepers.

Management when the accident happens

Focus becomes on saving the well and not stopping the oil. Stopping the oil is a risk issue. By now we have competing management objectives on how best to save the well and mitigate the risk of the oil. Scientists, engineers and accountants are working the numbers and not the problem. The result is that some very bad remediation occurs. Plans become asynchronous and not synchronous. The fact that they never had more than one plan on the move is pure management. Leaders work as many options as possible to get the most out of the people, the resources and the situation.

Layers of abstraction

BP creates a condition of abstracting the business units to defer risk and to manage the bottom line and NOT the long term. By creating distance between the executive branch, the operations group and the consultants the firm is insulated from financial and litigation exposure. This is an excellent fund management strategy but a very poor business execution strategy. In times of crisis an organization needs to gel and be cohesive not fragmented and dysfunctional.

The overall effect here is to have as many layers as possible between risk elements and decision makers. So anyone complaining about a problem cannot get directly to the person who created the condition or who can remedy the situation.

Defer the risk (blame game)

Management decides to spread the risk and share some of the monies with contractors. The contractors as explained to the shareholders are lower cost and are NOT burden by our restrictions. This is the first red flag for poor accountability but a great management strategy. In most cases this strategy works. BP projects have a very poor safety record but BP as a corporation has a good safety record.

Containment

To this I have to tip my hat to management. In the midst of this chaos they were able to prevent the US government from intervening, and for technology to be deployed to demonstrate the gravity of the issue. This was mind boggling to me.

The US government has the largest navy in the world and not a single one of its massive assets was sent to act as a barge to stop the oil and to assess the damage. The was Obama's time to shine and he blew it. Millions upon millions of Americans were put in harm's way by this and he sat there neutered. It was painful to watch. All the talk in the world will not stop the oil from spreading. This was classic analysis paralysis. His country is being crushed by banks taking over his country and when his country is being attacked by a runaway oil spill he trusts the "company" that created the problem to own up to its mess. The really sad part of this, is that it was allowed to happen. His only feint moment of truth was when he was going to stop BP from paying its dividends. That almost worked till he found out that too many of his starving pensioners have BP stock and depend on those dividends. How very sad for the young president. He cannot blame anyone for his complete lack of leadership during his watch. He did, however, do a fair job managing it though.

Most times, action will trump inaction. The Obama administration so failed on this one. It was his country at stake with its shoreline and its livelihood.

The second containment issue that was too bizarre to believe was the "live spill cam" showing the oil spill. Ok, this is another sign of the apocalypse. They can get a camera down there and get it on the web but somehow they can't get a good camera down there. Much has been said about James Cameron offering his camera and technology to the cause. He was serious and it would have been very effective if BP was actually trying to do what they said they were trying to do. Here is the deal, grainy pictures give the illusion of action but they also knew the risk if good quality pictures where broadcasted to the world. Their quess-timates of the volume being poured out would have been challenged by sharper minds then whom they had on staff. Trust me, this was by design and not by accident.

"who is in charge"

The BP incident and Katrina both suffered from this greatly. Who really was in charge. You have groups dropping oil containment socks and another spaying dispersants to dilute the oil. One counter acts the other. But we are doing something, please be patient, trust us. Then they only had one plan at a time. This wasn't some lab exercise it was suppose to be real. Even when they were able to pump the oil they didn't bring enough ships to hold it. But they did manage to save the oil.

The winners

BP and all its shareholders won on this one. The company survived, maybe a little bruised but functional. They will pay their billions and marketing companies will make a fortune spinning the new BP.

The losers

The poor souls who lost their lives and their families. For BP has and will not change their ways and other workers are still at risk. They just don't happen to work for BP directly.

The American people have lost their coast line and their ocean based economy.

Obama lost a real time to lead. Kennedy had his "Cuban Crisis", and NASA had its Apollo 13. Obama had the resources, the timing, and the will of the people but he lacked the execution. People do want to be managed they want to be lead. The sad part is that his bid for election was about leadership and he did show signs of actually understanding that. However, never confuse "the sell" with "the install".

THE TRAPPED MINERS

A Chilean deep hard rock mine that has seen its share of turmoil and ownership changes. The mine suffers a major rock burst and it is shut down from access. The emergency procedure are followed and they determine 33 miners are unaccounted for. The search for survivors commences. It was this natural use of the emergency procedures and its execution that would lead to the most dramatic rescue in recent mining history.

Leadership management before the incident

The leadership of the company, had emergency shelters, food, ventilation and more importantly emergency protocols. These protocols were not just pieces of paper but regularly checked and validated procedures. Workers were trained and practiced on the procedures. This was considered a cost of doing business and the right thing to do.

Leadership at the time of the incident

On the surface the emergency response teams started to execute a prepared emergency plan. All elements of the plan were put in motion. There was no one waiting to see who was in charge. The plan had factored this in, the mine management engaged the resources and drew from internal and external resources. It was not about saving the mine it was about saving the miners. Immediate action trumped any naval gazing. Teams were devised to search for survivors and to drill ventilation tubes into underground emergency shelters in the event miners had made it to the safe houses.

After days of executing the plan without deviation and doubt, the first real miracle occurred. The miracle was a note stuck to the drill rod of the vent shaft. The note was simple, there are 33 of us and we are fine.

From underground the miners had already rationed the supplies, natural leaders emerged to execute the plan and to assess the situation. Work was broken down and each member had something to do to ease the stress and to improve the situation. These men just did not sit down and blame an external force on their misfortune. They started to work the problem and were coming up with plans and options on their own.

Leadership when the miners where found

Once the trapped miners were found, the country stepped in and released the full power of resources and not the ego. The broke the problem down and had several teams working several options. All the time there were communicating with the miners and their families. They took the approach "Success is all 33 are coming home", failure and the associated risks were understood but not the focus. Leaders have doubts after decisions are made and not before.

The extraction

Once the true realization of the facts were known, the rescue was broken down into major parallel tasks. All factors were considered, health, hygiene, body sizes, mental health, extreme exposure to no natural light, geological issues, access to equipment, food, shelter, extraction bullet, physics, engineering, emergency services, etc. Each area had a lead and each lead reported back the executive. The key here is that they worked on many issues at the same time but with a solid communications and control mechanism.

The celebration

Here was another part that showed the true leadership of the event. The celebration was about the miners and NOT the company or the rescuers. Their reward was seeing the 33 happy faces not the padding of their paychecks (the latter occurred naturally for doing a good job, not by demanding it).

The president of Chile and Bolivia (one miner was from Bolivia) were there not for the glory but real leaders, lead by example. The photo ops happened of course they do, but for the right reasons.

The winners

The family and miners, the Chilean government for it showed the world how to deal with a crisis, the mine for it has been able to maintain its reputation of taking care of their own and lastly the people of Chile, for they have a restored hope in hope.

The losers

The media that played to the drama of the one miner who had a mistress. This was noise for the west and irrelevant to the event. Big mining companies who freely admitted prior to the extraction that it could not be done and they would never take the risks. The only risks they wouldn't take was to their back accounts. It was a sad statement from some of the largest mining companies and the some of the larger mining labour groups.

In conclusion

The Chilean leadership based approach pre, during and after the incident if applied to the BP incident would have had a better ending for all parties. If the BP management approach had been applied to the Chilean incident, families would have been given compensation payments in front of the media and a tombstone at the base of the mine to lay claim to 33 dead miners.

We as a society need to promote and demand leadership. Our people in leadership positions today are so concerned with management of numbers, expectation and the next poll or quarter that they have missed the bigger opportunities.

This is being echoed by governments and what the media is trying to call national debates. We need real discourse and engaged communities not people who are being managed (read manipulated) by 30 second sound bites.

In the technology field this is such an easy trap to fall into. Groups will hide behind management decisions and chase the new shiny tool instead of making the current ones work effectively and with purpose.

You lead from the front and with you head held high. Build a strong team that is armed to execute plans and to be creative to gain a better end result. The more we allow basic management to prevail, the softer and less competitive we all become.

Detention time verses dwell time

2010-09-23T13:23:00.001-07:00

Recently, I was asked to explain the difference between dwell time and detention time. This is a common question that plagues the transportation industry and as such there is likely more than one explanation. Here is how I explained it.

Background

The first question that some of you will ask is why is this even a discussion? The answer in the transportation industry is that you generally only get paid when assets are being utilized. The challenge becomes knowing what has moved to make money and what has just moved in general.
For the purposes of this discussion the following definitions are required for the reader to continue.

Detention Time

This is the calculation that something has actually physically not moved. This uses the specific latitude and longitude reading of a GPS device and checks to see if the asset actually moved. This can be very helpful to find assets that are “static” regardless of where they are. An example of this is a dropped trailer that has been forgotten or that has been abandoned by a tractor.

Benefit

1) See what is actually not moving, literally.
2) Find misplaced or static assets regardless of where they are suppose to be.

Challenges

The biggest challenge is to account for GPS drift. GPS drift is when the latitude and longitude can shift due to GPS tracking precision. GPS location is based on triangulation. As the number of satellites change over time the accuracy of the latitude and longitude can vary. This is called drift. The 4 decimal place precision is roughly 11 meters. What this means is that over time a very static GPS location device could look like it moved up to 11 meters and it did not actually move. This is addressed by using math to account for the drift and then comparing the results against a drift algorithm. The answer will come back with it did or did not move + or – of the drift value.

Dwell Time

Dwell time time is very similar in thinking to detention but with one large variance. Dwell time is primarily focused on assets that have NOT left a geo-fenced area.
A geo-fenced area is when you place a boundary around a specific landmark. This landmark could be a terminal yard, customer site or any other geo-spacial location that has a complete closed logical perimeter (circle, square or polygon).
Dwell time will tell us if an asset has NOT left a defined location.

Benefits

One of the biggest benefits to the organization is that it will tell you if an asset has not left a location. What can cause this is if the asset has been shunted around the yard for various reason but has not left the yard. Customers will do this with trailers specifically. They could be using them for mobile warehouses yet from a latitude and longitude perspective the asset is moving and would not be caught by using latitude and longitude only.

Challenges

The biggest challenge facing dwell time is the interval of the GPS latitude and longitude reporting. Let’s say that you have a device that is reporting location every 8 hours. It is possible for a pulse to happen within the location, then, the asset leaves the location and returns prior to the next pulse. This condition would give a false positive. To combat this you may have to look at both detention and dwell to isolate patterns. Another alternative is to increase the polling cycle.

Business questions answered

1) What is not moving = Detention
2) What is not moving and I do not care where it is = Detention
3) What is hanging around a yard and not making money = Dwell
4) What is at my customers and not moving or leaving = Dwell
5) Looking for lost revenue for assets domiciled at customer locations = Dwell
6) Misplaced assets = Detention
7) Dropped trailers = Detention

Visit my trailer tracking site to learn more.

Strategic Planning

2010-05-08T22:38:00.001-07:00

This post will deal with the specific issues around strategic planning regardless of organizational size. The same rules apply for all. I am a big proponent of planning and specifically strategic planning. It is critically important to know how to plan so you can build the road ahead. It provides for downstream direction and more importantly a reduction in dysfunctional behaviour.

There can be as many methodologies for planning as there are plans. Do not let the different approaches confuse what is the purpose of the plan.

The information for the plan flows from the bottom up and is distilled from the higher levels to make the plan. Once the plan is made then it must be lead from the top down. The vision must come from the top. It may seem simple but all to often this is not the case. When the plan is driven from the bottom the phrase “the inmates are running the mad house” comes to mind.

What is the function of each of the areas?

Strategic

The strategy function is the high level that defines where is the organization and why does it want to be there. The vision in short. The goals are based typically on the SMART acronym of Specific, Measurable, Achievable, Realistic, and finally Time Framed. This is typically driven from the mission.

Let’s break this down. The goals have to be specific and not some nebulous touchy feely element. You want to grow the company by X or you want to have all products under one group, or you will acquire companies for volume or product growth.

You need to measure the goal so you will know when you have gotten there and more importantly, what needs to be done to get there. People do not do what you “expect” they do what you “inspect”. The inspect portion is the measurement. Another caution here is to measure what gets you somewhere and not burden down the system by too many measures. I have seen firms spend more on the measurement then on what the function brings in value. This is a real concern and as a leader of the strategic plan you need to have your measurements be part of the overall plan and with the correct tools to measure effectively.

The goals have to be achievable. You cannot put a goal out there that no one believes is reachable. You want to create stretch goals that make the organization better but not so stretched that buy in to the goal will not be supported.

Realistic goals are those goals that fit the culture of the organization and the overarching team to achieve the goals. This part of the discussion leads to comments about hiring new skills or rethinking some approach to realistically attain the goal without undo harm to the overall organization.

Without a timeline, most goals are not reached. The interest wanes and the prospect dims. Once the timelines are in place then you need to have regular checkpoints to see how you are progressing. Failure to do so may surprise you when you are getting close to the deadline and you are not there. This goes hand in hand with measurements. Your measurements should have expected values for each of these checkpoints.

The strategic plan should be an inclusive approach from the bottom up to gather as much information as possible. However, the final decisions have to come from the leaders in order to be executed properly. Strategic plans can be managed to success but they are lead to greatness. You want to give a clear picture of the plan and why you want to get there.

The strategic plan should span years and have regular checkpoints to ensure you are on track. It also gives you time to adjust elements in order to achieve the goals.

Tactical

The tactical plan is how you break down the goals into major functions so you can achieve the goals in the timelines specified.

This part of the exercise is where everyone takes their areas of the goals and breaks them down into relevant and meaningful objectives. These objectives are the building blocks to achieve the goals. The increment steps to success.

Objectives will span disciplines and departments and will require coordination between the major players. These objectives can also use the SMART acronym but have a lower context view of the issues. You may need several objectives to attain just one part of the goal. The issue and focus has to be on how do we deliver the parts of the solution for the goal in a structured deliberate way.

The tactical plan is typically 6 months to a year and involves shorter checkpoints. These shorter checkpoints allow for quicker decision making and minor adjustments.

Operational

The operational plan are the short term tasks to achieve the objectives of the tactical plan. These may projects that deliver key elements for the tactical objectives to attained. These short term tasks are very specific and will be larger in number than objectives. The objectives may create many tasks in order to achieve the objective.

The teams required here are more specialized and rarely cross boundaries. These smaller units are able stay focused on the tasks and have insight into the objectives. They will know of the goals but will have little insight into the actual progress of the goals. They should have insight into the objectives.

What are the elements of a strategic plan?

Vision

The vision is what you want to be. A future statement of how and what your organization will be know for. It is a small statement that reflects a line in the sand that can be defined. It should not be a novel with legal, politically correct statements. If you need to have a coffee and muffin to read it, then the vision can be effective. The vision is the point in the future. An example is

“To be the #1 choice of our customers”

Mission

How will you get there is the mission. The mission statement is the action item to deliver the vision. Using the example above the mission statement could read

“We will focus on value, a superior customer experience and innovation”

Goals

Goals are the key elements to execute the mission to realise the vision. The Goals to support the fictitious Mission and Vision above could be.

1) Reduce order process times to 1 day

2) Provide a new major release every 6 months

3) Decrease billing errors to .01 percent.

What are the impacts to the plan?

People

People need to buy in in order for the goals to be achieved the mission to be executed and the vision to be realized. To do this you need to open communications from the bottom up. Get the input from the operational people. Distil this information and let it provide insight into your vision. The vision, must be reflective of what your people can achieve. They may need assistance to get there but that will be flushed out in the goals.

I cannot stress enough you need input NOT decisions from the bottom. All too often I hear, well that is what the department wanted. This is so wrong on so many levels. How can we expect a line person to understand the entire machine. Their insight is very helpful in how we deliver the end product or service but their view is limited to their area.

All too many projects have failed for they tried to please everyone and when you are trying to perform structural change this is not a realistic condition. Fess up early and get the people to understand or at least know the reason why of the vision.

Remember people respond to what you inspect. Your measurements should be sensitive to positive outcomes and not compliance.

Process

The day to day processes need to be aligned with the objectives and goals. Failure to do so, will make the attainment of the objectives and goals highly unlikely.

The measurement components should be non-obtrusive and the analysis of them part of the process.

Processes may need to change to support your goals and objectives. Ensure everyone knows why this is being done. When processes are aligned you will get buy in and you will not get trapped in the bureaucracy of management of measurements. I too see this often. If the measurements are not part of the process then people start to manage the numbers and not the process. This is very dysfunctional. The measure has to support the end means and not just be a box to fill in.

Tools

In most cases in order to truly be successful, the people need to have bought in and the processes have to aligned. Typically doing this will also ensure you have tools to easily measure the outcomes and to provide this information to the people required to action this to achieve the goals and objectives.

In Conclusion

Plan the work and work the plan. It is as old as the Romans and still very relevant. Strategic planning is very important and should be part of any organization regardless of size.

Larger organizations will have formal processes and will have disciplines in place to adhere to the processes. When and if you become part of these plans, be proactive, probe deeper and find out why certain goals need to be achieved. It will go a long way in making sure your objectives meet the overall goals.

If your organization does not have a formal process, make one for your area. The rest of the organization will follow. If you do not have vision how do your expect your people to follow you.

Another question I get asked often is “I am only a manager how do I do strategic planning”. This is actually quite simple. It is a matter of perspective.

The executive branch makes the strategic plans for the whole organizations, Directors then provide tactical plans to achieve this. Their managers will then in turn be given tasks to achieve the objectives.

Now comes the fun part. To the organization above you are providing operational tasks. However, to your staff you are providing strategic goals. Then the supervisors below you are now giving you tactical plans and the line staff are given operational tasks to achieve their tactical goals. It is the water fall effect.

I am currently a Director. I get my marching orders from the CFO. I then translate them into tactical plans and operational plans. To my staff I am providing strategic direction but to my boss I am providing tactical leadership. You just keep doing this till you run out of reporting layers.

Information and metrics follow the same path.

The executive team decide where they want the ship to travel based on forecasts, staff input and their personal leadership positions. They they ask the staff to ensure all the elements of the ship can be monitored and managed to arrive at the destination.

By everyone focussing on their role and contributing in a positive way the organization will achieve the plan and hopefully the plan was a good plan. If the plan was faulty but is being followed correctly then adjustments become easier to apply. When there is no formal process and everyone is rowing at their own pace and direction, the ship will go nowhere but everyone will be working hard. Working hard is not the way to success, working effectively is.

Circling the dragon

2009-11-26T14:25:00.001-08:00

This is a phrase I use frequently when I am trying to find a stubborn or elusive problem. I am not always sure everyone understands the statement. The short definition of the phrase is to keep chipping away on the periphery issues to get to the root (dragon) of the issue. It also means sometimes you cannot solve the problem in one step and you have to plan your way to resolution.

I will explore both options in this post.

The graphic below shows the dragon in the midst of the OODA loop. This is by design. The approach to basic and pragmatic trouble shooting is to follow the loop.

Getting to the dragon by process of elimination

This approach is used when you are not entirely sure of what or where the dragon is. An analogy would be of a dragon slayer going on a quest to find the dragon. The dragon slayer would follow the trail and the evidence till the dragon was found.

You need to really focus on the OODA loop here. The first step is to clearly observe all the elements not just one the ones you are comfortable with. Look at it from different angles and from different perspectives. In the orientation phase of your observation you are likely seeing just a symptom of the deeper problem. If you could see the root problem (dragon) you would take a different path to solution. For this discussion we are going to state you are just seeing the symptom.

Once you have oriented yourself to the observation you need to list the options (decisions) you have. Play it out in your head what happens with this test or with this action. Visualize the process. This will give you what you expect to learn or gain from the exercise. This is where I see most trouble shooters fail. They tend to hack away at things and in doing so miss the relevant. They also, end up wasting time and more importantly they tend to add to the problem.

The approach of elimination is just that. Break down the issues in systematic and measured steps. You should have an expected result from the effort. Sometimes the effort is to just prove what it is not. This is OK, sometimes you need to validate the known so you can find the unknown. As Spock use to say in Star Trek, “if you eliminate the possible all that is left is the impossible”. There is a lot of wisdom in that. All too often we jump on the obvious, only to find out it did not solve the problem and we have learned little from the exercise. By taking a step back before we jump in, we can see if jumping in is even worthwhile.

Once you have played out the possible decisions you need to act on them. I am amazed at how many people freeze here. They have a solid basis for their approach, it is based on solid observation and alignment (orientation) with the decisions and yet they do not act. My favourite clue for this, becomes the accountability blame game. It manifests itself in statements like “I do not have authority to do this or I sent an email and no one responded”. This shows lack of ownership and commitment. If you do not act then how do you expect to solve the problem. Hiding behind email shows lack of personal accountability and leadership.

Once you act on your decision then you need to start all over again. What did your action do to change the situation at all? Even a nothing change is telling you something. If nothing happens, you may have to undo your action. If it did in fact change something what did it change. The exercise of “what is it telling me?” is critical in the orientation step of the repeatable loop. Force yourself to dig deeper and in doing so you will be given different decisions to draw from. Once a list of decisions is made act on your plan. Once the action is done, start all over again. Are you sensing a theme yet?

Eventually, even if it is just shear will power, you will find the dragon and reduced it to its smallest elements. The result is the dragon is gone. Now like all dragon slayers you have to go and find a new one to battle. How you defeated this dragon now becomes knowledge you can use for your next encounter.

Slaying the Dragon in steps

When you know what the dragon is and where the dragon can be found you may need to take several steps to get to it. If so, then it becomes all about the planning and execution of the plan. It is the deeper, more mature, application of the OODA loop. When you have found the root cause and you know it cannot be slain in one cut then you need to plan and prepare for its exorcism. To be fair, of late, this is lacking in so many firms and people in our industry. We have become obsessed with the tools and the analytics but little work is actually done solving the problem. We have better diagnostic tools then we ever have had and yet we still are falling behind in solving issues. This is not unique to the information technology field, all one has to do is look at our health care and you will see we are more focused on the problem then we are on the solution.
In building your plan you need to break it down into its appropriate steps. Once each step is defined you need to mentally validate that the steps are in the correct order and what is the expected outcome of each step.

Doing so is critical to the OODA loop execution.
So once you have made your plan, you observe the environment. This can be done by doing a baseline test and measurement. You then orient yourself to the observations. Has this baseline highlighted anything or shown a pattern you were unaware of? Note these observations for future reference. Make a decision as to the plan execution. Execute (Act) on the first step of the plan.

Once the plan is in motion, observe what is happening. Orient yourself to your expected outcomes. Are the expected outcomes being realized? If not, what have you found out? Do you need to change the plan? Once you have made up your mind then act on your decisions and the next step of the plan. Start the loop again at the observe step.

Doing so will quickly, and hopefully, predictably slay the dragon. The key is that you must be adaptable to what you are seeing and you must be able to orient yourself to your observations. Your decisions need to be based on what you see and what the context is of what you saw. Lastly, without action you become the victim of inertia and in problem solving inertia or inaction is the enemy.

In conclusion

Problem solving is about bringing solutions to bear. There are many who can write emails and memos on the problems facing us all. The real challenge is to bring solutions so the problem are resolved. To the naysayers who wax poetic “there will always be dragons”, I say to them clearly and with purpose, “Lead, follow or get out of the way”.

The people side of problem solving

2009-10-18T22:38:00.001-07:00

As of late the amount of work hitting our team has been staggering. The initial response by the team is that we are overworked. Fair enough….. or is it?

I have always struggled with this comment. My approach is and has always been, if you do it right and pay attention then you rarely have to go back and fix it. If this is a truism then the work you are doing is moving you forward not holding you back.

Since not many people give this argument much thought or at least my current team doesn’t, I thought I would take this blog to express my position or stance.

To solve a problem you have to first acknowledge there is a problem. Seems simple but it is not that simple based on the observations I make on a regular basis. Frequently, I have been known to say in passing “see a problem, fix a problem”. Typically this is something as simple as fixing a colleagues tangled phone cord when you borrow their phone. A simple gesture, but one I consistently do, just because. Other simple ones like filling the paper tray of a printer you walked by because you heard the error tones. Holding the door open for someone whose hands are full should not be something that has to be “memo’d” to be done.

Yet, as I look around I see most of us plodding along and doing as we are told. This is a huge burden for the person that is responsible for telling us work needs to be done. I can’t remember a time when my boss had to explicitly tell me to do work. Sure, we have meetings to discuss priorities and new projects, but I would be insulted if he had to tell me do something that is clearly in my implicit mandate. An example is doing the annual Disaster Recover Plan. His job is ask what occurred, or to make a decision on if we are going to spend more money on it. He does have to “tell” me to get it done. That is my responsibility and accountability. It makes his life easier and it clears up our meetings for more strategic endeavours.

We are in the midst of a very large multi-vendor phone upgrade. It involves the lion’s share of our users and will impact the entire enterprise. It has been 10 months in the planning and will be executed over 5 weeks. We have fundamentally altered the way we use telephony. By all measures this is the single biggest project our infrastructure group as ever worked on. Saying this, my immediate expectation of my group is to be focused and to think of things that are not so obvious. Put yourself in the chair of the users.

For months I have been listening to the push backs and complaints of my team of how much work they are doing for preparation. I keep reminding them that this large effort will reduce our overall efforts in out years. The smarter ones get this, but the average ones do not. This is why I am writing this post.

Our cabling person is driving 2 hours to visit one of our closest sites to prep for the phone changes. Phones use cables, cable people put in the cable, putting in cables requires tools, cable person should be automatically bringing tools. NOT….. He wasn’t told to, and is very comfortable is stating this. Sadly, this is not such an uncommon event. I have been speaking to my other colleagues and they are experiencing the same type of behaviour. My simple response is “until there is a penalty there will be no change”. Yes I know this sounds harsh and the softer side of me says “you get more with honey then with vinegar”. But what do you do if the honey is not working? Common Human Resource procedure has the manager doing way too much work to get so little in return. So I continue to reward the good behaviour, and then acknowledge the bad behaviour. It makes for a long day at times and many visits to the human resource department.

As a person you have to want to fix the problem that is on the people side of the equation. If you or your team is not personally engaged to fix the problem, you likely will be dealing with the issue for a long time to come. However, if you are capable of creating a culture where your team cares about their job and their relationship with the larger firm, then you will be able to solve the problem right the first time.

The above picture is one of my favourites. The saying goes something like this: “Who is more committed to the breakfast meal, the chicken or the pig?”. The answer is the pig, for it has to give up its life to provide the bacon for breakfast. As of late, I am finding way too many chicken’s laying the low fat, low content eggs and spouting off about how much work they have done. Whereas, the pig cannot say anything for it is too busy being the meal.

Be a real person when solving a problem, and remember that you are likely solving it for someone else. Also, it is not important who fixed it or who solved it. What is important is that it was fixed respectfully and effectively. Spread the praise of others and do not be afraid to call out the naysayers. If the naysayers want a voice, let it be the voice of self-defence instead of their smug offensive.

My New Toy

2009-09-03T08:26:00.001-07:00

Well I finally did it. I supported the economy in my own little way. I bought a brand new, gas guzzling, kick ass 4X4 truck. I am so happy. Can you feel the testosterone?

Mine of course is better than this picture. The picture is the same colour but mine has the soft tonneau cover, bug deflectors and the window vent visors. Are you impressed?

Where are “U” in the user experience?

2009-09-02T15:12:00.001-07:00

This post is a result of the last few days and the constant reminding I have I had to give me team. In the midst of a technical system failure it becomes so easy to lose track of the users, your role and the role of the people you are speaking to. From the people, processes and tools approach I adhere to this post is clearly dealing with people issues. These issues are a direct reflection of how they interact with the tools and the processes. I am a true believer in everyone is accountable for their actions and interactions with others.

Know your role

Support

If you are the support person and you are being asked by your superior a question then please do a baseline assessment. The mental assessment should go something like this “who are they?”, “what level of knowledge do they have?”, “How much context do I have to provide before I give the deeper answer?”. It should not be “WHY are they asking”. This is insulting to the person asking the question. If your superior has asked a question please answer it. If you want to have an esoteric mind conversation on the “why” and “conspiracy theories” do it on your own time. For the most part when someone asks a question they really want an answer. If this is the typical courtesy “how are you today?” then by all means feel free to lie. But when they ask a question of you because you are the support person, then answer with facts and stay on point.

If your role is support then please provide some. Remember that you are being asked for your advice and consul to fix a problem. It may not be your fault or it may be. That should not affect the facts. Also get over yourself. Just because you know more then the person who asked the question does not mean you know it all. You may be surprised what the user and your superior know that could make you look silly if they choose to. Do not give them a reason to exercise that option.

Treat both the user and your superiors with respect. You do not have to like them to respect them. This is a great position to take with anyone you work with, play with or live with.

Speak in the language and context of the person you are speaking to. If the end user is from warehousing don’t be throwing acronyms their way or speak in geek speak. Try to use their language. If you do not know and you want to be successful then you should start to ask questions of them to educate you on the problem in their language. Picture yourself in a foreign land with a foreign language and you need to get some directions. Break the communications down to that level. They are likely the master’s of their domain and you can learn something from them instead of telling them things that make your world easier.

End user

If you are an end user and there has been a system failure you have a role to play as well. It is a very important role. You are the recipient of the direct pain of not having your system working. You need to provide more insight then “it doesn’t work”. Or my personal favourite, “I can’t get my work done and it’s IT’s fault”. It may be the Information technology’s department fault or it may be what you the end user did. Either way we need each other to get the problem resolved. Please keep the drama for your friends in the lunch room and not for the ones who are trying to help.

Please pay attention to what you do when you are using a system and/or a process. I know us IT folks like to poke fun at the dumb users but hey users get paid to do a job too and that job is rarely a direct result of the technology. Sometimes it is and then I personally get frustrated when for example a programmer who uses a computer all day to do their job has to have the infrastructure group setup the new monitors or keyboards. Come on .. . . get real. This is tantamount to driving a car and not knowing how to put fuel in it. Yes I know they exist out there and they are also breeding but someone needs to educate them or better yet slap them.

Leader

If you are the leader please pay attention. First, I did not use the word manager because that is completely different and was explained in a different post. The leader has to assess all the facts and from all the players. Do not get caught in the drama. Stick to the facts, assess what and who is impacted. Find out “what changed?”. Have all parties quantify their statements. I use the line “what evidence do you have to support your position?” I get amazing results from this approach. First it disarms those who want to finger point and it also forces the team to stay on facts and not conjecture. Following my fact based strategy will save many cycles and reduce stress.

Prove and/or disprove all the theories coming at you. Your role is to direct the flow of information and more importantly to get the decisions made. Sometimes these decisions are not made by you but you need to get these decisions made by the correct people.

You also need to ensure that all parties are not crossing boundaries. This is very common in large projects and when people start to influence peddle like a bunch of politicians at voting time.

Be confident of your role and do not let others dissuade you from your role. It is not good for the team or for you.

Conclusion

Each and everyone of us has a role to play and the role changes as the situation changes. Sometimes you are the leader, sometimes you the end user and other times you are the support person.

Each and every time you enter a new situation take the time to observe the roles of others and more importantly yourself. This goes for when we are in informal situations as well. The best leaders have proven they were also excellent followers.

Sample argument for a Blade Center

2009-08-31T15:11:00.001-07:00

Here is a sample discussion paper I wrote to assist a First Nation Community in evaluating a blade center approach to infrastructure. The name of the community and identifying details have been altered or removed.

What the following post highlights is that the model changes with blades and virtualization to the positive. However, an organization’s thinking must change to achieve these benefits.

Issue

The Community administration’s is looking at strategies to upgrade their server infrastructure.

Background

There are currently 11 servers within the community at different stages of their lifecycle. Many are end of life and present a critical risk in the event of failure. The traditional method of creating a business case for each server is both time consuming and may be preventing future opportunities. This briefing note will attempt to demonstrate another alternative.

How does it work today?

In today’s environment when a server becomes end of life the organization is faced with several challenges. The first challenge is to understand the role of the server. Is the role of the server mission critical? Some of the servers today are considered mission critical. The more mission critical a server is the shorter its outages can be. These servers perform functions like email, accounting, grades, Firewall, printing, file sharing etc. Each and every one has its role to play and it may or may not be able to be offline. Only the organization can make that assessment.

Once this assessment is done, then the organization has to determine how big and expandable does the new server have to be to last until that platform is end of life. The recommended recycle time for critical servers is three years. If you follow this approach the first years of the server implementation the server is running well below optimum, the second year it starts to realize full performance and somewhere in its third year the server will start to become strained from overuse. This is a typical scenario and is repeated for each and every server. These ebbs and flows are constant in the industry.

To address this static hardware replacement strategy the industry is now deploying what is called blade centers. These blade centers take the best of today’s hardware and packages them so they can fulfill the needs of many servers on one hardware configuration. This virtualization of physical servers to many logical servers is well demonstrated and proven in the industry. The technology has been proven and it is being used right here on Manitoulin Island at Manitoulin Transport. They were able to consolidate over 100 pieces of equipment down to 10 pieces of equipment while at the same time expanding their services offerings.

Costing Sample

The following table demonstrate the costing model difference between upgrading 11 servers independently verses using one blade center. The blade center described is capable of running 18 servers of the type and model being utilized by the community currently. I have chosen 18 due to the fact more servers are actually being recommended by all the major vendors today. It will also allow the community to build testing environments without having to purchase new hardware.

As you can see the second year of the model the cost structure dramatically switches in the favour of blade centers. If you factor in additional servers then the case for blade center is proven sooner. The third and out years are even more favourable to blade centers.

Benefits of Blade Centers

Centralized control and management
Cost savings
Centralized Backup
Back and recovery per server is consistent and resilient
Annual incremental increases verses sporadic larger capital costs.
Autonomous building of servers
Integrated security
Improved network performance and resilience
Reduced support costs
Small form factor
Reduced energy costs
Reduced heating and air conditioning requirements
Industry adopted
Many vendors to support the platform and its implementations
Increase the number of servers with minimal or no additional costs
Increased flexibility for your technology rollouts
Hardware independence from your operating systems. Bigger benefit in the Microsoft world.

Burdens of Blade Centers

New skills are required to maintain the platform
Software to build the platform will need to be purchased
Migration project will need to be undertaken to port the existing 11 servers to a common platform
Organizational policy change to support central housing and shared resources
Governance structure for support and backup rotations
Annual operational dollars will need to allocated to sustain the platform

Conclusion

The cost of hardware is plummeting but the challenge of effective use of hardware is ongoing. By adopting a blade center strategy, the community can reduce costs, increase effectiveness and provide a long term platform for the entire community. Each of the current 11 servers is important and their ongoing support and functions are critical to the overall community. A proactive and long term view to their deployment will have a positive impact for the community.

Next Steps

Agree to the strategy
Build a requirements list for the platform
Build a RFP
Source the platform
Build the migration plan
Perform the migration

The challenge of Voice over IP

2009-08-17T21:13:00.001-07:00

There are lots of discussions regarding Voice over IP (VoIP). They typically are centered on the technical merits or shortcomings. This post will attempt to address some of these issues but more importantly address the business discussions that should be transpiring.

First, my biggest pet peeve is for the vast majority of the naysayers who claim with great flair and passion that “VoIP is not ready for the real world”. Ok, check the sources of these claims. Most likely is the the big telecomm groups. Why? Simple, they are trying to keep as much money in their pockets as long as possible.

Every technology has growing pains, the telco’s have had a hundred years to better the experience. Recent failures of the big telcos show they didn’t see the real business problem but are still bragging on the technical wonders of what is in their labs.

This graphic shows the timeline from the old copper days, to digital phone (the said saviour of the business) to Internet Protocol (IP) phones.

The point here is that there has been a path to something different over time and with increased functions.

The large phone carriers have been doing VoIP at their interconnection points since the late 90s. These are the same carriers that say VoIP is not ready. My challenge to them has always been, then what are you doing to get it ready? Their users have spoken and answered in droves by saying “not much”.

I personally have been doing VoIP at the trunk level for my enterprise phone switches since 1999 over Framerelay, yes Framerelay. So much for the engineering specifications of today’s massive network requirements. Which leads me to the real challenge of the convergence.

If VoIP is going to work it has to travel on a good data network. Seems simple but here is where the real cultures clash. The clash is not in technology but in approaches to solving issues. The 100 plus years experience of telephone thinking is move slow (read glacier speed) and over build. The premise always was, we have lots of money and time. Along with this the customers really had no choice. If you wanted voice mail and auto attendants the choices were limiting, confusing and very expensive. This voice culture rewards safety and engineering prowess. In the traditional phone world the engineer dictates the experience, hence the horrible user interaction points. The only saving grace was it worked predictably and reliably.

The culture of the data teams is get it in and fix it later. This is a plaque that is ruining the industry. Poor network design along with sloppy implementation coupled with cavalier change management policies is their legacy. This culture leads to some of the vast security breaches that occur today. The network needs to be designed and implemented properly to really gain the value of VoIP. Some of benefits of the data network engineers is one of adaptation and creativity. This is a good trait to have as long as it is well managed and lead. In this new world the network is king so let’s not make the village idiot the king.

On the same note, let’s not make the telco trolls the masters of all. This is way too dangerous and counter productive.

The Internet and the internet protocols are here to stay. Many good people have built worthy networks capable of running VoIP simply and effectively. These people have used the true value of voice engineering design principals with the creative approaches and techniques of the data network arena.

The business case for VoIP is simple, reduce the moving parts and players and you gain the competitive advantage. It is easier to find network experts than phone experts. The technology being created for the VoIP space is being done by creative people solving real business problem. They are also using modern business models that are more cost effective and give the businesses real options to solving a vast range of business issues.

We have currently converted 5 of our major phone sites to VoIP in support of 600 users. Phone updates are done by the PC techs using the same tools they use to setup a new Windows users. The days of the black arts being managed by the Merlins are coming to an end and that is a good thing.

The kingdom should be managed by the king on behalf of the kingdom for the benefit of all. VoIP is an effective business tool to get there. Yes there will be scary witches, there always are when you are implementing big change. The alternative is to continue to pay too much, get too little and be locked into old rigid thinking. Modern companies have fought through the technical issues and now are reaping the benefits of mobility and true business control of their phone infrastructure to gain business advantage.

Some benefits to the business are;

Ease of Moves, add, changes (MAC)
- Can be done by PC Techs
Mobility of workers without support calls
- Worker can change offices without have to call for new cabling or setup
Everything is a data drop CAT5e and CAT6
- No more dual copper connections
  - voice CAT3
  - data CAT5e and CAT6
lower licensing
Cost based on users not systems and users
More competitors for different options within same environment
- phone systems
- voice mail
- call recording
- reporting
- phone sets
incremental user costs for new users
- Can purchase as needed instead of in bulk
Session Initiated Protocol (SIP) trunking for dial tone
- Very inexpensive and very reliable regardless of what you hear from your vendors. Talk to actual users of it
- Significant business continuity benefits and toll reduction over traditional PRI setups

Some draw backs and cautions to VoIP

The data network must be checked for compliance
- DO NOT underestimate this. Just because it is working does not make it workable for VoIP
Tough to find a vendor that is good at both voice and data
Tough to get the voice and data teams to behave nicely together
- expect causalities if you have mature teams. This is not always a bad thing
- They need to learn from each other without coming to an impasse
Watch out for the hidden licenses. Read the fine print and ask lots of questions.
Every thing is server based and with all servers then need to be maintained in a proactive way.
Make sure your core data network is near any voice recording software. Voice recording in the new VoIP world is very easy and let unmonitored will kill your data network with traffic.
Make sure you are solving business problems when you purchase some of the optional offerings. This is where their money grabs come from. Do not be afraid of mixing your vendors. Is this new world is it very easy to do because of established standards.

Test from Windows Live Writer

2009-08-17T21:06:00.001-07:00

This is test to see how Windows Live Writer works.

This is me when I prep for my Sensei
Be afraid but do it anyway
Train today to better then you were yesterday to defeat the enemy of tomorrow

I have to admit the tool is really kewl. Setup is a little odd and it does not read the Internet settings from the O/S or IE. For a Microsoft product that is odd.

I will be using this tool on a regular basis. Thanks Frank for showing it to me.

Thoughts on operating systems

2009-08-13T14:24:00.000-07:00

Here is a link to a friend of mine. His thoughts on operating systems is well worth the read.

It is brilliant in its clarity even if its implementation is hard work. Doing things right is rarely easy.

Solution Lifecycle and accountability

2009-07-06T17:51:00.001-07:00

The above graphic demonstrates the influence and accountability for the opportunity, project and production methodologies as described in previous posts. It is important to note that the influenence area is real and should be addressed as an influence and not necessarily permission. By this I mean, it is important to inform the influencing areas and to get their input, however, not all influencers are decision makers. The seasoned Information Technology professional will work the organization to deliver the overall goals and to get influencer buy in.

This is a short post for the graphics speaks, hopefully, the remaining elements. I may expand in future posts by the blogger, ME, is tired now.

Opportunity Management

2009-07-06T17:32:00.001-07:00

Introduction

Opportunity Management is becoming a growing issue for modern IT shops. Why? Increased scrutiny of IT project resource utilization, and the subsequent rise of the portfolio approach to project management.

Many IT projects are fraught with perceived cost and time overruns. The days of "show me the money" and you get your project are coming to an end.
Portfolio management's primary focus is to manage opportunities, projects, and systems. By engaging at the business level early, you can gain an appreciation for the business drivers and the proposed solution design constraints.

This paper will focus on the processes required to manage opportunities that come to or from the Information Technology (IT) group. Opportunity Management moves you away from the "order taker" role and toward the "trusted advisor" role. This move is becoming manifest with organizations challenging their technical teams to deliver business value, not just cost containment. In this scenario, IT doesn't drive the car – it supplies the car. IT is a service-enabler, and Opportunity Management supports the concept of IT being a service-enabler for the business rather than just being a cost center. A cost containment attitude equates to a "no can do" shop mentality, which is not good for your team and limits your ability to get funding for your much needed projects.

Adopting an Opportunity Management methodology is also a good mechanism to work more effectively with the business units, to gain buy-in, and to understand business processes from their perspectives. Respecting each business unit's core competencies, issues, concerns and viewpoint goes a long way toward making any opportunity successful. You may not always understand or even like a given business unit, but it is imperative that you respect them. Doing so will return respect to your area of technology expertise. It will also give them the chance to witness the potential of technology as it relates to enhancing their business processes.

The methodology explained in this paper supports both waterfall and Rapid Application Development (RAD), though this method is especially attuned to RAD. Adopt the mantra "start small, think big, scale fast." By using this approach, you will be able to respond quickly when the organization is ready to scale solutions beyond their original implementations.

This methodology can be used for both short- and long-term engagements. The stages may look onerous upon first glance, but you will find for smaller projects you only need to confirm details at a certain stages. It remains an excellent checklist to ensure you have covered all the bases, regardless of the size of the opportunity it is managing. As you perform more of these engagements, you will find that many of them take on a similar form and you can reuse patterns of not only previous designs, but also of documentation.

The graphic above demonstrates the flow of opportunity Management

Stage 0 – Opportunity Identification

IT is constantly inundated with requests for changes and the setting of priorities, so this step should look familiar to many in the IT field.

Identification

The main focus of this step is to give the opportunity a name and a shape. "What is the big idea?" is a phrase frequently used in this phase of the discussion. Typically, in larger projects and larger organizations, this opportunity may have been defined in the normal business planning process.

The "elevator speech" is all that is needed to identify the opportunity. An elevator speech is a description of an opportunity that can be explained to a potential sponsor in the time it takes to ride an elevator from the ground floor to the boss's floor. There is no need at this stage to get into final costing or even resource planning. A discussion of "What is the big idea?" and "Why is it being asked for?" is the focus. All too often, IT people start thinking about the "How?" and forget what is driving the "Why?" If the sponsor is clear on why this is important, then assembling the how is less likely to get bogged down, because the focus remains clear.

It is important to log every opportunity in a tracking system. The logging mechanism can be a spreadsheet, database, Web site, or even Notepad. It can be formal or informal, but it is critical that it is logged. For example, you could use your service desk to log all activities regardless if they are issues, changes, or projects. Such an approach makes life easier when resource planning and, once captured, it is guaranteed that all users and stakeholders can more readily follow successful processes.

Qualification

The qualification step focuses on placing the opportunity against the overall strategic business plan and moving priority projects forward, while at the same time redistributing other projects and priorities as required. This cannot be done in isolation; and it is not the role of IT to set priorities, but rather to act on business priorities. By providing trusted advice back to the organization, the IT group is enabling the organization to make better decisions with more and better information. And IT has to eliminate the "sell from the install". During a "sell" engagement everyone is positive and wants to make and opportunity work. This is not a bad thing; however, the qualification step is intended to bring the "install" piece into focus. Issues, such as cost, time, and scope have to be mentioned here to validate the opportunity.

Qualification commences once the sponsor has clearly identified the business drivers and a further investigation has become warranted. Determining the requirement for further investigation can be the tricky part. For the sponsor, an investigation is always warranted and he/she usually can't believe you are not jumping all over the identified opportunity. This is where you get to earn your money – this is your opportunity to work with the sponsor to explain the process, and help everyone understand where their opportunity fits within the context of other organizational initiatives. By working with the sponsor, you can help him/her articulate the opportunity using a pragmatic approach.

This process is meant to put all identified opportunities on the same footing and to align similar projects. It is always amazing how similar "different" departmental needs are when you look for common ground. Organizations that take a step back to align similar projects effectively have a better chance of stopping rogue projects and IT teams, and avoiding duplicated and wasted efforts. But by no means do you make this approach a "boiling of the ocean" exercise, because too much time focusing on strategic alignment prevents achieving valuable short-term gains that can move the organization forward and satisfy the legitimate desire users have to have their needs met.

Adopt a "make !T work" attitude (no, this is not a typo). The philosophy behind this is to make the IT components work for you, and to avoid those components becoming barriers to success. Your job is to align your IT services with opportunities realistically, so your organization can make an informed decision of the validity of the opportunity.

Priority Matrix

Using the priority matrix as defined in a previous post will ensure proper alignment and qualification.

Stage 0 Deliverables

Entry of the opportunity into a tracking system.
Identification of the opportunity's sponsors and business drivers.

Stage 0 Outcomes

Opportunity identified and entered into tracking system.

Stage 0 Duration

One or two engagements, which could mean as little as one e-mail or as much as two meetings.

Stage 1 – Positioning

This is the first formal stage in the opportunity management process. The goal of the Positioning stage is to clearly articulate the vision of the opportunity and its inherent execution requirements. This stage usually requires several workshops, especially for larger projects. As with most first steps, getting it right is vital. All other stages are based on the work of this stage. Without buy-in at this stage, the remaining steps becoming increasingly difficult to execute.

Vision Statement

The vision statement must answer the question, "Where you are going?" The vision statement encompasses the guiding statements of what the opportunity must accomplish. Many firms get hung up on this and create long, drawn out statements that obscure focus and lose value. The vision statement focuses on where you are going, not on how you plan on getting there.

An example of a simple but effective vision statement is, "The solution will provide Internet access to our customers, when they want it and how they want." The statement is clean, clear and is the rod against which the solution will have to be measured. If the solution proposed cannot be accessed off-hours, or cannot allow customer changes, then the opportunity cannot be successful. It also demonstrates a first cut at the solution scope. This proposed solution does not include detailed input from partners or other stakeholders, and must be flexible enough to envelop that input without becoming diffuse.

Mission Statement

The mission statement answers how you are planning on getting to your solution. It is a set of clear directions that are specific to the proposed solution. An example of a mission statement from the preceding vision statement would be, "The solution will use the existing resources to develop an in-house Web-based solution for customer self-service." The key is to keep the mission statement as focused as the vision statement.

Business Drivers

Business drivers become a further articulation of why you are proposing the opportunity. It represents the business you are in and why this opportunity is important. The business drivers can be such things as increased revenue, more access, reduction of costs, or response to competitive forces. Either way, you need to explain why this opportunity is an opportunity – if it isn't an opportunity, it may just be a good idea with no substance.

Key Performance Indicators

Too many projects get funding and have resources assigned when they have no measurable performance indicators. How can the project ever close if you do not know when you have arrived? The performance indicators can be such things as the completion of one month-end, a percent of usage measure, or a simple thing like turning down the old system. By stating a performance indicator you have a natural closing point and a positive approach to the project.

Stating measurable success criteria will allow further steps to contain scope. If the scope is for customers only, and a measure of success is to have 5% of your customers using the Web site within one year, when you have reached the 5% mark then the solution has completed a key performance indictor. The key is that these indicators must be measurable, or they fail the test as indicators of anything at all.

Another consideration is that IT projects are always plagued with perceived overruns and dragging-on of issues. By stating performance indicators up front you are engaging the business units to define, in their terms, what represents success. You must get the business units to sign off on this component, as this will ensure their buy-in as the opportunity turns into a solution and then into a production system. At all stages, the business unit, again in its native terminology, must understand that the IT team is working with it to solve its issues. By engaging them in this process early, it also makes it easier to get the business units to perform and commit to testing at the testing stage.

Governance

The dreaded governance component is like death and taxes – it is inevitable. The opportunity must be have an owner and a sponsor. Sometimes, in larger projects, the owner and sponsor are two different groups. Without clear ownership and sponsorship, a project risks being tagged as an IT project; and as soon as the IT group gets involved the tendency for most business units becomes to defer responsibility and accountability to the IT group. This allows units to spread the guilt if the opportunity isn't accepted, and it is the quickest way to achieve failure. We in the IT field have enough of our own projects – we don't need to get saddled with those from other business units.

The business units know their area and hopefully your team knows IT. They come up with the important "Why," and you have to supply the "How." The governance stage provides for an excellent matching of players between the IT team and the business units. This way both groups know their roles and the components for which they are responsible. It is also an excellent way to measure the level of commitment by the business unit. Are they warm, cold, or very hot toward this opportunity? When you start hearing, "I am not very technical, so shouldn't you lead this?" run for the hills – it is an indication of a lack of commitment from the business unit. You are there to provide trusted advice to the organization, not to be the business sponsor. Now is your time to shine and explain your role.

Stage 1 Deliverables

Vision statement.
Mission.
Governance.
Business drivers.
Draft definitions for success.
Input into the solution outline.

Stage 1 Outcomes

Position paper that is no larger than 15 pages.

Stage 1 Duration

One week.

Stage 2 – Validate Business Needs

This area focuses on further refining the business input, its operating procedures, and its opportunity assumptions. The existing and proposed business models must be defined for any proposed solution since the proposed solution must be able to support the activities of the business unit.

Traditionally, feasibility studies can cover up to and including this stage. All the work done here is to further define and clearly state what currently occurs and how the business unit would like proceed. By knowing these guidelines, the technical team can always check to ensure the solution does not deviate from stated objectives.

Core Business

The core business definition is used to validate the overall objectives of any opportunity. If the opportunity does not complement or satisfy the core business, then it may need to be reconsidered. The focus of these core statements is critical to maintaining the integrity of the solution since, should that focus change over time, the solution will be affected. This is recognition that the solution must be designed to be as dynamic and flexible as necessary to manage changes over time.

It never ceases to amaze the number of groups that cannot clearly articulate the business they are in. Many a time I have heard from the accounting department in a manufacturing company that their departmental business is making widgets. Yes, they are critical to the success of the making of widgets; however, what business is the accounting department in? When I hear phrases like, "we are in the business of collecting, collating and deciphering the business transactions for the organization," I am confident the process is going to have a successful outcome. Success is not always measured by the opportunity being realized; many times it is that the sponsors have accepted the opportunity, worked the process, and that they trust the IT department is giving unbiased support for all elements of the organization.

Programs

Programs are the major methods for delivery of the core business functions, and can either be formal or informal. Continuing the accounting example above, some programs offered by the accounting department could be Accounts Payables and Accounts Receivables.

Programs are how the business unit is broken down to functionally manage their services. Not having an articulation of the business and their programs will make any solution definition incomplete. Every step of the process must be able answer the questions: is it supporting the business and, by definition, is it helping in defined program areas? This is a good acid test to ensure the opportunity is being supported and sponsored by the correct group. Many an opportunity, when it gets into the hands of the IT department, turns into an IT project. This is because the opportunity team is not ensuring the core business and program areas are driving the project. Business solutions should not be lead by IT teams. Having said this, it is imperative that IT representation is present in order to ensure all elements of the organization are covered by any technical solution proposed.

Services

Services deliver value to members of a target group. Typically, this is where the program areas interact with other areas of the organization or customer base. Again, following the above example, the Accounts Payable program area may have a service provision for printing Vendor checks.

Typically, an opportunity is addressing key service areas. This exercise should clearly identify the services the proposed solution is addressing. The service areas, at times, may need to add, change, or delete service components. For example, automating approvals and check printing may have a direct impact on an existing check-printing service. This services definition is especially important in any outsourcing engagement opportunity. By not clearly articulating the as-is services, the new services may overlook key areas that cannot be performed by the new service, and adoption of a final solution will naturally fail under that oversight.

Client Profiles and Scenarios

Specific client areas that will benefit from the opportunity are defined. By breaking down the clients into groups, the business unit will be able to define common wants and needs. This client profiling is used to build scenarios.

Scenarios are structured walkthroughs of the proposed solution. Once the profiles and scenario are defined, a series of business unit engagements can be used to build the use cases. Use cases are nothing more than documents in clear business language to define the specific steps of any given user scenario. If you spend the time in the scenario definition, then the facilitation of the use cases is infinitely easier. (Do not allow the technical team to hijack these meetings. The goal of the scenario workshops is not to start coding, but to garner the spirit of the opportunity and its touch-points with the clients and, ultimately, the solution.

The use cases should focus on the actors, events, and triggers that happen. In simple terms, the actors are the internal or external users of the system; the events are the functions to be performed; and the trigger is what caused the function to commence. Do not get carried away with defining all the business rules, but focus instead on the interaction between actors, events, and business units.

Environmental Scan

Before you engage too far it is always best to get an assessment of what solutions already exist, so best practices and best-of-breed solutions should be researched. The usual magazines, trade papers, and technology Web sites are excellent resources. Today, it is becoming easier to find off-the-shelf products for many solutions.

Colleagues are also an excellent place to source ideas. Learn from the ones who have walked the path first. Look for lessons learned and comparative analysis. Don't forget to weigh your needs against the features and do not get lured into features you don't need and possibly will never use.

The key is to look at things from many perspectives, and weigh existing solutions against the maturity model of your organization. You may be able to find the best-of-breed solution from a given product domain, but is your organization able to understand it and use it? Beginning with a smaller solution to get the organization prepared for a more formal discipline is a good approach. Many of the steps described here are not wasted when putting in a smaller, less function-rich solution. Many purists may disagree with this, but too many large projects cannot get out of the starting gate because the organization cannot get its head wrapped around the larger, more complex system. But when this "start small" approach is taken, it is imperative that the organization realizes those solutions are transitional solutions and elements of the final solution. Not all of this interim solution may be used in the final solution, but nor is it a "throw-away" diversion.

Stage 2 Deliverables

Definitions for core business, programs, and services.
Validate the opportunity goals.
Further define the business drivers.
Define the governance model.
Environmental scan.
Input into the solution outline.

Stage 2 Outcomes

Use cases profile definitions and for more traditional approaches the feasibility study.

Stage 2 Duration

One to two weeks.

Stage 3 – High Level Scenarios

This is the first stage in which technology is introduced to demonstrate the opportunity. The mockups are a low risk approach to visually presenting the options. These mockups are not complete solutions and are not intended to be production ready.

This stage is often used to introduce new concepts. Consider the "7 times 7 different ways" theory, which states that to have people understand a new idea will take seven presentations using seven different approaches. In IT today, one of our many challenges is educating our user community on the realm of the possible. Today e-mail is pervasive and you don't have to explain its concepts. However, at one time we spent a great deal of time explaining e-mail as a generic idea. Some of the new challenges are Instant Messaging, document management, and Web portals. To be blunt, most users do not know what they do not know. In older, mature groups they need to a have common point of reference for new ideas. The mockup allows the IT department to show different approaches of tackling the opportunity as they understand the business needs and drivers.

The mockup can be a slide show presentation, skeleton application that demonstrates workflow, or vendor product demonstrations. This bidirectional dialogue between business sponsors and the IT team is invaluable for nailing down the scope and buy-in of the business unit. Most business units like to be involved in this stage and find this part of the process rewarding, so let them play in the sandbox, but make sure you let them know when recess is over. The goal is to get their input in a non-technical environment where they can see and touch elements of the opportunity.

Though mockups, the business unit also gets to see tangible proof that the IT team understood the previous steps and the business problem that generated the opportunity. Changes to the solution, scope and design are accomplished easily here and should be encouraged. Some IT professionals have a hard time with this step, because they want to deliver a more workable mockup. Be careful of this desire – it will waste valuable time and resources. The users are going to make changes, so get used to it, but do not forget to document the change requests. Welcome to the iterative world.

Stage 3 Deliverables

Documented customer profiles.
Documented use cases.
Mockups.
Input into the solution outline.

Stage 3 Outcomes

Solution shortlist and/or workable prototype to be further developed.

Stage 3 Duration

One to two weeks.

Stage 4 – Technology Alignment

After the mockups, the technology team retreats to their development area and designs a system. This is easier said than done, but if it was easy, someone else would have done it already. At each step of the design process, the IT project lead has to ensure the vision, business, program, and service area's goals and objectives are respected.

The design should include logical and physical architectures, and in a more formal organization you would get architecture sign off and guidance as well.

One area that is usually forgotten at this juncture is the support model. This area requires special care. Many systems are not evaluated thoroughly, and will come back to haunt you in the post-implementation stage.

Work with your user community and your service desk (if you have one) early to get a feel for the non-functional requirements of your proposed solution. Will it need "24x7" support, or is "business hours" support good enough?

Compare the solution to your existing infrastructure. Can you support this new solution? Do you have the capacity, skill and/or resources? This is the time to get those determinations documented and clarified.

Compare your solution to your technology blueprint. Are you duplicating functions you may already have? Is there opportunity to consolidate solutions at the technical layers? An example of this might be the sharing of a Web application server rather than implementing a secondary provider solution.

Once the deliverables are completed, a final workshop is provided for the business unit, so that the IT team can demonstrate the solution. Do yourself a favor and make sure you keep the technical language to a minimum. I have seen too many projects where the technical group is so enamored with their solution they can't help themselves, and drown the presentation in technicalities. All of sudden the client asks, "What about this or that?" and you can hear a pin drop for the sudden silence.

This is the final opportunity for the client group to get their message across as to what they need and how the solution must look, so be respectful of both the technical team and the business unit. Again, changes here are not serious because you are still refining the solutions.

Once the user area has signed off on the technical design, you can proceed to costing and a final proposed-solution design.

Stage 4 Deliverables

Updated customer profiles.
Updated use cases.
Support model.
Mockups.
Non-functional requirements definitions.
Logical architecture.
Physical architecture.
Input into the solution outline.

Stage 4 Outcomes

Tangible, workable solution architectures.

Stage 4 Duration

Two to four weeks.

Stage 5 – Proposed Solution and Costing

After stage 4, the final touches can be made to the proposed solution. By now the functional and non-functional requirements have been agreed and negotiations can commence for costing and component manifesting.

A high-level work plan is established to create milestones and costing containers. These costing containers may include such things as training, implementation, transition, cutover, and/or build costs. At this stage, the costs are used for budgetary purposes, and final negotiations should always bring your costs down at the purchase stage. Many groups get themselves into trouble by negotiating feverously at this stage only to loose leverage due to the time it will take to get final approval.

Work should also be done at this stage to tighten up the component elements of your solution. Tasks should be given to the IT team in respect to further definitions and clarity on development and/or interfacing costs. When trying to interface a new system into an existing infrastructure, make sure you have estimated the learning curve component for your team to acclimate to the new system's parameters and architectures. This is not the time to throw stones at the new kid, for we all live in the glass house. Use the "Improvise, Adapt, Overcome" mantra to get your team focused on getting the solution to work. Everybody is encouraged to make it work instead of finding every possible reason why it can't.

Also, nail down support costs for the initial rollout and ongoing support. Don't forget to clarify how the solution will be maintained. If is maintained by the vendor, how does the vendor expect to support you? Is the solution a mission-critical solution? Is the vendor aware how its solution is going to be implemented?

Stage 5 Deliverables

Revised functional requirements.
Revised non-functional requirements.
Update to logical architecture.
Update to physical architecture.
Solution costing.
Support model and costing.
Input into the solution outline.

Stage 5 Outcomes

Rough draft of the solution outline and very high level costs (+/- 25%).

Stage 5 Duration

One to two weeks.

Stage 6 – Implementation Planning

This is where the rubber hits the road. All the work until now, for the most part, has been open-ended with no firm commitments on dates and deliverables. After stage 5, the client and you are committed for the implementation plan.

What the business unit wants to know is, "How long is it going to take and when will we get the nod?" This answer has to be sensitive to organizational approval schedules, other projects, resource constraints, and operational concerns.

The implementation project plan might include the following milestones for a development opportunity:

Deploy and release to production plan.
High level test plan – do not assume the user knows what or how to test.
Procurement and setup timelines.
Marketing communications plan – it is very important to get the word out on the positives of the opportunity.
Infrastructure updates and configuration changes.

Stage 6 Deliverables

Project plan.
High-level costing.
Communication plan.
Input into the solution outline.

Stage 6 Outcomes

Workable project plan and costing figures for approvals.

Stage 6 Duration

Two to four weeks.

Stage 7 – Solution Outline

The solution outline is the culmination of all the previous steps. It is a technical document that will be the main resource for the solution after funding has been approved. Many organizations will get the business units to sign off on this document, but most users do not know what they are signing, so don't put too much weight on their signatures. Do, however, review the document with them to ensure you have captured the business drivers and guiding principles of the opportunity.

The important thing to remember is that the documents will contain all the relevant technical information for the proposed opportunity. Depending on the scale and scope of the solution, this document can be large and not a pretty read, but by culling this document you can build the requirements for the solution and for any Requests for Proposal (RFPs) that may need to be created as a result of this opportunity getting funded. It will become an invaluable resource for your technical team even if it becomes a shelf-filler for your business units.

Your solution outline may contain some, all, or even more than the following items:

Introduction.
Business scope.
Core businesses and services.

Mission statement and guiding principals. Clearly state the guiding principles in the solution outline. This will ensure all players understand the overall guidelines of the solution being proposed.
- Core business.
- Programs.
- Services.
- Types of individuals and organizations.
- Client needs.
- Goals.
- Business drivers.
- Architecture overview – introduction.
- Architecture overview – enterprise view.
- User groups and delivery channels.
- Business services.
- Resources.
- Architecture overview – components view.
- Presentation services.
- Architecture overview – software view.
- Architecture overview – IT system view.
- Logical technical architecture.
- Architecture overview – physical view.
Non-functional (operational) requirements – Do not overlook the importance of getting in writing some of the non-functional constraints.
IT standards – It is always good to state the baseline for which the solution must adhere to. This will give valuable insight into why certain technical decisions where made long after the opportunity has passed and the designers have moved on.

Stage 7 Deliverables

Revised functional requirements.
Revised non-functional requirements.
Update to logical architecture.
Update to physical architecture.
Solution costing;
Support model and costing.
Final report back on solution to business area.

Stage 7 Outcomes

Final report on solution outline and high level costs (+/- 10%).

Stage 7 Duration

One to two weeks.

Stage 8 – Business Plan/Case

Where the solution outline addresses the technical problems and opportunities, the business case addresses the business problems and opportunities. The business case has very little technical information in it and is written to be read by the business decision-makers. The main focus of this document is to state the business opportunity with its associated costs and benefits.

It is imperative to include the business unit in the creation of this document. They have to not only buy-in, but must also contribute to the end result. The organization will be using this document as the core document to make its decisions, so it must be written in common business language and any technical information should be filtered for readability. You do not want the organization to mistake this opportunity as a technical project, and remember that even technical opportunities must drive the business forward.

A sample table of contents of a business case is:

Background.
Guiding principles.
Solution.
Software.
Technology/hardware.
Network.
Cost summary.
Benefit summary.
Conclusion.

Stage 8 Deliverables

Business case.
Revised costs.

Stage 8 Outcomes

Business case.

Stage 8 Duration

One to two weeks.

Stage 9 – Funding Approval

The "hurry up and wait" game begins here. All the effort, time, money, and resources are now on hold until you get the nod. If this project is high profile and important you may be working the back room to sell the opportunity before the formal approval process commences, so you want to make sure the elevator speech is being worked at all levels.

Stage 9 Deliverables

None – trust the process.

Stage 9 Outcomes

Funding approval or a "go/no go" decisions.

Stage 9 Duration

Dependent on how your organization approves opportunities.

Stage 10 – Implementation

It has been correctly said that you should be careful what you wish for, because you may just get it. The fun is over when the project has been approved, because now your team has to deliver the promise. The main source document is the solution outline, and depending on the time lapse between its initial creation and your approval to implement you will have to update the numbers and project plan accordingly.

It is important you get sign-off on all changes to the solution outline and business case prior to implementing the previously agreed plan. The line "Don't confuse the sell with the install" comes back again to haunt. The sell cycle is always fraught with positive statements and "don't worry" attitudes. However, once the contract is being presented, the install side of the house arrives to take all the fun and money away. This is also a good time to get the vendors to commit to their schedules and resources as were agreed to in previous steps.

Stage 10 Deliverables

The solution as agreed to.
Execution of the project plan.
Execution of the communications plan.

Stage 10 Outcomes

Commencement of proposed solution.

Stage 10 Duration

Dependent on implementation schedule as defined in stage 6.

Conclusion

These steps, at first blush, may appear too complicated for most IT groups. However, upon review you will find you have been doing most of these steps all along. This methodology was meant as an "aide de memoir" to ensure your opportunities are given every chance to succeed, and for you to gain valuable input on why the business units are looking for your team's help.

This methodology has proven very successful for both small and large projects. It can span from one week to many months, depending on complexity and scope. After the first few formal uses of this methodology, user groups will grow to understand why previous IT projects failed. One of the major reasons they fail is a basic failure to speak the same language across boundaries within and without the organization, and this approach rectifies that problem by its adherence to a well-founded process.

Being involved in the opportunity stage is new to most IT groups. They are used to users coming up with requests and then being tasked to complete them. This methodology puts you in the trusted-advisor role within your organization, where you will become part of the decision making process. You will be providing the organization business-value through your input and pragmatic approach. The goal is for them to succeed, because when they succeed your IT group will be validated.

Some organizations have swat teams for opportunity development. These teams consist of Web design, graphic design, infrastructure support, business analysis, telecommunications, and customer support. It sounds impressive, but for some opportunities all these roles and more are needed to prove or disprove the opportunity's viability. The bottom line is an opportunity team is a small team that is able to be creative and drive the business value forward.

The risk of not getting involved at the opportunity level reduces the IT group to order takers. By being an order taker, you are bound to the business area's comprehension of the overall business needs and your unique requirements of trying to keep their house of cards from collapsing. As the competitive forces increase and the user community gets more knowledgeable about IT, the ability to manage opportunities will become paramount. Most IT groups are feeling the pinch now. The wave is coming, and it is better to learn to surf then to be swept up by it.

Priority Matrix

2009-07-06T17:15:00.001-07:00

Over the next few posts I am going to focus on getting the priority quantified, justified and aligned. This is both a formal and informal process and the Information Technology professional has to ensure that the large list of projects are properly dealt with. All to often we get transfixed by the projects we want to work on or the last one in the door. Either of these conditions can be deadly for the overall effectiveness of your team.

Priority Matrix

Using the priority matrix will give the organization a visual perspective of where their priorities align. On a regular basis, opportunities should be placed on the matrix for comparisons and synergies. What was deferred last time may be ready for action now, especially if your identification process has made a continued to effort to a build common technological framework for delivering business value.

The axes and quadrants of this matrix represent a powerful tool for qualifying opportunities.

Ease of Implementation

How difficult will it be to implement the opportunity? Do you have the correct skills? Is the organization ready? Are there obstacles in the way of success? Can success be measured? These are some of the critical questions that need to be answered before you extend too many resources to the development of the opportunity.

Social/Economic Value

Too many opportunities are measured on pure economic value. This method has proven to be successful in building an organization, but in a highly competitive marketplace more factors need to be considered than just the old standbys. Many opportunities have a social benefit that is difficult to measure – for example, social impact is often overlooked when qualifying employee portals and intranets. Many opportunities are lost when faced with the concept "if it isn't broke, don't fix it." Successful organizations take the time to quantify all benefits, and to build environments that are moving the whole organization forward rather than just handling the issues relating to sales, manufacturing, and/or finance. The entire benefits of an opportunity should be investigated when bringing new opportunities forward. The challenge is to quantify the benefits in the context of business value.

Even more critical to qualifying opportunities effectively is to understand the quadrants of the matrix in relation to the potential for positive business impact.

Plan

This quadrant of the matrix is for those projects that are less difficult to implement, but have a lower Social/Economic Value. Basically, this quadrant contains the "nice to have," but not the "need to have" opportunities and benefits. Timing is everything and the projects in this quadrant generally spark up good positive interest, but the organization isn't prepared to implement them now. Typically, these projects will see the light of day, but just not in this round of approvals.

Do Now

This quadrant speaks volumes for those opportunities that are easy to implement and have high Social/Economic Value. The low-hanging fruit analogy works well here. These opportunities should be moved forward and funded to advance the organization. The value to the organization can be immediately achieved and the organization is comfortable with the overall fit. The projects align well with any strategic plan or roadmap. These projects were typically once in the plan quadrant, and have since become practical.

Review

When the value is high, but the implementation becomes more difficult, it may be best to review and build a funding proposal. Most new opportunities that require the organization to break new ground will tend to fall into this category. Also, these opportunities tend to require more detail before the decision-makers are comfortable giving the nod to proceed. Overall, these are good opportunities. A fit is recognized, but the comfort level by all the parties is not there. By providing more detail, the organization will be able to make a more informed decision. With opportunities under review, it's a good idea to go back to the business drivers and substantiate the findings, and also go back to the technical options to see if adjustments are needed.

Wait

The Wait quadrant is for those opportunities that are deemed difficult to implement, and where strong value statements are difficult to quantify. These opportunities are typically beyond the current scope and understanding of the organization. Opportunities in this quadrant typically need to have a communications or an awareness plan developed before they can be advanced.

Enterprise Architecture

2009-06-30T06:32:00.000-07:00

The art and science of creation

Today, the word architecture in the Information Technology arena is not always used in its correct context. As one of the silver backs I can remember when we used the word engineer as a freely as we use architect today. We had customer engineers, solution engineers, hardware engineers etc…. Some uses were correct and others were very loose interpretations of the term. Today we have information architects, solutions architects, network architects, voice architects and the likes of usability architects. Again, some correct, others, well, just good old marketing.

I personally take architecture very seriously.

The Webster’s dictionary that I possess at home states the following:

Architecture – The art or science of building; that branch of the fine arts which has for its object the production of edifices pleasing to a cultivated and artistic taste; construction.

How real is this? Architecture is the marrying of art and science. The production and building of edifices (technology) that is pleasing. Pleasing becomes the operative word here. Just because something is built does not mean it is architecture. It just means it was built.

Architecture is like so many other borrowed terms we use in Information Technology, and made our own. This one in particular is of special interest to me because I take it so seriously from its purest beginnings and meanings. We stand on the shoulders of giants rings so true in this arena.

Some of my previous posts talked of the IT Stack and its importance for sound design. Enterprise architecture follows many of the same truisms. The IT Stack becomes what a draftsperson is to an architect. The architect has a vision and translates it into real-world designs. The architect then works with the draftspeople to iron out the real world forces. When we were all called engineers, I baulked because too many engineers only know the known and do not push the limits. The architect starts with art in mind and then transfers it to real engineering problems to be solved.

The graphic above demonstrates the 4 key domains for enterprise architecture. Some enterprises will have more domains and that is just further fragmentation of the arts and sciences. The department of defence has taken a much deeper view, but if you were to step back the 4 main domains this post will encompass the others in some form or other.

The graphic has the business domain as its center and I believe it is the lynch pin that binds the other three. With the business domain of “why”, the other domains of “how” become support players to the main event. Even the best historical architectures had an underlining purpose. These edifices of wonder were able to solve the need with special designs. The pyramids, the coliseums, the churches and the grand bridges that have stood the test of time have also stood the test of good taste. I remember standing in the Saint Michel castle in France and witnessing the formidable architecture that was over 1000 years old. The basement did not leak, the walls were not cracked and the roofs have sustained the mighty gales of the English Channel. In its 1000 plus history the walled city had never been breached and the trained eye could see the advancement of technology in the buildings while never giving way to the sheer beauty of its architecture.

In modern times we have such wonders. Time will tell which ones were true to real world realities and have lasting artistic value.

The information technology craft is new and as such is prone to flux and at times chaos. Now is the time to gain back some creditability to move us forward. Many believe the pace of change has been too fast. I could not disagree more. I feel we have been hindered by technology business models that have rewarded the quick and easy and not the long, difficult, right way.

I was speaking to our owner regarding the “cloud.” Our owner is a self made multi-millionaire and a companion of the order of Canada. He has prided himself on honest, pragmatic business. He has been rewarded for his principals and he is also the holder of several key transportation patents for his forward-thinking designs. By his own admission he knows nothing of computers. After about a 10 minute explanation from me comparing the “cloud” to 3^rd party logistics companies he started to understand. That analogy is the best I could come up with where you do not own the assets but leverage them. My owner had a pregnant pause for about 20 seconds. This is a long time for a man of his drive and passion. His response was short and very direct. The reply was “what took so long.” For him it was so clear, yet, we as an industry have not been able to exploit it and move it forward yet. The answer to that riddle took a little longer. Over several beers he came to realize that the technology sector is not rewarding leaders of technology but rather managers of business. The business model is sound but the debates over what is or what is not the “cloud” is preventing us from moving forward as a whole. This is not good business and even worse technology. His response was, you had better agree on that you need a road and that everyone has to be on the same side of the road. He brought our problem back to his transportation world.

This is a long pre-amble to state that without a real business reason any architecture is strained to deliver value beyond its artistic impression.

Business Architecture

This is the core domain and it answers the biggest question and that is the “why”. The next area of concern for this domain is what, who, where, when and which information is relevant. The process thinking person is well suited here. The business domain is about making the logical connection between business information and the processes that drives it and relies on it. A good business architecture model will drive all the other models and be used as the referential checkpoint for all the other domains.

Be careful of the process purist. These individuals tend to pave the cow path and have data needs that will strain good data governance and control. The process should solve the business needs in the fewest possible steps, in the most secure way, with sufficient oversight to be managed and to be improved. All architecture domains need to be built to be built upon.

The strategic business view needs to be broken down into tactical components and then into operational elements.

The business domain will map the people, their processes, and the tools required to complete the business requirement. I am a visual person, so I will draw many process and mind maps to isolate the patterns for improvement and critical success. The information going back to the organization must be presented in the form the business can understand. The artefacts also have to serve as the core building blocks for the other domains. Constant checkpoints from the other domains have to be made to ensure the business domain is adhered.

Technical Architecture

Some groups will call this domain the infrastructure domain. I am part of that group. This domain manages and controls the hardware and software of the organization. Along with this it will adopt secure methods for all other elements of the solutions.

The biggest and most valuable artefact from the technical architecture is the blueprint for the functional and non-functional requirements. I pay special heed to the non-functional requirements, for these are the ones that tend to get overlooked and cause the greatest strain during implementation.

This domain also has a large role to play on cost minimization, technology blueprint adherence and the proper implementation of standards. A good implementation of the technical architecture will become the building blocks for other domains and other business solutions. This domain should focus on flexibility and reusability. The patterns derived from this domain are almost always used for other solutions. This domain also provides a strong blueprint that can be used for all following elements, especially security.

Solution Architecture

Solution Architecture is the glue that binds the data models to the technical models to deliver the business model. Some groups will call this domain the application domain. If you are new to an organization and their enterprise architecture group, then make sure you get their taxonomy clear. Some groups can be very particular on this.

Solution architecture starts to make patterns from the business model, to feed the data model, and will be supported by the technical model. The focus here should be on component modeling and the carving down of major functions into smaller more reusable elements and modules. Strong adherence to security, interface design (internal and external), data connectors, messaging, auditing, logging and version control become paramount. The project manager and the business sponsors need to conform to the business model and the non-functional and functional requirements. Scope creep can be a real issue here and controls need to be used to keep the team focused.

This domain will also be faced with the greatest iterative steps and the greatest use of lifecycle management. The users will be playing in this backyard with little or no expertise and it becomes paramount that the solution architecture stays true to the business architecture. When there is confusion, a checkpoint must go back the original model to ensure the business needs are being met. At times this domain can get enamoured with scientific or artistic discoveries. The architect is required to keep the final vision in focus and not the current unforeseen discovery. This is a real discipline and the best solution architects have a strong eye towards delivery rather than discovery.

Data Architecture

This is likely the oldest of the disciplines and is the genesis of many other methodologies. It is computer science 101 and is the most abused of the disciplines. The advent of spreadsheets and personal databases has muddied this craft. There are many who think they understand data models but the ones who really do get frustrated by the poor data models and database implementations of the others. Another issue that arises is the forced use of old techniques when newer more effective approaches are warranted. Modern databases support auto indexing and the old technique of composite keys only burden the systems for downstream business analystics.

The conflict has always been present between the data purists and the process purists. The fact remains they must be in balance and work complimentary.

Data should be modeled to reflect the process’s use of the data and yet still be able to convert the data into information. I have seen overburdened data models that span thousands of tables where similar applications patterns have used 100 of tables. The pure data architect can justify both but only the enterprise architect can validate which ones solve present problems.

Modern databases and database options need to be exploited in a positive proactive way. Privacy and security issues can be enhanced within this domain for a more robust overall solution.

I really enjoy seeing the application domain come to life within the data model. Many of the business model patterns can be tested and vetted with good data architecture. For in the end if it is not stored it does not exist for the other domains in a complete enterprise world. I know some knowledge management folks have just cringed. Data architecture takes into account all structured and unstructured data to complete the information picture. Once these patterns are complete and available they become a source of knowledge.

In conclusion

Without architecture we have form without function. With good architecture we have function with form that is pleasing. We have all witnessed good architecture even though we may not recognize it as architecture. To some architects that is the highest compliment. I am in that camp. When it works in its simplistic form to solve the most complex of problem, the Architect has successfully created art from the sciences.

An architect’s vision without execution is just a drawing. With execution come future patterns to be used by others to further the craft.

The case for blade centers

2009-06-14T21:29:00.000-07:00

When it comes to blades you have to realize of couple of baselines. The first is that you must understand the value of virtualization. The second is that you have a long term view of your world.

So now that we have established the value of the baseline, you need to understand the two main types of blade setups. The first is many applications on one blade center and the other is many blades servicing one application. The latter is way kewl and is what we use to call “grid computing”. That buzzword has fallen by way of the “cloud” and other similar useless marketing technical terms. I will focus this post on the many applications on one blade center. Please read my post on consolidation. I am even using the same graphic for it is that similar. I am also lazy and graphically challenged.

In the past when you had to replace a server or had to buy a new server for new applications you were forced to use a crystal ball. Yes there were many tools to aid you but in effect you had to estimate what you were going to need for several years. In the first years the computer is oversized and underutilized over time the server starts to get utilized as per the requirement and without due diligence the server will become overworked and over utilized. The roller coaster effect takes over. This is the reality faced by most organizations.

The advent of blades allows you buy as required and expand as needed. The initial costs of the infrastructure are high but you can add server instances in places where it would have been tough to get funding. Overtime the cost per server is dramatically lower. Do not underestimate the value of this. It is also a caution to prevent what is termed “server crawl”. The proper implementation of blade infrastructure will reduce more costs than just the hydro and air conditioning that everyone is talking about. It gives management and extreme flexibility and a pay as you play approach.

By using a hypervisor you are able to adjust the supply to the demand without the long processes of procurement and implementation. Benefits of backup and system management now become more manageable as well. The big win, regardless of the marketing hype is that you can actually think big, start small and scale fast.

On a vendor note, be careful of the hype. Deal with vendors that know data centers and that have blade technology for your environment. Some manufacturers are for the many blades to one application model and others are for smaller shops that will not expand beyond the one blade center. Know your business problem before you buy and commit.

Currency Exchange

2009-06-14T20:48:00.000-07:00

The concept of currency exchange is as old as time. However, it is not about the currency it is about the exchange. Before we had currency we still had exchange. Some would argue it was better before the advent of the money makers.

What I find so difficult these days is that we have all forgotten about fair exchange. The recent demise of our great, or not so great, manufacturing and finance giants says more about bad business than about some sudden change in the world.

When did making a good product, at a fair price loss to corporate management? I must not have gotten that memo. Oh wait, it might have been an email disguised as corporate direction. All kidding aside this is a serious issues and one that affects us all and especially us in the Information Technology field.

We do not always deal with actual currency but we trade with other currencies every day for most every decision. I build trust and relationships with the same respect a farmer does for his crops. I know that if I follow the process respectfully and I watch the crops to ensure no weeds, bad soil and such disrupt the planting then I should be granted a good crop to barter for other needed things.

This takes the shape of having people trust you when you say your project will be completed on time and on budget. In the event of slippage you may have to give up some of your non-cash assets to offset your project issues. This is not a light issue. I am astounded at people who just come up with dates as a placeholder and then say “oh well, missed another one”. These are the same people who whine “why are we not respected?” What did you do to garner that respect?

I am a senior Information Technology guy who has built a career fostering and building relationships. In fact I take great pride in them. In doing so, I have been able to exchange with these relationships things far more valuable then currency. These relationships have allowed me to very successful and to provide many rewards to the other parties in these relationships. It is a constant spending and saving exercise.

I have a penchant for seeing dumb people and bad ideas. When faced with this I get very agitated and somewhat cold. I make no apologies. If you profess to be in my craft you had better be prepared, be focused and be knowledgeable. This is not a challenge but a position of what I call mutual respect. I give you the respect of listening; you may want to give the respect of speaking respectfully. If you think a currency exchange will right this wrong you are sadly mistaken.

If you are a young Information Technology professional and you are starting out in a new position this condition will arise. One day you are going to witness your boss having a social meeting with another department head or a vendor. This can be viewed several ways. The first is of envy and you think “must be nice” the other more pragmatic way is “what are they talking about and how can I learn”. Now if your boss is the laughing stock of the company, the former response is likely valid. However, if your boss is highly respected you are likely witnessing a valid currency exchange. What you are witnessing is the natural give and take of negotiations. Most negotiations are built and over before the formal process begins.

This currency exchange can be between family members, lovers, friends, vendors, suppliers, customers and the like. If all you have is money to exchange then your relationships will be short lived and not very meaningful. It will be fast food approach to life and business. Rarely, in a professional world does the one with the money wield the power. Typically in the technology field the one with the knowledge is in the stronger position. Good business executives latch onto this and make sure there is more than just money in the exchange. Sadly as I look around, I see the old trappings of perceived wealth abusing the hard working. This will end, but it will take everyone remembering a fair exchange is derived from trust, respect and grounded in a common valued system.

You might be asking what spurned/spurred this email. Well it is like this. In the scenario above my new hire to our team did not take the time to learn what relationships I had built and as such destroyed the working relationship between our firm and three of our trusted advisors. One is completed lost and only my personal friendship is left. That one is a great loss to our firm. The second was easily explained and the third with be like the first. I will be able to sustain the third but only through friendship. The real loss here is that the individual still has not learned the value of the real currency exchange. One might asked why they are not fired. Sadly, spineless Human Resource departments prevent the right thing from happening. The only saving grace is that since my new team member will have it more difficult to complete their tasks with these advisors absent makes a good case for poor performance. It will be long road for us all since the basic rule of relationships was lost.

That is why in the Information Technology field some users and departments get things done ahead of other ones. Chances are an informal currency exchange was being adhered to and that is not a bad thing.

Onboard computing realities

2009-05-19T20:18:00.000-07:00

Onboard Computing

I was recently asked by an onboard computing company to be on a customer panel to answer questions. They provided all of us some questions to answer and this post will share with you my answers.

Before the questions can be answered several things the reader of this post needs to be aware of. First what is onboard computing? This is actually one of those simple questions to answer. It is a device attached to the engine system bus of vehicles. This device collects engine information in real time and stores it for future retrieval. This retrieval can be immediate or a store and forward approach. These vehicles in my case are large tractor trailers and our straight truck fleet. We currently have over 800 of these units rolling around North America. In fact I have more rolling infrastructure then static desktop computing. Also, the computing power and complexity is higher on my rolling fleet than anything on my accountants desktop.

Modern onboard computing is the ability to monitor the vehicle geometry (location, speed, rpm, braking etc) and driver behavior (hours of service, speed, cruise, lights, wipers etc) and bring the back office into the cab (driver messaging, pickup information, delivery information, signature capture, fuel tax, image scanning etc). Seems simple enough, oh but wait, if it was simple all of us would be doing it. You need to be aware that most trucking companies’ equipment committees are not tied to the backend accounting needs. The push and pull is everywhere. Traditionally if the rolling stock needed new toys, voila the money is/was found. Over time this becomes a very complex dance between perceived value and benefit with real cost of support.

There are two main camps in this arena. The first camp is all about driver and vehicle data. The old world of tacho-graphs and vehicle data lead the way. Our firm is squarely planted in this camp. This is typically the camp of the early adopters. Before backend systems had reliable means of real time connectivity the store and forward world of driver/vehicle data was one of batch reporting and driver coordinators who enforced compliance based on these reports. This is not a bad camp to be in if it can move forward. These types of solutions are usually very proprietary and closed and very good at collecting data. Not so good at making information out of it though.

The next camp is the one that wants to bring the back office into the cab. This is the where the late adopters find themselves. The technology has matured and the industry as a whole is comfortable with baseline vehicle and driver information. These systems typically are newer, open and standards based. The support groups of trucking firms really enjoy these platforms for they are easier to support. With anything new, there are issues to work out but all in all they are excellent approaches to solving real business information needs.

What about the driver. In most worlds the driver is actually forgotten by the technology unless the firm forces driver feedback. This feedback can be in the form of messaging, panic buttons for safety, audible alarms to enforce safety rules and give attention to immediate action. Some of the technology is actually used to improve driver skills. An example of this is lane departure software. This type of software emulates the rubble strip on the sides of the highway so the driver is aware of any drifting. It is very sophisticated in the math of determining if drifting is occurring and over time the drivers have had positive feedback on its accuracy and then by their improved handling of the equipment.

So what is in it for the Driver?

Real time feedback on equipment issues. For example spike break, lane departure, fatique
Panic button
Communications to and from dispatch in an non-obtrusive manner
Driver safety - Hi-jacking prevention and alarming
Driver pay based on performance
Reduced paperwork (driver logs, fuel tax, trip reports, pre and post trip inspections)

So what is in it for the vehicle?

Effective and proactive monitoring of engine performance
Fuel usage
Safe handling
Extended vehicle life
Proactive and preventative maintenance procedures
Consistent, predictable usage pattern regardless of driver

So what is in it for the organization?

Getting data as close to source as possible
Creating information from data
Increased customer service
Customer transparency
Reduced labour to support operations
Real time tracking of fleet
Heightened security position
Better competitive edge
Ability to make decisions faster and with better context

Here are my answers to the questions.

Question 1: How has technology in the cab provided your organization a competitive edge?

Answer: The technology deployed gives us near time information on business and operational performance. Our customers have complete visibility into their freight. Our bottom line is positively affected by lower costs, higher safety ratings, and predictable operational performance. We are in effect proactive not reactive to the marketplace.

Question 2: Has technology enabled your company to operate in a safer environment?

Answer: This was one of the biggest drivers for our onboard committee. From driver fatigue, to driver safety, to safety compliance we are able to work with the driver to improve safety both for the equipment and more importantly for the driver.

Question 3: What best practice has your company implemented to get driver buy in?

Answer: We have a pretty proactive and progressive driver committee and driver coordinator team. We run pilot projects and get driver feedback. We adapt the technology to fit the needs of the driver and the organization. We are always very aware of providing real time feedback to the drivers. This can be achieved through visual or audio cues in the cab.

Question 4: How do you see government regulations affecting your business?

Answer: We see the government finally taking the advice of our associations to adapt the technology in a supportive way. To be more accepting of digital information. We also see that there is still a lot of education required on the parts of government to understand what the industry is able to provide. One of the challenges facing some of the early adopters and proactive firms is information overload to the government. Some of the late adopters are just providing baseline information and not giving context to the information. This is leading to a dual standard on the road. Governments should align reporting requirements with reporting templates and guidelines.

Question 5: How does the government inter-play affect your technology buying decision?

Answer: More attention is being applied to things like driver logs and this is a good thing. The late adopters have an advantage here where some of the early adopters are struggling with technology architecture issues.

Question 6: How is technology enabling your organization to take advantage of fuel saving best practices?

Answer: Along with safety this is the largest benefit achieved by onboard computing. Elements such as idle time, progressive shifting, speed, excessive acceleration and rapid deceleration. All of these elements have given real saving to fuel and repair costs.

In Conclusion

Onboard computing is maturing to a state that not having the technology is no longer an option. We are at the stage that just having the technology is not good enough. The firm must be able to leverage the data to make useful information with it. Otherwise it becomes an exercise in diminishing returns.

Stubby Pencil Principal

2009-05-12T12:49:00.000-07:00

Technology as the tool

This post is being written to address how technology is meant to compliment the business and not complicate the business.

All too often, businesses and organizations look to technology to solve problems. However, sometimes technology is the problem. The organization must be able to articulate what the organizational problem is before a solution can be explored. Remember I am a technology person and I am saying be cautious of technology. Pay heed, truly.

Here is a true case study and the acid test I use almost every day. During the big space race of the 60’s both Russia and the USA were posed with the same problem. How will the astronauts write in their logs in zero gravity? This was/is a real problem. The countless checklists, science experiments and daily logs are a reality for this type of adventure. The USA Team through NASA started on the zero gravity pens. They Spent 10 of thousands of dollars in its research and came up with a swanky solution. The US astronauts were unaware of the great technological advancement made by the zero-gravity engineers but were happy they had a writing instrument. The soviet cosmonauts were given simple pencils and were equally happy. Both solutions worked and worked very well. Hence this is what I call the stubby pencil principal.

The lesson to be learned in the above case study is, “what is the problem?” Both teams understood the problem. The US team wanted a unique technical solution, while the Soviet team just wanted to solve the problem. Again, both worked. I liked the pencil solution for it was quick, relevant, inexpensive, easy to support and allowed the rest of the engineering team to focus on other real new problem like how to navigate back to earth without melting the humans in side.

Every day I have conversations with people and they come back to me with “how can technology solve the problem?” More times than not, I counter with, “let’s look at the current process”. Address that first.

Humans have been using tools and technology since the cave man and its early use of clubs. The tools then as they should be now were used to solve a specific problem. Craftspeople took great pride in making the tools and then allowing other craftspeople to use the tools. What changed? Simply, it comes down to respect and attitude. When we had only hand tools in the house building industry, each craftsman made sure their part was done well for everyone else would benefit from their work. Today with the advent of almost every tool imaginable and with the mindset that fast is better we get poor work from the beginning to the end. We have the capacity to do more with less but what we end up with us less with more tools.

I still love to witness good craftsmanship whether that is in woodworking, sewing, iron works, painting etc. The one thing I have consistently found is that the correct tool with the correct craftsperson creates art. The correct tool with the wrong person is considered work. The wrong tool with the wrong person produces junk.

Take the time to understand the problem, look for several options and when you are committed to a solution then put it in correctly.

I heat with wood and my wife and I enjoy the process of wood heat. You have to go into the bush, select your trees, drop your trees, cut your trees into stove length, split the wood and then stack the wood. On the surface, why bother? But in reality we have an appreciation for wood heat. We do not over stoke the fire box. We run the house at a reasonable temperature and we are always sensitive to effort required to heat. We are also aware at every stage of the next stage. By this I mean we do not rush and cut any tree, but rather the ones that can be dropped safely, handled with just the two of us and of the correct species to provide maximum heat for the problem. Of course this is not an option for everyone and I am not proposing that every heat problem can be solved with wood. What I am suggesting is that knowing the problem, respecting the options and deciding on a course of action that fits what the organization can support is the correct path.

The same goes for businesses and organizations. I tire quickly when speaking to business leaders who tell me their technology problems to nauseam but cannot express to me the business problem at all. This is tantamount to listening to an electrician telling me his hammer is broken but he cannot express to me why the house has no power.

The same is true when I see accountants using spreadsheet to send text documentation to someone. It amazes me that it can be done when a word processor would have been better. In most cases the accountant is not willing to learn a new tool and is forcing everyone to adjust. This is another form of disrespect.

The current attitude of waste and to throw more technology at problems is only creating bigger issues and forcing the real craftspeople to shake their heads in disgust. I have a saying “those who think they know really annoy the ones who do”, applies here.

Let business do what they are in business for and let technology in all its flavors support that business as a supporting actor and trusted advisor.

Have fun and be safe.

Leadership and Management

2009-05-01T08:14:00.000-07:00

Leadership and Management

Ok this discussion could go anywhere and it is as old as time. The questions that is mostly asked is can a leader be made or are they created? I will attempt to give my perspective on this. Again, this one may turn out to be more of a rant but I feel under these times of stress and crisis it is important to have this discussion.

Leadership and management are both required for any organization to be successful. There are many business schools that cloud the issues and interchange the words. I completely disagree with this thinking. Do not get me wrong both words are very positive to me and they are very real roles. However, there is a difference and I will attempt to explain.

Just so there is no confusion, I will state that in my opinion leaders are born. You can teach leaders to be better and give them more tools to work from. I have the same opinion of trouble shooters. You can make them better with training however; they need the character to start from. My personal opinions of those experts whom believe the contrary are saying it to sell the snake oil of their training programs.

Management

Management is the care and feeding of an existing system to make it better and to be efficient. You have management of people, time, scope, quality and a whole ream of other things. In the end, a vision was created by someone or something else and it is now the management of those strategic, operational and tactical items that is important.

Management is critical for any organization to be successful. Well managed teams and organizations can weather many storms and are difficult to knock off balance. However, when real change is needed by the organization to succeed management will struggle with how to solve the problem. Recent events of the economic crisis are case and point in this. Large very well managed companies are failing to respond to the situation. It is because the management team was closed to real inputs and changing factors. Crisis of what we are facing do not happen overnight. It is a long term effect of poor management decisions not necessary poor management. The goal of management is to keep the collective calm. The graphic above is an attempt to illustrate the concept. The consensus concept is not bad; in fact, it is a great management style. However, the concept does not promote innovation or free will. That would cause management issues and those issues must be excised to keep order. This is why well managed organizations can weather a storm but rarely can avoid the storm in the first place.

Then we get into management promotion from within. This is also a two edged sword. You get the insight from someone who has history with the firm; however, this promotes a closed system. Strong management teams promote this behavior and it causes the system to become stagnant and less resistant to change.

Leadership

Leadership comes in many forms. It comes from all levels of the organization and it must start with personal leadership. This is the type of person that steps away from the crowd and asks “why” or “there has to be a better way”. Innovative and creative organizations promote this behavior at all levels not just within their management ranks. Leaders take charge and make the tough decision even in the face of personal adversity. A leader who puts themselves aside and does the right thing for the collective is the true leader. Many leaders can be confused with charismatic managers. Do not confuse the two. Look at what visions leaders leave behind. A leader leaves a lasting imprint on the organization and charismatic managers leave the group with a good feeling but not a clear vision to follow.

A leader by my definition is someone who can positively get someone to do something that they would not have normally done. Once completed it raises the personal bar as it were. By doing so, the person being led is now better for it. Some people are great manipulators and can get people to do things they would not have done. The acid test is the person doing the work better for it or just the person asking for the work done?

A leader leads from the front, is the last to eat, first to rise, the last to sleep and takes care of the people under their care first. Most management schools don’t even recognize what this sentence means and that is why it is a management school.

In times of crisis leadership must be promoted to navigate the storm not just weather it. Sadly, the world is getting lean on leaders and too rich (multiple context) on management. Leaders seek consensus but are not framed by it. Some examples of current leadership are Tony Blair, Winston Churchill, John F. Kennedy, Pierre Trudeau, Margaret Thatcher and Barrack Obama. All of these people shined in crisis and struggled in calm. The collective are quick to cling and to be lead through the storm, however, once the clear sky appears they want to return to the comfort zone. Sadly, we as a society are too quick to penalize the peacetime leader in favour of the manager who can split the financial hairs to get more bonuses and perks for the elite.

General Motors was well managed but very poorly led and hence they are on the brink of self made collapse. The management team was so use to drinking from a fire hydrant and so far removed from the product they made that when the customer went elsewhere all they could say was, “heah, we are number one and if we fall the economy fails”. How sad is that? People are still buying cars, just not theirs. Good leaders would have known to build something that will get purchased. The examples of this are many, current telecommunications companies, air lines, cable companies and hard goods manufacturers all need to learn from the auto crisis. Get out of your offices and go and talk to your customers. Learn what they need and want and stop thinking we are cows to be herded.

In conclusion

If any of you are Star Trek fans you will know the borg. The borg is management and they were powerful, however, a strong leader, Captain Picard was able to get the management (borg) to fail at its lowest unprotected system. The system attacked was to lull them to sleep. They did and the captain won. When we look at recent events and we see how simple the failure was and how pervasive the abuse was it is no wonder that leaders are excised from the management teams. Our recent ails are based on greed and selfish management teams whom have lost touch with what business they are in.

People remember leaders; leaders need management and management needs leaders. Once leadership is excised all management system will eventually fail. Look around you, are you the leader or just the manager. It is your choice and your choice alone.

My mantra is “Lead, Follow or get out of the way”. This may sound crass but take a deeper look and you will see the mantra is just stating, “Know your role”.

Curse of bad communications.

2009-04-28T22:47:00.000-07:00

The curse of electronic communications

The image above, at first glance, is about balance. In this case it is about my two passions on bad communications. The first is arrogance and the second in ignorance. The twin curses as it were. Both are bad and way too many of us hide behind it. I will forewarn the readers of this post that this is a rant.

Arrogance

Let me deal with arrogance, especially in the Technology field. It manifests itself in two forms. The first is the thought that since I know more than you in technology then I must be better and therefore treat all lesser mortals with disdain. The second flavor is that since I know Technology I must know it all. Both these conditions can be found when people speak with acronyms and double speak. When you read an email from a technology person and you want to “bitch slap” them it is likely their arrogance shining ever so brightly. I have on occasion, printed the email (environmentalists stay calm) and sat down beside the individual to ask them to read the email to me. Now I am a big guy and this effect is always powerful. My point gets made very fast. You wouldn’t speak to me like this in person so why are you putting it in an email. As you can tell, I do not tolerate this and we as a collective shouldn’t either.

This is also witness by short terse emails by support people that just take for granted that everyone has been ordained in geek speak. My theory is that if you can’t explain it in real paragraphs with real sentences then you are the idiot and should take a lesson on proper communications. I blame this on incessant email and text messages for this. Our youth may have their own “text” language but as a society is it lessoning the human factor.

Email has no tone and sorry smiley faces don’t really give the professional polish I expect from my staff.

Ignorance

This one is more passive aggressive and to some it is well hidden but just as nefarious. This manifests itself into, “I am not in IT so I don’t know”. I didn’t ask you to be in IT I asked you to think. Just because an IT person asks you a question like “so how do you do an expense report” doesn’t mean they are looking for pseudo code to build you a new system. They just want to know from your perspective how to fill out an expense report. Here is another form of ignorance that really gets under my skin. We in the technology field are constantly expected to know how other areas work. I really encourage this for it provides for better systems. So if I am expected to know your world then you might want to pause and have some respect for mine. Yes I know some of us are weird and geeky but hey if I am showing you respect how about giving some back. Most of us learned this simple rule in kindergarten. Share the love people.

Respect

It comes down to this. When you are writing an email, remember the person on the other side is a person and not just blank two dimensional text characters. Treat an email as you would a stranger on the street. Be polite, sincere and more importantly respectful. If you are asking for help, be kind and respectful (notice a theme). If you are providing assistance be polite and respectful and give an answer that is written in the language of the recipient.

Say thank you and mean it.

Many a relationship has been lost on bad emails. Yes, we all have to breathe and remember people have bad days. We also have to get over ourselves and stop thinking email is actually real, effective communications. Treat it as business letters conveying a message or request. Yes there is a difference.

Sincerely and respectfully

Buchi.

The business reason for virtualization

2009-04-21T12:52:00.001-07:00

The Infrastructure Framework and why the business should care.

This post will focus on the business reason for virtualization. There are many technical reasons but these technical discussions only mire the bigger business needs. Many firms and organizations grew their Information Technology departments out of other departments and/or specific projects. Organizations that are funded by project typically have been forced to bind their Information Technology to the project office. These would become the seeds of the many silos we in the Information Technology industry have been forced to deal with. But what does an organization do to address this unrelenting reality. The first is to identify it exists and then adapt your future rollouts to support a different operational model.

The organization is entrusted to deliver the best programs and services they are capable of. Information Communication Technology can be seen as either the cost center or the opportunity enabler. This decision is left to the organizational leadership.

If the leadership chooses a “Cost Center” approach then there is little one can do to break free of the silos. For the initial apparent high costs of Information Technology are never a true reflection of the value they can bring. The best defense for this is asking your accounting group to stop using a spreadsheet for the cost of licensing is too high. Paper and pencil is cheaper. We would not ask this of a mature accounting group. Yet, every day we are asking the same of our technology groups. They are being asked to deliver more with less and no acknowledgement that Information Technology is a mature and valuable group.

If the leadership decides that Information Technology is in fact an opportunity enabler then the organization has to understand how that Information Technology group can bring the best value.

The leadership needs to follow the path of many successful organizations. The first step is to clearly articulate the organizational goals and problems from a holistic approach and NOT just from a departmental (silo) approach. This is the toughest step. The leadership must elevate the Information Technology group to the decision table. This elevation is not to defer the decision to the Information Technology group but rather the contrary. By bringing the Information Technology group to the table they become trusted advisors and can bring insight in your organizational solution definitions. It can be that easy.

But how does Information Technology bring value to the organization from within their domain. That is done by pragmatic deployment of solid networks that interconnect the departments heterogeneously. Next they deploy a technology platform that is solid, stable, robust and flexible. Once these underpinnings are in place the organization is now open to any and all open standards based applications. These applications can be boxed, custom built or a combination of both. The organization should be focused on solutions (why) and not the vendor (how).

What do you do with all your legacy issues? In the past this was the major stumbling block for breaking free. The issue of obsolete hardware, fractured networks and lack of focus that is evident in the most organizations’ Information Technology Strategy needs analysis is not unique. These challenges are being faced by many organizations. The good news is that there is a way out of the issues without having to abandon those functions that are working. The answer is in server virtualization and network consolidation.

The path for which you may want to consider is one of bringing all the networks to a solid and safe central place. By leveraging equipment today that has capital costs but very little monthly maintenance costs and NO monthly operational costs the organization can grow as needed without having to find new sources of funding. The second and most important piece is server consolidation. Many organizations have been forced by vendor licensing and performance models to deploy many servers to achieve small incremental advances. This strategy helped the vendors and only added to the complexity of support. The two major players of server virtualization of VMware and XenCitrix have solved this problem. The current conservative rate of server consolidation is 10 to 1. That means 100 servers can consolidate into 10 physical boxes.

The advantages to Server consolidation are many but I will list a few.

Reduced footprint
Ease of management
Exploit entire computing power (memory, CPU and disk)
Hardware is now a commodity
Can have as many logical servers as hardware will support. This is supportive, especially, of Microsoft’s one server per role model.
Backup and recovery is now simplified
Ongoing hardware costs are dramatically reduced
Ease of testing new versions of software
Single place for all storage
Takes less room
Grow as needed
Grow quickly
Grow simply
Allows for departmental independence without having to have physical independence
Share costing model

· Information Technology becomes a working service department. Can charge out time and resources to other groups to be included in funding envelopes.

· Considered “insourcing”. The Information Technology group becomes the “go to” group and trusted advisor to all because they are spending their time and efforts delivering value and not fighting fires.

There are other factors as well but the basic approach is to consolidate and then leverage. This solid network with a server consolidation platform gives any organization the platform and foundation to implement any solution. This is called the infrastructure framework.

The solution framework now becomes an exercise in connecting people with content and applications instead of the hardware and networking nightmare it has been known to be.

Privacy and Security -- A primer

2009-04-14T08:50:00.000-07:00

Privacy and Security

What an odd picture to describe privacy and security -- or is it?

The picture is of a person and that person is in protective garb. Can you indentify the real name of the person, the purpose and the location? No? This picture is in the public domain of the Internet and is freely accessible to all viewers. Yet, I will prove it has protected the identity of the person even if the digital image is not secured.

What is Privacy?

Privacy is the protection of personal Identity. It is that simple. The owner of ALL personal data is the actual person themselves. The rest of us are just custodians of that information. It is not just an Information Technology problem or solution. The information technology industry gets measured by a double standard in both privacy and security; however, all custodians have the same responsibilities and accountabilities. The advent of the free flowing Internet has increased awareness and complexity but not the underpinnings of what privacy and security really is.

Privacy IS about;

RESPECT for:

You
Your family
Your community

It is about:

Your rights as an individual
Your rights as a community
Your obligations as a custodian of personal information

There are 10 principals to Privacy Policy and all must be adhered to safeguard the individual. Most organizations would pass the acid test but great care must be done to ensure all elements are being addressed.

The 10 Principals are;

1. Accountability -- An organization is responsible for personal information under its control and shall designate an individual or individuals who are accountable for the organization's compliance with the following principles.

2. Defined Purposes -- The purposes for which personal information is collected shall be identified by the organization at or before the time the information is collected.

3. Consent -- The knowledge and consent of the individual are required for the collection, use, or disclosure of personal information, except where inappropriate.

4. Limiting Collection -- The collection of personal information shall be limited to that which is necessary for the purposes identified by the organization. Information shall be collected by fair and lawful means.

5. Limiting Use, Disclosure, Retention -- Personal information shall not be used or disclosed for purposes other than those for which it was collected, except with the consent of the individual or as required by law. Personal information shall be retained only as long as necessary for the fulfillment of those purposes.

6. Accuracy -- Personal information shall be as accurate, complete, and up-to-date as is necessary for the purposes for which it is to be used.

7. Safeguards -- Personal information shall be protected by security safeguards appropriate to the sensitivity of the information.

8. Openness -- An organization shall make readily available to individuals specific information about its policies and practices relating to the management of personal information.

9. Individual Access -- Upon request, an individual shall be informed of the existence, use, and disclosure of his or her personal information and shall be given access to that information. An individual shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.

10.Challenging Compliance -- An individual shall be able to address a challenge concerning compliance with the above principles to the designated individual or individuals accountable for the organization's compliance.

What is Security?

Security is the actual protection of the personal information itself. Modern technologies today have more than surpassed the security tests. From Networks, encryptions, and security architecture the ability to secure is there and people should take comfort in this.

So why are we seeing so many security violations. Well in fact we are not seeing security violations we are see privacy violations. When we hear of credit card information being obtained from recycled computers we are in fact witnessing a violation of principal number 7 which is Safeguards. The custodians of the personal information did not take safeguards to ensure continued security.

There is, today, a technology to solve any and all security issue. Yes the hackers and crackers (there is a difference) can break the codes and that is why security is fluid and ever evolving. Security is a never ending challenge and everyone must be diligent. When it comes to protecting identity all of us should be alert and conscientious. When I speak of Security I always refer to two realisms. The first is, “locks keep honest people out”. This refers to preventing, truly, the accidental breach. The second truism is “people do not break into Fort Knox to steal corn flakes”. This last one refers to the level of security you have should be equal to and/or greater to what you are protecting. Privacy is the top of the food chain on this one.

In conclusion

Privacy protects identity and security protects the private information. They must work hand to hand to truly be effective. Referring back to the picture above, yes I am the person in the picture. But what is my name for it is not Buchi. The armour I wear protects my person against my assailant’s harm. Where was the photo taken and why was it taken is the mystery?

Privacy and Security should not be complex, for if it is, then the human element will likely breach it by writing down the password or leaving the keys to the camp under the carpet.

JAAT Logo

2009-04-08T08:49:00.001-07:00

New company logo

Just posted it to brag.

From Data to Wisdom

2009-04-07T13:06:00.000-07:00

The evolution of data

The following graphic is used to demonstrate the evolution of data at a holistic level.

In my storied and eventful career I have been both the savior and the victim of Business Intelligence. The battle has raged for years and the real victims are the customers who are trying to figure it out. Over time and after many scotch on the rocks I started to piece the pieces together.

To truly explain, I have to go back to the beginning.

Data Level

Is the simplest to explain, it is the raw 1's and 0's or the smallest information store. This could be someone's first name, location, city, postal code. An individual information component. For those spread sheet users, picture this as a single cell.

Management Level

You may know this layer as Content Management, Information Management or Document Management. They all mean the same at this data maturity level. When you take the raw data and start to draw relationships then it becomes information. For example: the city name is related to the city description file. The invoice detail is related to the invoice header by the same common invoice number. The content is related to a press release, the documents are related to a case file. Once you establish the relationships then information emerges.

Knowledge Level

You may know this layer as Knowledge Management. I was originally stumped on this term until I dug deeper. What I found was this. Once you take your information and start to see patterns emerging then you have knowledge. Patterns become key. When you can take different sources of information and established predictable patterns then the user has knowledge at their finger tips. Knowledge is power. You start to really work the results when solid proven patterns emerge predictably. When unpredictable patterns emerge you have data mining and that is even cooler information, but I digress.

Wisdom Level

This is the final layer and it is based on applying principals against the patterns. Like in life, this becomes the challenge. There a many people in life with the all the knowledge but do not practice a principled life and by definition are not very wise. Like most things in the Information Technology arena we are standing on the shoulders of giants. It takes time and experience to apply principals to knowledge.

In Conclusion

Data becomes information after relationships can be built and maintained. This information comes in the form of document management, content management and information management. Once this has been established, patterns emerge. Once this is done successfully, Knowledge Management is the outcome. Lots of work is being done in this regard.

The outer level, bring together all this information in clear patterns and applies principals. These principals are in effect wisdom. This is the newest area of work in data evolution. An example of this principled approach to data is this example. “A car has a flat tire and it will not start”. Data, information and knowledge tell us to repair the flat tire, however wisdom tells us to get the car started first. Without the car starting the tire conditions have no bearing on movement. I find both in society and technology we spend too much energy on the flat tire.

The more connected and the deeper our understanding the easier it is for us to reach the wisdom level.

Emergency Management

2009-03-29T07:26:00.000-07:00

Information Technology and Emergency Management
I was recently asked to give some insight and a presentation into how Information and Communications Technology (ICT) could be leveraged for Emergency Management. So for this post I will share what I presented to the Assembly of First Nations national broad band task force.

The challenge for ICT is to balance and broker the person with content and applications.
Spring is here and with it comes its rain and hope for a better day. However, reality dictates that for most of us this is a time of year of watching water levels and checking thawing rates to determine what type of ride the journey to summer will be.

Information technology and technology in general can play a vital role in all sides of the emergency. The lead up to an emergency is the preparedness side and sadly, in the event of an emergency the reactionary side of the solution is engaged. The Management side of the proposal is directing and engaging all the stakeholders throughout the entire process.

The time tested adage of “plan for worst and hope for the best” is a good strategy in this context.

Preparedness
This is where the greatest potential benefit can be had for Information technology. It is the boring day to day upkeep of the plan and all its components. This benefit can be realized in good information management, communications portals and best practices repositories. No one group has all the answers for all the problems. Technology can be leveraged to share the wealth of these previous emergencies to aid in the ones yet to be realized. The traditional model of every jurisdiction or geographical area taking care of their area in isolation has proven over and over again to be ineffective and at times deadly.

The tools and information are available today to assist those communities with little or no expertise to follow a proven methodology to get their respective areas prepared. This type of work can be as simple as automated call out trees, support contacts, lists and locations of emergency supplies, best practices documentations and to the more complex information toolkits. Education and awareness is crucial not just for the constituents of the community but also those who are entrusted to action the emergency plan when needed.

There is a large misconception that minor and major levels of government are prepared for emergencies. In many cases this is true, however, like all of us they are only as good as the plan and the plan needs to be flexible, current and adaptable. So for those recurring emergencies like, floods, fire and black outs the current plans are normally fine. This is because they have had time to test and trial them. However, what about emergencies they have not experienced before. The classic example of this was SARS in 2003.

If you take this discussion to smaller communities you are relying on overworked individuals who may not know how to build a proper Emergency Plan let alone get the community prepared.

The preparedness side of the equation is typically heavy towards content management and plan development. The major tool that can be leveraged for this role is content management.

Emergency Response
This is where failing to plan causes failure. Information Technology needs to be tested and like all things in Information Technology it needs to be able play nicely with others. Take for example a large scale emergency that involves, fire, ambulance and policing. They all have mobile communications and what do you do if they can’t speak to each other? Truth is, this is common and control centers get jammed, confusion reigns and ineffective execution follows. You do not have to look far to see what can transpire. A good plan has proven its elements to be functioning and it must be tested.

The response side of the equation is strong to application usage, status update, issue tracking and execution of existing plans. The content management system will used as reference for current action plans. The major application being used in the response side is typically issues management.

Emergency management
This is the element that allows the leaders and coordinators of an emergency plan to keep track of events, actions and conditions in as close to real-time as possible. This allows for effective communications and coordination of resources, tools and people to deal with the emergency and the information flow to and from all parties. Simple issues tracking systems can and should play an integral part of an effective Emergency Management solution. A fully utilized portal is an excellent tool to manage emergencies especially if the scope is multi-jurisdiction and multi-disciplined.

In conclusion, this is just a small insight into the role of Information Technology and how it can help build, maintain, test and deliver the emergency response plan. There is only one other factor that is more important than technology in the case of an emergency and that is people leadership.

change management matrix

2009-03-27T13:55:00.000-07:00

A stages of change matrix with their symptoms and options

Change Management

2009-03-24T14:43:00.001-07:00

The people side of Change

The people side of change. There is the formal change management process for Information Technology and this discussion is not it. I will attempt to give my insight into change. Before you can speak of the formal Information Technology elements of change management you need to address the real people side of change.

As Technology professionals we are constantly in a state of flux and change or at the least the good ones are. If you are one of the moss backs, this post is NOT for you. I would be considered a grey back. I have aged and have learned from my scars. I am still young enough to pursue and wise enough to know what will hurt and what will not. I am driven by doing the right thing and not always being right. Yes there is a difference.

Whether we are creating the change, are agents of the change or are victims of the change it is important to understand the human element of this change. Regardless of what part you play you are going to witness some uncomfortable things. The more you can identify the signs the better you will be able to handle the changes and the people they affect.

As I get older and have more experiences to draw from I find most organizations are faced with conflicting messages when it comes to the most senior of their staff. In times of crisis this becomes more prevalent. This is what I mean; the company needs to get efficient and is faced with budget cuts. Do you go and get the budget by letting go of junior staff or do you go after the most senior? This is a very difficult question to answer. Firstly, loyalty states you go with the veterans for they have earned the right. However, there may be evidence that the junior staff is more eager to learn, to produce and to accepting the new challenges.

Here is what I believe, “your message sent should be the message you need heard”. If you need strong leadership and a solid base to go forward, then your senior staff will likely get you there. However, if you need to change direction dramatically and your senior staff does not have the energy or desire to make that level of commitment. You may want to consider cutting from the top. I spend a great deal of time working directly with the team to find out their capacity for change, their willingness to adapt and their basic sense of pride. I am always attracted to crafts people. I will also share with you my experiences as a basketball coach. I always fielded the best players. By best I mean the hardest working and the ones who knew they were part of the team. I have little patience for prima donnas and the entitlement crowd. I have seen the scorn of my colleagues, superiors and team mates for not following seniority convention but I have found over time the team worked better when they knew there was a reward for effort. Like I said, I have a lot of scars on this one.

Before you show anyone the door, you need to find out if they are in fact in a rut and if so, what can you do to help. Some people want the change for it is the new challenge and others just want to get through the day.

When you are looking at the senior crowd, tread lightly. This advice is especially true if you are the new person on the field of play. Everyone is in their current position for a reason, and you need to find out what the reason was. I have found “was” is more important than “is” in this context. I am not a political person but I truly understand the game of politics. You don’t want to give a hard time to a senior employee if that person is well connected to the upper food chain. This doesn’t mean you are not going to get rid of them, or make them accountable it just means you need to do your research and find out the whole picture before you proceed. Refer back to the OODA loop for this process. It is most effective here. An example of this is a person who has been promoted to incompetence. This type of person was very effective in lower roles and has been promoted for jobs well done in the past. The challenge now is that they have reached their capacity and in fact may be in over their heads. You as the new person will likely have the clearest picture for you have no background to draw from. Good for you, bad for them. These individuals can be identified by their direct dealings with your superiors and other managers above their pay scale. In these cases you need to get that person on board to the new vision and approaches as quickly as possible. Failure to do so, will only make your job more difficult and send a confusing message to others. Be fir, but fair. Remember you have no history with this person, so do not let history play into your dealings.

The other line I always here is “everyone is doing the best they can”. After the initial cringe I feel, I start to process it. I read it this way, the state we are in was not done in malice but it was done in ignorance. If you subscribe to this theory then, you need to educate as you communicate. By showing people what you need done and how it can be done then you will get people seeing differently. Success will breed success.

So after this little parental rant (sorry about that) what are the signs and/or stages? Anyone who has taken psychology will understand the stages of change. They are same stages as grief. You see, change will force someone to give up a known habit or condition. This condition can be so comforting that they feel a certain loss/fear. Most negative responses from change come from a point of fear. The fear may be from not knowing or not believing they are capable of the change. You, as the leader, will need to guide them through that change. I use the line “be afraid, do it anyway”.

These stages, as seen in the above graphic, do not always follow a direct path. Sometimes a person may only express one or two of them or sometimes all 5 of them. Just because the person has moved past a certain stage does not mean they will not go and visit the stage again.

Denial
The symptoms of Denial are road blocks, rumor mills and the deep negative aspects. You will hear things like “it is never going to work”, “we have tried this before” and my favourite “it if isn’t broken, do not fix it”. You need to address these professionally and firmly. Your response messages become, “It is going to work for we have learned from previous attempts”, “we have a plan”, “just because it works doesn't make it right”, and, “we need this to be successful”. Fear is gripping this person and you need to get to the source of the fear to alleviate it.

Some of your options for dealing with the Denial state are; provide a clear vision, a clear mission, frequent communications, be transparent and search out positive change agents in the group to be the change champions.

Anger
Anger, the one everyone wants to avoid. I, however, do not mind anger. Reason being, you can deal with anger you can’t always deal with the passive aggressive. The symptoms of anger beyond the obvious screaming and shouting are actual grievances and short terse communications. First and foremost do not run from anger but also do not fuel the fire. Here are some options to deal with anger, have offline meetings to get to the root of their concerns. Again anger is based on fear, largely the unknown and a perception of loss of control. By having private offline meetings you create an open dialogue and opportunity to engage. Become an inclusive listener. You may have to change some team dynamics to encourage positive behaviours. In some cases you may have to actually discipline the staff member to reinforce the organization’s position. Make sure you have support from the organization first. You need to fight the good fights and let the smaller ones die.

Bargaining
This one can be very dangerous for the team and the project. The symptoms are scope creep and they are typically the hidden changes to appease staff. Other symptoms become mixed messages from the group. One day they are all good to go and then whammo, the sky is falling. One of my favourite elements of this stage is the parading ot the sacred cows. These are the statements, “customers will never agree to this”, “have you consulted with ????...... They did not like this in the past”. This is also the stage when all forward movement seems to be lost and at times you feel you are going backwards.

There is hope, truly. The best approach is to stay calm and to stay on point and true to your design principals. Do not bend to the will of scope changes. Look at the changes and the requests and see if they are going to move the project forward. If so, give it consideration. If the changes only delay then put the changes in later phases and document it so you can say it has been dealt with. Communicate the goals of the organization and the project repeatedly even if it is becoming annoying. Lastly, make the tough decisions. In this stage strong leadership will win over emotion.

Depression
This is one of the most difficult to watch but sometimes you have to let the train wreck happen. The symptoms of this stage are low morale and slow progress along with an overall lack of enthusiasm. This stage is usually most prevalent in the big lift areas. So much work is being done that those in the trenches lose focus and direction. The best approach here is to praise the success regardless of how small they are. Even if you just change the language of the communications. For example instead of saying what did you work on today, rephrase the question to what have we accomplished today. Have a regular success communication. Post the completed list instead of the remaining list. Share the wealth of praise amongst those doing the work, show how far you have progressed. Your role here is to motivate and communicate and lastly be patient. If they have not stopped completely, give them time to heal the wounds to fight another day.

Acceptance
The stage you have been waiting for. You know you have reached this stage when elements you have been working on are being exploited and promoted from all stakeholders. The other big sign is when new ideas are coming from the group that was affected by the change.

The best approach here is to reward the good behaviour, often and on many fronts. Acknowledging the success will breed a successful culture.

In conclusion

Change is inevitable and it is a real part of Information Technology and our current society. If you want to survive you will need to adapt and help those who cannot and forget about the ones who will not.

Service Desk

2009-03-16T10:04:00.001-07:00

Service Desk
This post will focus on what I call the Service Desk. For those of you in the know you will realize it is a very loose interpretation of the ITIL framework. What I am describing is actually a help desk. I am using the Service Desk term for most help desks today have become helpless desks due to bad management and execution. This is my attempt to right the wrong. I make no apologies for using the term Service Desk.

The goal of a Service Desk is to offer good service and not to be a burdensome process. The graphic above is the high level view of the Service Desk. Some other goals of the service desk are to record the resolution and to offer self-service to those users who wish to do so. The Service Desk should be accessible by any channel. The most common channels are email, web site and call center. By having multiple channels the user is able to make contact even if their computer is completely inoperative.

As you have probably guessed from previous posts I am a process person. As such when a process is intuitive and effective it will be used. When a process is broken or ill conceived it will not be adhered to. I say this to remind the readers if your Service Desk is not being used, the normal culprit is an ineffective Service Desk (or helpless desk as mentioned earlier). The entire management team must support the process and adhere to the process in order for it to work. The Service Desk has several levels and each level has a contact path and a responsibility path. I will endeavor to explain as I go along.

Please refer to the graphic as I explain the roles and their associated goals. As mentioned before the Service Desk should have a website for the users and the managers to monitor their requests. Users should be able to email requests. I use the email address of “help@companyname.com” as the moniker for email access to our Service Desk. I also have a phone number for users to call to get their requests in. It is imperative that the users shouldn’t have an intimate knowledge of how your service desk works. They just need to know how to access it and watch for progress. If you offer too many options, then the user community gets confused and starts circumventing the process.

As a downstream process it is imperative the organization has a Service Desk that is accessible to all parties and is the single source for all requests, changes and issues. Failures to do so can cause many undo delays and multiple touches on the requests. This is another sign of an overburdened process.

User
This is the actual person with the problem, issue or request. It must be impressed on them to give as much detail as possible and how and when they can be reached. Some systems will allow the user to dictate priority and I am not a big fan of this for it gets over used. I tend to ask questions that state importance. For example is your system down? Are you able to perform your work by other means?

The user can call the Service Desk or email the request or place an entry at the website. Regardless of how the entry started it will be visible to all concerned parties via the Website. This is critical. For the purposes of the rest of this post this request or entry will now be called the work order.

Role – Enter the work order and be as descriptive as possible
Responsibility – To ensure all work instructions have been followed and that first level operating procedures have been followed.

Management
The immediate supervisor of the user should now have access to the work order. If required they should be able to make additions and/or comments to the work order. If the work order is a change request, my process forces the immediate supervisor to approve the work order for review. The work order will be routed to the business analyst and from there a formal approval process will commence. For the purposes of this post I will not delve any deeper into the approval process other than to say, you should have one for change type work orders.

Some systems will auto route work orders based on what is in the work order. If you have such a system you must encourage your user community to be as descriptive as possible. The advantage of such system is that work orders can routed more effectively and therefore time to resolution is reduced.

Role – update the work order and provide insight and guidance to proceed.
Responsibility – To supervise the work order process and to ensure that it is a valid work order to be worked on. If it is a training issue they must instruct the user correctly and update the work order accordingly.

Tier 0
This is the Single Point of Contact (SPOC) for your Service Desk. This person does NOT have to be a technical person. It is helpful but not a requirement. Their goal is to ask pertinent questions and to gather more information for the other players in the process. Over time, the Service Desk will become a resource center and this Tier 0 individual will be able to solve most simple problems. Issues like password resets and hardware resets can be handled by this group. These issues are always following established protocols and guidelines as set out by the Technical Department.

Many times Tier O can be located at a remote office or business unit. For some organizations this Tier 0 is an operational person and an operational responsibility. You will need to assess the value of this approach. It works in a lot of organizations that share an IT pool. This gives the IT pool a pre-filtering before they are engaged.

Role – To look at work order and gather information to pass it on to other groups. If more information is needed then they make contact with the user to gather this information. They can also determine the severity of the issue and any possible work arounds.
Responsibility – First formal contact with user. They must have an excellent customer service approach to working with the end users. They are encouraged to apply known solutions to problems. They are the only ones who can direct the work order to the specific support groups. They must also contact the end user via a determined channel that the work order is being addressed. I am a big proponent of always informing the user as to status. This role will also update the work order with all its findings and actions performed to date.

Tier 1
This is the first full time technical contact to the Information Technology Department. It is equipped with junior level support people. It is usually the starting point in most technical department. They will have more tools and resources then the Tier 0 group. This is effectively the Triage group. They ascertain what type of issue is this. Is it hardware, software, network, security etc. Once this is determined they will perform first level support on the work order. They will update the work order and ask the user to perform known solutions to the issue. They will also try to gather any information from any failed attempt to resolve. Sometimes a lot is learned from failed attempts. Due to the direct customer interaction, you must impress in this group good customer service protocols.

Role – To look at work order and gather information to pass it on to the Tier 2 group only when first level solutions have been exhausted. If more information is needed then they make contact with the user to gather more information. They can also confirm the severity of the issue. This group is a technical group and as such must be able to quickly inform the deeper support tiers of all the troubleshooting to date.
Responsibility – First formal technology contact with user. They should have a customer service approach to working with the end users and Tier 0. This role must dig deeper and use the OODA loop throughout this process. This role will also update the work order with all its findings and actions performed to date.

Tier 2
This group is the subject matter experts of their respective areas. This is to say they are experts in software applications, hardware, networking, security and any other technical areas your department is responsible for. For smaller shops an individual may wear many hats but regardless they are considered the expert for a particular area. They may also be the backup person for another specialist in another area.

Tier 2 only speaks to Tier 1 and Tier 3. A proper rollout will not have them speaking to end users. This on the surface may seem odd but what I have discovered is that you pay these people to get the work done and not to be confused by the end user. Also, many of these specialists do not play well with others and therefore tend to annoy end users. There are always cases when they have to speak to end users but I try to discourage that. Trust me; things work better when they are dealing with likeminded individuals.

This Tier like other tiers updates the work order with what has been done. If they cannot solve the problem they can pass it on to another specialist in this group if they believe the problem is theirs or they can pass it to the actual vendor that is responsible for the work order issue. This latter group could be a software company or hardware vendor or network management group. It is typical to send the work order details to the supporting vendor to reduce their efforts and to stream line the resolution process for all parties.

Role – The subject matter experts of a specific area or areas. To fix the problem permanently and to update the solutions database with the resolution. To escalate to vendors if needed
Responsibility – Primary contact is with Tier 1, 2 and 3 and not the end user. They must have the skills to fix the problem and to research resolutions using all the resources available. They are the only ones who can direct the work order to Tier 3. This role will also update the work order with all its findings and actions performed to date.

Tier 3
This is the actual vendor and is typically outside the organization. It is in everyone’s best interest if the end user does not contact the vendor. This leads to dysfunctional behavior, increased support costs and lack of knowledge on how the issue was resolved for future issues.

Most vendors will support this model for it allows them to treat your tier 2 group as their tier 0 group and thereby reduces their time to resolution.

Most vendors will not have the ability to update your work order directly and therefore your tier 2 will have to update the work order with the details for future reference.

Role – To address the deeper issues with the work order request. To work with your tier 2 to resolve any issues.
Responsibility – Typically the support of last resort. If your organization cannot fix the issue then the vendor must resolve. They need to be respectful to the fact the problem has already been worked on and that there is no need to start from ground zero even if they want to. Your organization has to pass on all the relevant information to the vendor.

In conclusion
At first blush it may look like this is just another process to annoy the end users. In fact in can be if you do not have the discipline to maintain the protocol. However, if your organization has the discipline and your Technology Department is successful in solving the issues then you will find compliance high and the results positives. I have been in many shops where everyone called whom they believed could solve the problem. The problem with this approach is that it assumes you have called the correct person. If not you may have called a mechanic to fix an electrical problem.

The Service Desk also protects your group. By being transparent you will not get into the argument that your department is not fixing issues. You will need to be firm and keep stating you can only fix problems you know about. This statement means you keep telling your users to fill out a work order. We, in my department, log all things into the work order system, even if it was just a 2 minute fix. By doing so, I have the metrics of what my team is doing and the end user has a transaction to confirm a service was provided. The work order system serves all parties well when all parties decide to use it honestly, completely and effectively.

The project Manager's Mantra

2009-03-09T09:37:00.001-07:00

Project Management -- High Level

There will be other blogs in which I explore specific Project Management methodologies. This post is to give an overview of the project manager’s mantra. There is a difference between someone who manages projects and a project manager and it is NOT the letters after their name. This is also not about the blurring of lines between business analysts, technical folks and certified Project Managers. It is about the real responsibilities of the Project Manager. It is also not about MS Project either or any other tool for that matter.

The three key elements to successful project management are the proactive management and control of Time, Budget and Scope.

Time

It may appear to be the simplest to manage for many. However, any experienced project manager will tell you this is where diplomacy and tact reign supreme. Most people will you give either too short a time line or a timeline that is too cautious. The project manager has to measure duration and placement amongst other tasks to enable the person to qualify their time lines. The balancing of time verses effort is critical to overall success. The project manager must ask each person to confirm that the time line can be met. This gives the person giving the time accountability and buy in at the same time.

When I hear timelines of it should take 2 maybe 3 days, I start to get agitated. This is due to the fact that now people are guessing and that causes the overall project to come under risk due to someone not making a time line. I try to focus the time effort but probing deeper in the effort of how long it will actually take. This becomes easier once you start to know your project team and what they are capable of. You want to tame down the overtime junky and ignite the slow starter.

I also put in clear milestones throughout the project. I use these milestones as checkpoints to allow the slower ones to catch up and the more aggressive ones time to breathe. It also allows the whole team to refocus on the next stages. It is used to define critical paths and inter-dependencies.

Some projects are time sensitive and the end date cannot move. Y2K is an example of this or the move out of a building is another example. These projects I tend to start with the end point in mind and work backwards. Buffer where needed and ensure a sense of urgency is there and of reality based time lines.

Another factor of time that needs to be managed is when your internal resources are also expected to work on other projects or have other work related commitments. This can led to internal struggles and unforeseen delays. The good project manager is working with other project managers or projects to balance the time and effort commitments.

Budget

The one piece that is usually not very flexible. It is great when the budget can be fluid. However, you should not count on getting more money when building your plan.

Capture all the costs for both internal and external resources. Some firms follow the policy of internal resources are factored at no cost. I am not a believer in this model. I also factor in what the opportunity cost is if we lose the internal resources and therefore have to go outside to complete. When your internal resources are working on your project it takes away from the time they could spend on other projects.

Keep a daily, weekly and monthly tab on the costs for each task and the overall costs. Most tools today manage this and as the project manager you need to escalate to higher levels when budget envelopes become strained. Too many projects fail when in the early stages of the project the budget is not kept in check. This can be witnessed if you ever had a home built for you. The foundation guys will allow changes and the money is there and they get paid. By the time the finishing carpenters arrive, the budget is tight and the home owner is left with below expectation results for the budget is not flexible enough at the final stages.

By keeping a tight control of time slippage and scope creep the budget envelope can be manage very effectively. The good project manager knows when to call in the hounds or when to loosen the purse strings.

Scope

Scope creep is the killer of most Information Technology projects. Most IT projects fail for they are unable to maintain budgeted scope and end user expectations. End user expectation is not just at the user requirements stage but throughout the whole project. I am amazed at how IT projects just take for granted the end user knows all the options before them. Once the user starts to get exposed to the final design and starts to implement actual workflow then scope typically is in for a rough ride.

I have spent a large part of my career being parachuted in on bad projects to get them back on line. Two things always seem to surface. The first is taxonomy or the language of the project. I could speak forever on this. What one group uses for a term can surprisingly have a different meaning for another group on the same project. For example what users call a database and what a database administrator call a database typically do not match. The second element I run across is scope creep. The endless features that just have to be there or we can’t go live. Most of these are built as pieces of the project are exposed and people start to kick the tires. This is where leadership verses management comes to play.

First and foremost before you had them sign off on initial scope, make sure the scope document is written in their language and that you have walked them through it from all levels of the team. I have had to rescue major projects because executives allowed line staff to sign off on the scope documents. Their misplaced trust in that adage “they use it therefore they must know” is extremely dangerous. If that was the case why are they not running the organization? Leadership and direction come from above and not from the trenches. The trenches are there to give an acid test to how much impact the project is going to have. You need the input from the entire group but sign off must come from the executive sponsor and that person must understand what they are signing. I love it when I review the project charter and I see technical jargon or diagrams. After I witness this I know I am in for a rough ride.

When death by scope creep seems inevitable, make a list of all the functional requirement of the original scope document and the new list of desired requirements. Demonstrate which functions being asked for are in conflict of the original design points. This usually clears up most issues. Once people are reset for what the goals of the project were it is usually easier to get the train back on the track. The other functions can be placed into latter phases of the project after you have implemented the initial stated phases.

The other thing you need to remind the team about is that scope creep costs both time and money (budget). They need to sign off on change requests. This change process is not just in place for just external resources but also for internal resources as well. You need to get people to agree to the changes and to be held accountable for them. Ensure each change is measured against the original goals and objectives. If there is conflict the project manager has to highlight these conflicts to the senior team. Most projects fail not on one change request but the steady flow of minor changes. Each change must be bringing you closer to your original goals and not away from it.

Lastly, the project manager must not get emotionally involved with the scope, and must report back objectively. This is a challenge for those project managers who also wear the hat of the business analyst.

Like most of the triangles I have mentioned it is about balance of the three sides. When it comes to project management there are so many external forces putting pressure on time, budget and scope that you will have to be diligent, tactful and most importantly capable of making adjustments that enhance and not detract from the project’s stated goals.

Portal as a broker

2009-03-02T14:05:00.001-08:00

The portal

To most people a portal is a website or, to the more daring, a website on steroids. This view is short-sighted and lacks an overall holistic vision, because a website is but one element of a portal. Even if its interface is a website, the portal itself is not. The portal is the environment created by the natural evolution of distributed information, dissemination, data aggregation and data management.

Distributed information is information that often resides in branch offices or smaller applications. This vast pool of information is being collected and managed away from a central source, yet it is vital to the branch operation and is even more critical for the whole organization. This is similar to the analogy of a series of blind men trying to describe an elephant from each of their static locations. Each description is correct from their perspective, but a complete picture is difficult to articulate.

Aggregation is the ability to store the data in a central location for easy retrieval. By categorizing the data into smaller, more meaningful portions the data starts to take shape as information. In the end the user is responsible for sifting the information from the data. This aggregation was the mainstay of the knowledge management and business intelligence revolution; but there was an anomaly: If a user had access to all the data, why were they still unable to make better decisions? The answer lies in the usefulness and timeliness of the information. Aggregation was key, but not completely sufficient to answer the question.

Management of data is that balancing act that occurs when you can have distributed data, with the aggregation of information. How do you best manage the data to make aggregation possible, and distribution easy? In future posts, I will discuss the path data takes from its inception to wisdom.

If we look at the Internet for similar correlation to the developmental stages of the concepts of portals, we will find a first wave of websites where a wealth of data on specific topics was located. The Internet boasts of storing ninety percent of mankind’s knowledge. Children today have access to the human genome and the entire works of the greatest authors of their time and any other. However, finding the data is troublesome and deciphering its value becomes a greater challenge still. This may explain why our children have not surpassed their parents in terms of intelligence. Proving access to the data does not equate to usefulness. The portal allows information to be useful, relevant and achievable.

The first wave of portals started to take the aggregation approach. The simple approach was to build portals based on subject matter. So, we had project manager portals, employee portals, travel portals, and more. Each portal became an aggregation point of data relevant to the portal’s theme. In fact, the data was organized and categorized based on further defining the framed data into smaller portal-relevant data sets.

Yet again, an anomaly exists for many people trying to understand portals: Why are people not flocking to these portal sites? The perception of the anomaly is actually the problem; understanding the interaction between the people and the site is the key. The portal is not a site, so by reason of purpose the portal needs to be more than just a collection of similar data objects. People are not trained monkeys, contrary to popular “dot com” thinking, and do not participate in a site just for its data objects for any longer than the data provides value. There must be more than organized data to provide a portal to information. This can be witnessed by the sudden surge of social sites. The initial value is there along with the long term reason to keep interacting.

So, what is the portal if it is not a site? The answer is that it is a “broker.”

Broker…

The portal is the component broker for the layers of communications (human and electronic), technology, and applications and, more importantly, the business drivers of the organization. The graphic is the simple representation of the portal links the person to the content and the application, along with applications being linked to content. This brokerage is the vehicle for that basic human need to filter data and to query its content. The machines categorize the information into a meaningful perspective so each supplier of data, or requestor of data, can quickly and effectively process the data into “information packages” that have relevance to them. This packaging is then used to assist human decision-making or application-decision execution irrespective of physical or organizational location.

Human decision-making is that fine art of actually acting on information. When we use information to make a decision it becomes knowledge. Knowledge becomes the outcome of the action. How we shape the data, to decipher the information, to make the decision, is the difficult part. Without the decision we have “analysis paralysis”. The path is from raw data to information to knowledge to finally wisdom.

Humans have their burden eased by the portal in this “decision-tree” through personalization and customization. Personalization is created by the environment, based on who the user is, and what role they are currently playing. When the system knows who you are it is able to tailor the experience. Customization is when the user decides to alter their user experience to best fit their needs. This can be in form of skins, layout and addition or removal of portal parts.

Application-decision execution occurs when programs look to be triggered based on data they receive. Today this is very popular in stock markets, where programs wait to see if a certain stock rises for falls; and based on this action, the program will automatically sell or buy stocks. Likewise, system management software will look at system log information and will be triggered to perform actions based on thresholds or alarm values.

These application-decision algorithms can be beneficial or detrimental depending on the human value placed on their actions. An example was the negative effect of mass selling after the disastrous September 11th Twin Towers act of terrorism. Automatic programs went amok, selling based on other auto-sellers taking action. The result was a spiralling of negative activity. It took human intervention to stop the downward spiral of stock prices by these machine-generated sell options. This clearly identifies the risk we run by deferring responsibility and accountability to program logic. Just because the tools make a job easier does not mean they don’t require a craftsman to complete a job well. The hammer is used for nailing, but still requires the vision and purpose of the craftsman to do the job correctly. A portal can at least package information in a way that makes these sorts of application-decisions more effective and efficient.

The role of the broker is essentially to connect the service requestor and the information supplier. So the portal, when acting as the broker, has no direct form. Basically, you can’t hug a portal like you can a website, because it is not a single, central physical thing. It is the void of the data interchange. It is both full of knowledge and lacking in data; everything and nothing at the same instance.

No end-state…

First and foremost, a portal has no end-state and is in constant change. Information becomes old or irrelevant, user demands are constantly changing, access to more data is inevitable, better tools to process the data become available, and so on. This change is both system-controlled and user-experience controlled, because the system allows for the categorization and the user-experience allows for content personalization. The user drives the demand, and the system drives the supply. This constant churn makes the portal a living entity with an uncertain beginning and no predefined end.

For many, the confusion about a portal is purely an issue of perception that is largely based on the absence of an end-state. A portal is a component manifest of apparently disparate components until you take a higher view of its form, function and purpose.

The Roles

The dichotomy triangle shown above has three major roles and they are People, content and applications (Apps).

People

I am amazed at how many portals I visit that are built to impress the masses. The user at the keyboard is the only person for that session and that should not be forgotten. Your design and the user experience should keep this in mind. It is not a flashy banner for the world to see but rather an experience geared for one person to whom you want to allow to work, to learn and to play at their speed and their direction. From the portal’s perspective this is broken down into three flavours of personal identity. The personal experiences are the anonymous, the synonymous and the known.

The anonymous experience is for those users whom do not want to be known and will not leave a presence behind. This is the public internet site. No user log on is required and all information and applications are for public use. Example of this is google, Wikipedia, imdb etc.

The synonymous user is that user that wants to be identified but not by their real credentials. This is for those sites where the user wants a unique setup or experience but has a desire not to be known specifically. This blog site is an example of this type of user setup. My real name is NOT buchi, however, my shared profile information is real, just my real identity is masked. Other examples of this type of login are You Tube and Gantthead for project managers.

The known user is where a true identity is required. This could be a corporate portal or your banking portal or any other portal that your true credentials are required. Some portals will require even multiple methods of identity to confirm your electronic user credentials.

Content

This is where the vast majority of portals focus their efforts. This is where raw information, documents, reference material and other mostly static information resides. These could be documents, best practices, research material, snippets of code, blogs, news, movie clips, multimedia files etc. The content is typically engaged by clicking on a hyperlink and the resultant content is forwarded to the client software which is typically a web browser.

Luckily, today there are tools to manage this content so the maintenance and upkeep can be done with minimal effort. Tools like Sharepoint, Joomla, Mambo, Bricolage and Drupal and countless others fill this void.

Applications

This is where the user interacts with real applications in the form of databases and dynamic data. This could be a simple web application for shipping, tax returns, government permits etc. The difference is the user is engaged in what data or information is presented, updated or deleted. Some good examples of web application frameworks are mason, .NET , Java Virtual Machine and Tomcat.

Applications can also update content via Content Management Solutions (CMS) stated earlier or by graphs and reports created by user interaction. The loop becomes complete when all three are engaged seamlessly.

There are many tools out there that can be assembled to fit your organizational goals. The technical goal should be to broker the person, with the content and the applications by way of the portal to the organizational goals.

2009-02-23T10:36:00.000-08:00

The eBusiness Model

The three legs of the business relationship are shown in the above graphic. The three big roles are; the organization (business), the support (administration) and the stakeholder (customer). For hundreds of years these three roles have had a known and predictable inter-relationship.

If you wanted a product you engaged the organization either by store front or by phone. The traditional model has you engaging in a salesperson/client role. You discuss the product, features, benefits and costs. When the parties agree to proceed to the next step, that step is typically a sale. The salesperson will lead the customer to administrative support and make the initial introductions in some form. In a lot of cases, the sales cycle is over and then the support cycle begins. Now the customer will likely get exposed to the support functions of an organization. This is a tenuous situation. A good salesperson is trained in the craft of customer relations and has a positive (at least the successful ones) attitude. They are typically motivated by the commission of the sale and are eager to pass you on to the administrative group. This can problematic due to the fact the administrative layer is motivated by following the internal process and reducing their effort to complete the task. This can become the first strain on the customer relationship.

If you look at the triangle the cycle goes likes this; the customer (stakeholder) talks to the salesperson (business representative) that passes the sales info to support and the customer pays the support person to complete the transaction.

This model has worked for hundreds, if not thousands of years.

In the traditional model, a business had well trained sales groups and courteous support people. When all was in balance, the business flourished. If you had rude salespeople you tended to have reduced sales. If you had unprofessional support personnel you tended to have reduced repeat sales. You could make the first sale but would likely not be motivated to return for more.

Buying a car can be like this. The sales presentation is usually excellent and the buyer is convinced it is the right car. Then support steps in and potentially causes this large purchase deal to become strained by paperwork, cold calculated forms, delays, more forms and such. Then you need to get your car serviced and then the service department treats you like a herded heifer. Those car dealerships that focused on the complete sell and relationship model faired very well.

What changed?

The biggest change was the speed and transparency of the stakeholder to the business. The biggest catalyst was the Internet. Now the customer could research the product online. They became informed and when they went to speak to the salesperson the conversation was now on specifics and not just relationship. Moreover, the customer wanted to remove the salesperson from the transaction. They exchanged the salesperson to the Internet site. Some early web sites where disastrous in this regard. The biggest thing for any IT manager to know about the net is your site either has a presence (eBrochure, contact us, and company facts) or a purpose (online transactions). In either case, contrary to what you may have been told, the Internet is NOT a mass marketing tool but rather a personal information tool available to the masses. Customers may browse the net but it is typically in a purposeful way. They will click to learn or to be exposed to more. They are not expecting a rolling commercial for the masses but rather a multi-media experience based on their clickable requests. This is where the death by flash has to stop. The sheer quantity of sites I go to that are all flash and no substance drives me nuts. I will leave that rant for another post. Know your client and their needs. If this is a support site then have online manuals. If this is a retail store then your search engine should be based on how the customer knows your product and not your inventory control system. How many retail store sites have you been to that asked you for part numbers or catalog page number? You have to be kidding, how would a customer would know that?

Now the customer could engage the administrative layer directly with things like online payment, order inquiries, order taking, shipping etc. These offerings should be based on what the customer experience should be and not an extension of the support arm. Customer do not work for you, please remember that.

Some pitfalls and solutions

You’re a retail chain and your online site is negatively impacting the number of clients in the store. This is a good news for support people for you have lowered your cost of delivering the goods and you have likely reached a larger customer base. However, the in store experience is what gave you brand recognition and it cannot be under estimated. Then what if these stores are franchises, then what? One suggestion that Canadian Tire does is they compensate the retail store for every online purchase as if that customer would have been in the catchment area of their store. They do this by postal code. Other retail stores only offer some products online and encourage the in store experience. This can be problematic, for you are potentially giving up sales.

You are a service company that sells a complex service. The example I will use is transportation. The customer wants to order a pickup and goes online to get the pickup request. The customer fills in the form, the driver is dispatched and the product is picked up. The end customer (consignee) receives the product and the company sends the bill to the original customer (shipper). This is all good right? Wrong. The example was a good example of a service that was successful in that the customer had the service delivered as expected. However, there was no real business interaction. What if there were more products that could have been picked up or the customer paid a higher rate because they packaged it differently or that your firm also offers customs brokerage for border crossing or freight forwarding for international freight. So how does the customer know what they do not know? What I force, yes force, my sales group to do is to engage the customer through the online experience. The salesperson is expected to set the customer up in the website and train the end user on how it works. Some big firms think this is so wrong. Why would you have a salesperson setup an online customer? My answer, are you nuts?, you want an IT person setting this up? We went into the IT field because we do not like people, so why would you risk your customer relationship to a support person. My method o gives sales a great reason to talk to the customer outside of the golf course. Good for the organization and bad for the salesrep.

Support wants to go completely online for bill payment. This sounds good when your customers are small firms with low Accounts Payable volumes. The same is not true if your customers belong to large firms with large Accounts Payable volumes. The issue with using email for invoices is very dangerous. What if the recipient is not there, how do you confirm the invoice is there and processed? You need to offer different types of online invoicing. You might want to consider an email notification that a bill is ready for their review and then have online payment. Larger firms will want to engage Electronic Data Interchange (EDI). The basic tenements of “ask the customer and engage the customer” are important here and again allows for the customer relationship model to be balanced. Just because you have an electronic interface to the customer does not mean it has to be impersonal. The reverse is true, the more electronic you get the more personal it needs to be. The customer will need more functions, customization options and more importantly personalization options. You need to give them a reason to be there and it can’t be to fill out your forms to make it easier for support. Adhering to good user design will enhance the user experience in order to balance all the sides to the triangle.

Now what?
You need to build highly personalized, relevant electronic customer interactions to the support side of your business. You need to provide opportunities for your customer relationship elements of your organization to engage the customer outside of the support group. There will need to be a balance of what is considered clerical and what is considered relationship. The customer will need to be engaged at all levels and at all channels. Every interaction between the customer and the organization must be customer centric. Always put yourself in their seats.
Do not be afraid to change and to change often. Learn from others and focus on how you can engage the customer and how that engagement helps the overall organization.

2009-02-16T18:27:00.000-08:00

E-Governance

The goal of a modern democratic society is to become more transparent and accessible to the masses. To achieve this governments have adopted the e-Governance model which is very similar to the e-Business model. Governments are pressured to run like a business and they continue to fail. The graphics explains the roles and interactions of the e-Government model.

In order to actually achieve the stated goals, a concerted effort has to be waged to address the potential imbalance of power and the new roles of the players.

Before I delve too deep into the dream of E-government, I will spend some time on the current traditional model.

The Traditional Model

In this ancient model the elected official is chosen from the people, for the people and interacts directly with the constituent (voter). The elected official will broker relationships to the administrator (public servant) to aid the constituent. In the beginning the elected official was in the position of control and power. Over time and due to the growth of democratic governments, the constituents started to deal directly with government administration. From simple licences, forms and taxation to more complex policy direction initiatives. The role of the elected official started to be altered as more and more requests were directed to the administrators. Before the Internet and open access the change was slow and to most unnoticeable. Many elected officials had no issues with transferring mundane policy and control issues to their administrations, sadly, much to their demise.

The explosion of the Internet in the late nineties and the push for e-Governance has caused a rapid imbalance of the power sharing arrangement. Left unfettered the power of government will shift to administration and away from elected officials. Some would argue that we have already achieved this undesired state.

The e-Governance Model

The diagram at the beginning of this post is for both traditional and e-Governance models. The graphic is meant to demonstrate the balance between the three roles. Once an imbalance occurs, actions need to be taken to re-establish the balance via other methods. Change of relationship and type of request are the first signs of the imbalance. An example of this would be the recent changes to obtaining a passport. This very important act can now be solely done without any elected official notice or input. Again, most people would argue, why does the politian need to know. It is not a matter of needed to know, but rather one more lost opportunity to understand their constituents. Today, a constituent can interact with local government regarding snow removal and garbage removal. In the past, the constituent would have called their elected official to discuss the matter and the official would have had a sense of the issues without having to ask the administration what is going on in their constituencies. The further the contact is the farther the relationship is.

The Elected Official

The elected official now has the ability to address their constituents in a proactive manner and not just the old reactionary method and passive mail outs. By using modern Internet techniques an elected official can get input on critical government issues without the traditional use of lobby groups. There is lots of current evidence to support true e-Grassroots initiatives. This evidence proves how effective and positive in nature they have become. The older traditional models focus on negative issues and comments. Examples of these initiatives is website that allow for public input, e-Surveys and website that provide status on projects and initiatives.

The Constituent

The constituent has direct access to administration and the appearance of transparency is there. By taking an active role the constituent is now in control of their government interactions. I have, in the course of my career, worked for both private and public institutions and I am constantly amazed of how little the public service knows of their customer (constituent). It is as close to ignorant and abusive as it gets. The public oversight challenge has been allowed to diminish the experience for the constituent. There are some jurisdictions that have been quite successful in their attempts. While other jurisdictions think the user (constituent) is actually a public servant (emphasis on the servant) and provide user experiences that are horrible. Try opening a small business in Ontario to get the full abusive experience.

The Administration

Along with the constituent, the administration element of e-government is one of the big winners,. The new technologies make it is increasingly easier to deal directly with the constituent and therefore disintermediates the elected official. The other big challenge is that the administration has no official role in the dealing with the constituent and is solely driven by police and procedures. The actual government systems are for the delivery of programs and services and as such cause friction to the elected official.

E-Governance can completely impact public policy and public policy execution without involving the elected official. This is the real risk. As current elected official get burdened with unnecessary work they have less time to engage their constituents and cause the imbalance to move swiftly away from them. Without their engagement they become more and more like figure heads being controlled by public administrators. The tail waging the dog comes to mind.

The Goal of E-Governance

The goal of E-Governance should be to engage the constituent on both the administration and elected official fronts evenly. By allowing input for public policy by the elected official and the day to day dealing of the administration all parties are in balance. All parties have to change and with change comes the fear, uncertainty and doubt (FUD) of a new power shift. We as a democratic people need to positively affect change and allow our governments to act on our behalf and not become slave to their own inefficient processes.

I will address on the next post the effects of e-Business on the traditional business model and you will see the striking similarities.

For both the e-Business model and the e-Governance model once you change the balance on one of the legs you have created transformation. Just streamlining or updating the current balance is a modernization exercise. Affecting the balance, causes by its very nature transformation issues.

OODA Loop

2009-02-09T07:54:00.001-08:00

Colonel John R Boyd the true public servant gave the world with his obsession, the OODA loop. You see the good colonel was confused as to why he was so successful in defeating his opponents at the Top Gun academy. He pondered why he was able to be so successful with a lower quality aircraft and with the same training. Most people would have approached the problem with why is my opponent not good or from a position of "I am just that good". Mr Boyd, who did not lack any ego still was humble enough to look deeper. His quest led him to analyse all the great battles in history and looked at alternatives as to why the battle was won and lost. The culmination of this research led to the infamous "Patterns of Conflict"power point presentation. From this research the OODA loop was created. All his research was for public consumption for he believed being the benefactor of the public purse for his career it was morally wrong for him to benefit privately from it. This cannot be said by some of his comrades and again gives insight into his personality. His research is brilliant in its brevity and clarity. Many firms like IBM have refactored his code and called it Sense and Respond. What a twist of fate, making money selling back the Military their idea. The classic consultant gig of a consultant borrowing your watch to tell you what time it is and charging you for it comes to mind. You have to love the irony in that one.

All this to say, that I use the OODA loop all the time for quick operational items, tactical projects and more importantly strategic matters. I also use this thinking in my Basketball coaching, it is that relevant and open. The basis of all trouble shooting verses parts replacing is within the OODA loop. Now let me explain the Loop.

Observe

The first "O" in the loop. This is the simple act of just looking with your eyes at the world around you. Nothing more. When you are called to someones office and you start to walk to that location, look around you. What do you see? Make mental note of this. When you are looking at problem what do you see? In basketball, I ask my players, look for the ball. What do you see?

This is a passive step and it the passive event of looking.

Orient

The second "O" in the Loop. The is the active act of orientation to the observation. Now you need to adjust your thoughts to what you have seen. If it is an error message, you start to ask yourself "what was the user doing?". My favourite question is asking "what changed". The orientation step takes into account all matters of the known and the inquisitive. Political factors, Social factors, business factors and technical factors all play in this realm. You need to put context to the first observation. This is where you can take a baseline and make statements such as I am in the presidents office, the scroll lock is on and the screen is saying the password is incorrect and you have observed the obvious frustration. The culmination of the observations and the orientation of the ancillary factors will lead to options for resolution.

I find many people do not take the time to orient themselves to the problem and more importantly the observations. This lack of interest in orienting to observations manifests into rudeness, lack of concern and many failed attempts at resolution. I cannot stress enough how important this element is to the overall process.

This becomes the difference between fixing problem or addressing a symptom. Take the time, do the research and put your observations into context. At this stage, I seek out the "moss backs" or "lifers" of a company to get some idea of why and how certain things have happened.

In basketball, I ask my players, who has the ball? If it is us, then we must be on offence. If we are on offense and you do not have the ball, then what are the offensive decisions you need to think about. That is the next stage.

Decide

This is the "D" in the Loop. This is the step that takes into account "make a decision". After you have observed something and have taken into account the periphery issues you can now put into focus your options. This in turn creates your decision. The decision itself is just a course of action based on what you saw and what you learn about your observation. Weighing the pros and cons of the decisions is influenced by your orientation step.

Will you buy or build your software? Will you implement the change? Who will you assign this project to? These are the questions that need to get answered and the previous two steps allow you to make better pragmatic decisions.

Going back to the basketball analogy, if we have the ball and you do not have the ball then you have two decisions to make. Move towards the ball or away from the ball. By working on decision based thinking your team is elevated from the stress of guessing and becomes a more accountable group.

Act

The "A" in the loop. The elusive action stage. All too many groups, make great observations, relevant and accurate orientations and make sound decision choices but fail to act. The implementation of the decision is paramount. Without it we get analysis paralysis and foster a culture of complaints and whining. Action must be clear and be specific to the decision. You must act respectfully in the spirit of the decision. Deciding to do one thing and then acting to the contrary is a colossal waste of time and energy.

The basketball scenario completes this step in this example by going away from the ball to an open place on the court.

And the loop continues

Once you make your action the loop continues all over again. This is the part where you get to observe what your action did. The cause and effect part. Your action will have impacted the process and now you start all over again to see how that action has affected the original observation. Is the problem fixed?, did the desired affect occur? All these things are now relevant.

The basketball player who moved to the open space on the floor, needs to find the ball again and orient themselves to the new reality and make decisions according. The next decisions and actions will be determined on these revisits of Observe, Orient, Decide and Actions

In the John R. Boyd world if you can get inside your opponent's OODA loop then victory is certain. This is due in large part to your opponent now being directed by your actions and therefore is behind in their processing. The faster your loops are processed and the more experience and exposure you get the better your decision making is and therefore your actions will be more effective.

An OODA loop can exist in nanoseconds (Emergency conditions like a vehicle accident about to happen) to hours, days and even years (Strategic Planning). The key is to be consistent and to educate as you communicate to your staff when they are not performing the loop effectively.

It is very powerful and is worthy of the attention of a young manager.

2009-02-02T19:23:00.000-08:00

THE IT STACK

The IT Stack as I have so affectingly named it has been drawn on so many napkins and scraps of paper that at times I find it difficult to take myself seriously. Then I look with amazement on the eyes of the recipient to realize it is as relevant today as it was in the early nineties when I was first exposed to it.

Yes, sometimes, the simple is really the best approach. I am visual and therefore this imagery is even more powerful to someone like me.

To the young Information Technology leader this becomes your compass for how and why decisions will be made.

I will explain the diagram from the bottom up for that is how we provide value to deliver the why of an organization problem. This is not just some trite literary play on words. The difference between how and why is the difference between organizational success and technological blunders. The latter is all too common when the bells and whistles become more important than solving the business problem. Do not chase the technology, but rather solve the organizational problem.

Here is the stack you can use to vet your solutions and their overall placement. Learn to draw this quickly on napkins and the backs of envelopes.

The Network

This is the basic pipes and plumbing of the Information Technology infrastructure. This is the physical cabling of the network, or the wireless infrastructure that allows your computers and users to talk to each other. This is all the telecommunications lines you have going into your buildings and branch offices to extend the reach of your connected devices and users.

Watch the monthly costs from your telecom provider to ensure you are getting the best value for your dollar.

Your networks need to be stable and built like a utility. By that I mean your users must have the same faith in plugging in a computer network cable as they do plugging in a toaster. When this focus is maintained confidence will be raised in your users. Your users should NOT know what type of network you have and how it is laid out. No one cares except your team so stop trying to impress your bosses and other non-related business units with the how the ones and zeros travel between computers. I cannot stress this enough. When I go into organizations and their business leaders are exposing the details of their network both positive and negative I become deeply concerned.

Networks have to be built to be used and abused. The physical plant should be well labeled and very well organized. You would be amazed on how many problems are due to sloppy labeling and wiring connections. Take pride in NOT having a rat’s nest for a wiring closet.

Technology Platform

This is the actual hardware that you can hug and hold and get all warm and fussy about. This has the pretty lights and fans that go whir. I get real serious about hardware and I standardize on what my team can support. Being an IBM Bigot or DELL Bigot does not help you here. This layer is now a commodity. However, if you have excellent support from a vendor then make sure it has some value on the purchase side if they are not the cheapest vendor. Having every make and model from every vendor out there does NOT help you. Buying hardware you can make on your own is great if this is in your basement and you have no friends. It does not have a place in the business world. Just because you can doesn’t mean you should. Let’s be professional here. You have much more important things to worry about.

The technology platform consists of the following elements but is not limited to these.

Routers, switches, hubs
Firewalls
Servers
Desktops
Laptops
Mobile devices
Storage Arrays
Printers
Scanners
Access points

All technology equipment must be respective and supportive of the network layer. These two layers depend completely on each other. Any mismatches here can have serious repercussions.

Applications

This is where the rubber hits the road or the user interacts with the system. This should be the only piece of the technology a user can explain and get intimate and animated with. The software should fill the organizational goal. The goal may be just a simple tool for adding rows and columns (read spreadsheet) or the goal may be to have a modern and robust warehouse management system. The user interaction should be respectful of who is engaged in the process/system. A repetitive theme in my posts is “if you wouldn’t use it then why are you releasing it”.

The application must also be written to be complimentary to the technology it is sitting on. No use in building a behemoth memory intensive system if in fact the user experience can only support minimal processing capacity. Use some forethought.

Like the interdependencies between the technology layer and the network layer so is the application layer to the technology layer. There is one exception for the application layer though and that is the application should also be sensitive and supportive of the network. A final check between the application layer and the network layer is paramount. You must be aware if your application cannot support a high speed network. All too often software programmers have no understanding of how networks actually work and therefore their applications do not provide a proper user experience.

A simple list of some application layers are as follows;

Office productivity tools (MS Office, Open Office, Lotus Smartsuite, WordPerfect)
Operating systems
SAP
Peoplesoft
Warehouse Management Systems (WMS)
Transportation Management Systems (TMS)
Enterprise Resource Planning (ERP)
Business Intelligence
Sharepoint
Email
Text Messaging
On screen programming for your Satellite receiver
Firmware
Content Management Systems
Facebook
YouTube
And many more. The list is endless

Drivers

This is the actual business or organizations drivers to proceed with any effort. This is the problem that is being solved and interaction should only be with the software application layer. The organizational leadership should not know about the hardware and/or the network that is delivery the solution. This is so critical. The bottom layers should be hidden from the system users. If they know the intimate workings of your solutions then you have failed. I cannot stress this enough.

The interaction is just between the problem and the solution (application user interface). The solution may have all elements of the layers in the ultimate solutions but that is not what the organization needs to know or really should care about. Sometimes when I am in a meeting with the business units and my team is present the conversation will typically lead to one of my team member saying something like “well that will be a performance hog or man that is a lot of data” and my internal or sadly at times external response will be “so what”. That is the correct answer. Sometimes to really solve a problem we will have to update the technology, applications and the network and that is our job. That is our problem and the business users.

HOW

This is the value we bring to the organization. We bring the HOW the problem will be solved. We bring recommendations to the organization to give them the tools to succeed.

We bring value through a relevant application layer that is sitting on a stable and effective technology layer and is running on a ubiquitous reliable network layer that is responsive back to the application layer.

WHY

The decision making process is from TOP down. The organization provides the WHY and the Information Technology group responds with an effective HOW. I am a strong proponent of Information Technology providing recommendations and the organizational leadership provides decisions.

But before you give me “your shitting me, right”. There are some decisions that fall in the complete purview of Information Technology leadership. These decisions will always be based on business realities and sound business judgment. The ultimate network layer and technology layer are decisions that I do not give up without a fierce fight. However, before these decisions are made I take time to understand our budgets, long term plans, support skills etc. Once the standard is set by the Information Technology group then we only need to get approval for funding and not the actual decisions

I was once told if you can’t explain an idea on the back of an envelope or a napkin it is not worth pursuing. If this is the case, the IT stack is a sure winner in this category.

2009-01-27T08:37:00.000-08:00

The bread and butter of any methodology. This is NOT unique to Information Technology regardless of how many articles and geek speakers you have been informed by. This is as old as time. The Romans whom were the architects of modern, yes modern project management, knew the inter-relationship of People, Process and Tools (Technology).

Whether you are building a home or just implementing a function in a program your balanced approach needs to be considered.

When this triangle is out of balance to the needs of the organization then problems arise. All elements of the Information Technology value chain (Network, Technology, applications and business drivers) must be audited to ensure the organizational goal are met.

People are the cornerstone to any successful approach. People must have the proper training, desire, capacity and spirit to succeed. You as the leader have to let your people do their job. Give them the environment to succeed and at times fail. All too often we want to step in to fix the situation and this can cause longer term issues for the team. Team members must have the confidence to proceed as they see fit within the larger context and in a respectful way.

I have worked many sides of the Information Technology arena. Generally speaking infrastructure groups gravitate to processes and development groups gravitate to the creative open ended side. I have found the best developers are those that explore their creative side and the best infrastructure people adhere to defined processes and are focused trouble shooters. This latter group are your bush wise survivors and the former tend to be the tortured artists. Embrace both and provide an environment that is conducive to their unique styles.

Some of the key areas that fall within the people element are;

Training -- This should not be a reward or vacation but an investment for the organization and the individual.
Administrative support -- Do your paper work on time and with pride
Mentoring -- Educate as you communicate
Performance reviews -- This is critical to all parties
Supervision -- Who is running the mad house
Discipline and corrective action -- Be firm but fair. Focus on the message to those watching
Motivation -- Let them know when they are doing a great job, support them in dark times and provide a vision for their efforts

If you are ones of those recently promoted from within the ranks or from within the craft it can be very difficult to make the adjustment to management. One of my first realizations after knowing I was now paid for what I was able to get done was that the members of my team were now a tool within my larger kit bag. This is by no way meant to convey arrogance or maltreatment but rather the opposite. It was a very humbling realization. You now have the responsibility of this new tool and you have to effectively use it without breaking or damaging it. This new tool which you have no previous knowledge or comprehension of is not the inanimate tools (hardware and software) you used in learning your craft. This tool also did not come with any user manual and has a tendency, at times, not to work as expected. For this the axiom, people tend to do what is inspected and not expected.

You as their leader are now faced with much more responsibilities then just what happens at the job site. Your team will look to you for guidance, direction and to set the baseline. I encourage new managers to imprint their mark on their teams. This is not a simple task in this craft we call Information Technology. Most of us, were attracted to the purity of the technology and our ability to manipulate it impersonally. Now as a wielder of this human tool, our caviler attitude or iterative approach to tool learning will work against us. We must take a much more pragmatic and exterior view of the group and how they inter-relate.

Some sound advice in this arena given to me when I became an infantry officer from my grandfather who was a highly decorated Sargent in the Canadian Army during the second world war was this. Lead from the front, be the last to bed, last to eat and first to rise...... Take care of the men behind you and they will protect you from the enemy in front of you. Very sound advice to anyone who has a team under their care.

There are several other factors in the people element that I try to remember when working at my craft. Most of us, will be technology dealers with humans at the other end. Either as users or consumers of the craft. Be respectful. Would you want to use your technology every day. Does it take into account the normal dealings of your intended and sometimes unintended users. Put yourself on the other side of the screen or interface before you roll out your solutions. When users and some times abusers call us for help remember regardless of what mood they are in or for that matter what mood you are in, help was asked for...... How about providing some without the drama. As a manager you need to be respectful to the group of individuals you report to. Are you meeting their needs with your what your team is responsible for? Do you understand the vision? Are you moving the overall agenda forward? Are you part of the solution or the problem? These are the questions you need to reflect on when your team engages.

Process is for some, me included, one of the coolest elements of the approach triangle. When I am in an engaged business meeting discussing business challenges I become hyper sensitive to the processes being discussed. Established, effective process allows the machine to run smoothly. A simple effective process for time and attendance reporting has way more "acceptance" value to your team then an overburdened software development life cycle process. Again, remember it is people who use processes and that a good solid process take the human element into account and is people centric.

All the process you come into contact with both as a user and as a developer must be thoroughly considered for its relevance to your organization. There are now very mature Information Technology processes for you to draw on. But anything else in this craft, you must learn to harness it and apply it with proper care and use. You must assess the capacity maturity level of your team and organization before you delve too deep into a process. I find it best to walk before you run. I have also implemented processes that I call transitional processes. That is I introduce the base elements of a mature process to educate the team or organization before going after the larger more complex implementations. A good example of this is a ticketing system for work requests. If your organization has no formal method of asking for work to be completed then you need to implement a simple trouble ticketing systems before you go after a full service desk implementation of an ITIL best practices approach.

This blog will endeavour with future posts to explain and elaborate on formal Information Technology processes. Below is a list of processes that I believe are essential to leading in an Information Technology profession.

ITIL
Capacity Maturity Model
Project Management Institute
Project Management Book of Knowledge (PMBOK)
Software Development Life Cycle
Patterns of Conflict (OODA) -- A must read for anyone interested in effective problem solving.

Each of these has many books and reference points and I encourage anyone looking to hone their skills to read and understand these processes and their effective implementations.

The Tools element of the approach triangle is where I get my most enjoyment. I am such a tool junkie that at times I embarrass myself. This is when the true inner geek in me lets go. I do not care if this is a new wood working tool in my vast collection or a some wicked free network monitoring tool. I get all goose pimply and child like. When I get caught in the gaze of one of these tools I become 5 years old again. What fun......

However, in our chosen profession we have way too many tools now at our disposal. My grey hair is a constant reminder of the best of times was when we built our own tools to achieve our end goals. The older I get the better I was. One of the main poignant reasons for this, in my belief, is that to make a tool, the crafts person needs to understand the "why" a tool is being made. A tool user is only fixated on the "how" it works. A very important difference. I find a great deal of my colleagues have become so obsessed with tools that they forget why the tool was needed in the first case.

Network monitoring tools for me is one area that causes me the greatest concern with younger shops. The tools today are so rich and powerful that the user of the tool becomes an observer and not the crafts person. Times like this the saying "a fool with a tool is still a fool". It may seem harsh but we have all been witness to it. We also see this in our user community when we come across a super user from the Excel warrior camp who can dazzle the bosses with great ease. Only to find out that his tool of choice is using stale data and is out of sync with the full body of knowledge. But it is impressive to watch even in a sick sinister way.

Be careful when your team is constantly coming to you to buy or implement a tool to better their lives when they have not convinced you it will help the overall team and/or organization. This is usually a sign of lack of team focus or lack of confidence in themselves. Make sure the tools being acquired are being used and that value is being returned back to the organization.

Visual tools are very powerful, whether they be in the development arena or the monitoring arena. All users of these visual tools must be reminded of the underlining work that is being performed by these tools. Failure to do so, makes you the leader of the fools with all the cool tools.

One of my favourite tools in my leadership possession is the employee evaluation. I choose to use this tool to educate my team on what is expected and more important to reward efforts and behaviours. I was born with the greatest tools of all and that is two eyes, two ears and one mouth and I attempt to use them wisely and in the correct order.

In conclusion, when your approach is balanced with engaged people, relevant processes and effective tools then you can be assured your team will have what it takes to be successful. When you feel or witness stress in the team, ensure all elements of this approach are in balance.

The culture needed

2009-01-19T13:50:00.000-08:00

If the core of a team are its values then the mode of its execution must its culture. The culture becomes the predictor of the end result. For example, in most instances it is safe to say the culture of government is "oversight" and "bureaucracy" and that this culture is also not one of innovation. When you think of Apple you might come to the conclusion of "innovation". In many of my past lives I have had the fortune and misfortune of being inside an organizational culture.

When I am given the helm of a team, a department or a division, I spend a great deal of time orienting myself into their existing culture. The process I use to do this will be written about at another time for it is quite involved. This is where I find out if the team is focused on problem solving or problem identification -- is the team focused on solutions or just "order taking". These discoveries led to actions that allow me to imprint a different vision if needed. Sometimes the culture is fine and it is me who has to adjust. This latter part is very important. You must always ask yourself if you are part of the problem or the solution. Self reflection is paramount.

The purpose of this post, like the other, is to aid the individual who is new to the management role and comes from the technical background. One of the largest leaps that is required is to go from "being paid for what you do" to "being paid for what you get done". This may sound easy but it is tough to step away from the technology and deal with the people and process issues to get the team motivated to complete projects and tasks. Your personal currency is all you now have to complete these things.

What does all this have to do with "Culture"? Well, in a nutshell, everything. If your users/clients/stakeholders know how you and your team will come up with solutions and you adhere to your values then there is an expected outcome. If you build a culture of "get it done" with respectful values then good things happen. If you build a culture of oversight, governance, process and your values are self serving and protective you will find the user environment has found very creative ways around your team. This is quickly identified in those organizations that have "death by spreadsheet and/or MS access". A typical red flag that the IT Culture is not working for the larger context.

So what does the above graphic say of the culture I embrace? I will attempt to explain.

Improvise

This is the starting point for me and the team. We do not live in a lab were everything is controlled and we have unlimited funds. When a problem or what I call an opportunity presents itself, look to other options. This is how technology gets used in places that it was NOT designed for. It is 2am and a critical printer is down and there is another slower printer somewhere else. Then move the job there, do not get hung up on the drama of the user complaining about the speed. Slow is better then stopped. In the programming world, use alternate techniques that exploit your environment to the fullest and stop chasing the latest and greatest. That only leads to confusion and distraction. Yes, the computer science guys cringe at this one but lest be real. Boiling the ocean of the possible for a report or query that gets run once a year is not the best use of your human and technical resources. Improvise is used for that resourceful group that can get creative in a pragmatic way. This is not to support not standards thinking but rather thinking on your feet. This goes hand in hand with Courage to act. For those of us old enough the phase "MacGyver it" resonates as a key element of improvise. To the younger crowd the phrase "duct tape and binder twine" resonates.

The element of Improvise promotes creative thinking, solutions centric thinking and a "can do" attitude when improvisation is supported and more importantly promoted. The message being received by your stakeholders will be one that is positive and collaborative. Even with our standards, oversight and process we can still be nimble and relevant to the organization.

Adapt

Honestly, this is the one that I find the Information Technology group struggles with the most. For a group of individuals that inflict as much change (read pain) as we do, we are the worst at adaptation. Once we find something that works or has given us success we become the immovable force. We have more baggage and hangups then the dysfunctional celebrities we mock.

The adaptation step is one where you assess you role, position and meaning to the larger organization. Information Technology by its very nature is a service industry. So who are you servicing.? If you are in a technology company with lots of engineers then go nuts with the acronym soup. They will love ya. However, the vast majority of our members work for real businesses with real issues and little to no appreciation of what Technology can do for them. Get over yourself and start to educate as you communicate. If your company is capital constrained then look to operational solutions. If cash is easy to find but human resources are low then look to those solutions that make your department self sufficient and outsource those elements you do not need to know or do not have the hands for. Never outsource your competitive advantage or business knowledge. This becomes a dangerous game. Other posts will speak directly to Outsourcing for it is quite involved and has many real positives. If your team is not very creative then you need to draw outside help to get those things done. You need to appreciate the stripes on the zebras that are your team. You are the leader of a group inside a larger group. You will need to adapt to both internal (your team) and external forces. Resistance and steadfast has their place. Observe and act accordingly. I was once told by a mentor, "you have two eyes, two ears and one mouth ----- use them accordingly". By listening to this advice the level, and depth of adaption will be known.

Overcome

If you believe the above two elements then the third element of Overcome is a natural outcome. This means, do not lead your team through the rear view mirror. Look forward and put in solutions reflective of what is NOT what was. I have found, regardless of how bad a system or infrastructure is, people believed it was the right thing to do at that time. It may have been done out of ignorance or arrogance but rarely I have found it was done out of malice. This is important to understand. Sometimes, you have to come forward and say redo it.

By looking at what is and adapting to the reality of what you have at your disposal and being creative in your solutions you will be able to solve (overcome) the real issues and provide real value back to the organization.

Another way of looking at this is "do you want to be right or do what is right". Doing the right things now, for the right reasons is overcoming the obstacle and not being stopped by it. Do not buy into "the sky is failing" syndrome. Deal with it, respectfully, get all the facts, come up with options and implement the solutions and you would be amazed at how blue the sky really is.

We work in an industry that rarely informs us the good things we do. We are inundated with negative issues all day. It is our job and our primary goal to deal with these issues and provide solutions, interfaces, experiences and infrastructure that solves the real issues and not the symptoms. Always ask yourself, would you use the solution provided? If it is not a resonating "YES" then why did you implement it or why are you implementing it?

Team Values

2009-01-12T13:24:00.000-08:00

Values are the core of any team. It is even more important for Information Technology Teams. The problem with most IT groups today is that they hide behind lingo and processes. The goal of IT is to leverage the technology to move the organization forward. To do this your solutions must be values based. This is a tall order in a society that rewards the "passive aggressive" and the "techno weenies".

The value element of Courage is the one I encourage the most. Courage means many things to many people. One of my favourite quotes regarding courage is from Ambrose Redmoon and it reads like this "Courage is not the absence of fear, but rather the judgment that something else is more important". Within our Team "Courage" refers to the courage to ACT. Do something. Analysis paralysis is not an option. The action must have been thought out and must be sensitive to what problem is being solved. Once the action is done, you must review and followup your assumptions t0 ensure your action had the desired affect. Failure to do so, creates havoc. My team will be given great latitude for a thoughtful and purposeful action. Inaction must be weeded out and people's tendency to stay safe must be discouraged. I make reference to the "hero" syndrome created by the engineer who wrote one email on the POTENTIAL of the O-rings failing on the space shuttle. After the crash investigation this person was given hero status for his ability to highlight the problem. The sad part is upon further investigation it is found out the email does not provide options or even a detailed occurrences of solutions. Just the basic, its broke, and I have covered my position. This is not helpful. We as a human race have never accomplished anything from the comfort zone. People must act to progress. Staying safe and looking for the "OUT" instead of "How can we" is not the recipe for success. This comes with a great burden though, for the action comes with risk and is fraught with naysayers. Place your compass on doing the right things for the right reasons and look beyond your department for what is really needed. Action to move forward, in the end will always be the better approach than, sitting back and letting the inaction take on a life of its own.

HONOUR to be accountable is the next value statement. This means, in our Team's context to stand up and be counted for the decision that was made and/or the action taken. Facing the music as it were. Not just for ones action but for the actions of the team. Accountable to self and to team is just as important. The good news in this regard is that if you are person who not only takes accountability but encourages it, your team will be known as people of Honour and your word is golden. This is proved by the actions taken and the commitment to see it through. By being accountable you open your team up to public failures, however, this is offset by being openly invited to those decision making tables. This gives you and your team personal currency and places you at the decision table. Without this, your team will just be "order takers" and not solution providers. Always being accountable is hard work and sometimes it is perceived as witch hunting. When done consistently and promoted effectively it will become an organic continuously improvement exercise. Your team will also become the benchmark for other departments to emulate. I quickly weed out those individuals whom look outside themselves in time of crisis and internally in times of success. A good leader corrects an issue internally and quietly. Along with this, a Good Leader compliments his team externally and internally to promote good behaviour. This latter part is not trite or a facade but rather an acknowledgment the team succeeds and the individuals within the team must be recognized according.

Integrity is the last element of our value proposition. It is also, I find, the most difficult for our industry to live up to. In our team context, it refers to Integrity to work with others. To some degree we, in the technology arena, have become snobbish and arrogant. This is not how to become a trusted adviser to the organization. Information Technology cannot be successful by working in isolation or in silos. They must work cohesively within the team and more importantly with the organization as a whole.

The next part of this is the part some IT group will hail as blasphemy. Within the larger business context, the IT department does NOT, yes NOT make decisions we make recommendations. Information Technology should be looking at all solutions from the business/ organizational context. They should not be making decisions from an engineering or techno gissmo perspective. Come on, we have all done this in our personal lives. The shiny pots and beeds, the flashing lights, we can't help ourselves. This is the technology trap. Having said this, I am not recommending you let the business run information technology cart blanche. For I also have another saying. "those who think they know, really annoy the ones who do". To counterveil the latter from the former, it is imperative the solutions provided must solve the business problem. You have to bring all elements to the table, not just the shiny ones with all the lights or from the vendor that keeps you nice and comfy in your Management chair.

Search deeply, look into the organization. Get out of your office, walk the floor, know what your organization does from all aspects, not just how they interface into your technology. I pride myself at providing solutions that take the other side of the glass into consideration. If you had to do the job all day would the solution be something that helped or hindered. To know this answer you MUST work with them and be a leader to them. It is a tough balancing act but one that is worth the effort.

In conclusion our teams values are the Courage to Act, the Honour to be accountable, and the Integrity to work with others. Don't just say it or put it on your screen saver. Live it for deeds speak.

My first post

2009-01-02T13:28:00.000-08:00

Well bare with me as I stumble through this new adventure. I would like to use this forum to aid those individuals whom are trying to climb the organizational chart by way of the Information Technology latter. Yes this can be done and with much success.

The Rule of engagement for this adventure is not different than any other group but most things IT we tend to over complicate and forget the trip has already been done by others, some wiser but none the less others.

The concept of this blog was derived by a book proposal I have been playing with. The title of this book is/was "Making !T Work". You will notice the "i" is inverted and is in fact an exclamation point. Both are relevant.

I would like to share for that is what I do with anyone who will listen and in this case read. The title of the blog is Design principals for I strongly believe every project/undertaking should have a purpose and it should stay focued on it. So with this I will end my first post and commit to bringing some points forward.

I will be discussing Portals, Project Management, framework design, my three triangles (come on you want to know about that) and many more items. I will tell you what I will bring forward is not new for I truly believe we stand on the shoulders of giants.

I am really looking forward to your comments and suggestions on topics.

Have a great 2009.