It doesn't need to be this way

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

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

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

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

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

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?

 

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

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

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

Burdens of Blade Centers

1. New skills are required to maintain the platform
2. Software to build the platform will need to be purchased
3. Migration project will need to be undertaken to port the existing 11 servers to a common platform
4. Organizational policy change to support central housing and shared resources
5. Governance structure for support and backup rotations
6. 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

1. Agree to the strategy
2. Build a requirements list for the platform
3. Build a RFP
4. Source the platform
5. Build the migration plan
6. Perform the migration

The challenge of Voice over IP

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

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

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

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

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.