Emergency Management

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

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

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

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

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

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

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

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

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

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

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

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

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

change management matrix

A stages of change matrix with their symptoms and options

Change Management

The people side of Change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In conclusion

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

 

 

 

 

Service Desk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The project Manager's Mantra

Project Management -- High Level

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

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

Time

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

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

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

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

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

Budget

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

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

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

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

Scope

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

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

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

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

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

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

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

 

Portal as a broker

The portal 

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

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

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

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

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

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

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

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

Broker…

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

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

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

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

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

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

No end-state… 

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

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

The Roles 

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

People 

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

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

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

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

Content

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

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

Applications

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

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

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