Before I begin I admit that I do use Microsoft products (just not IE) and, for the most part, I’m quite happy.  Microsoft has done a lot of good in the world but when it comes to the web browser the battle between IE and the rest of the browser world is costing us all.  Consider the following . . .

In any web browser is the capability to view the source code of the page that you are viewing.  Now, most of us would never really want to look at this but if you did and you knew a little bit about website code you would see one very common piece of code handling.  In almost every case, a web developer has had to insert code that checks to see which browser you are using and, in almost every case, they are looking for IE.  The reason?  Because IE will not display a website the same as every other browser so special code needs to be written to handle IE browsers (I say “browsers” purposefully as there are even differences between IE versions . . . more on this later).  There are a multitude of reasons why this happens but essentially, IE is a non-standard browser wherein almost every other browser is (I’ll leave it to those with a more intimate understanding of the technology to explain how we got here since I have a different point to make here!).

Due to IE’s prominence on a Windows based machine, most people will simply click the “e” button and launch IE when they want to browse the web without a thought to installing something else.  Consiquently, as long as Windows continues to be the predominant operating system IE will continue to be the browser most people use.  Notwithstanding increases in Apple and Linux market share, we are still stuck with IE for the next while and thus an ongoing need to accommodate its proprietary annoyances.

The big issue I have is that accommodating IE costs me money.  If a project is going to cost me ‘X‘ dollars, a certain percentage of this will be additional programming costs for IE.  Even worse, any major release of IE (based on past experience) is likely to lead to additional programming costs to “fix” code that was already stable in all previous versions.  I tend not to have this problem with any other browser upgrades.

Now, arguments can be made as to how we got to this point and Microsoft could argue that they have a better technology and everyone should adopt their way of doing things, bla, bla, bla . . . but the fact is that if it’s costing me money to adapt to the quirks of IE then it’s costing everyone else too.  And it’s not like it’s a cost that we pay that Microsoft can even benefit from.  That additional expense is pure overhead and does not flow to Microsoft.  It goes to simply making our industry less efficient.

What to do about it?  Well, the thought of a class-action lawsuit crossed my mind but perhaps the best solution is to encourage your friends, family and co-workers to switch browsers to anything other than IE.   Resist the IE temptation . . . I know, it’s so enticing just sitting there waiting for you to click away but don’t do it!  Download Firefox, Chrome, or Safari all great browsers (note you’ll have to start IE to download them but you’ll only have to do it once!!) and vote with your browsing!  And don’t get me started on the Flash on iPhone/iPad thing!!!

Anyone following my posts would know the importance that I put on people in the IT equation.  Rarely is a failure of an IT project due to the technology itself.  In fact, whenever I hear people complain about an IT solution I immediately look to issues related to the organization and resourcing to determine the problem and not the technology.  More often than not, a system’s failure to deliver is related to the commitment the organization has to aspects such as training and resource availability or the lack thereof.  Given the importance of people, it continues to amaze me how its this aspect of system development that suffers.

The People Factor

People within any organization are impacted by IT change and whether it’s a new system or upgrade to an existing one, there are implications to people that must be considered.  These implications include:

• Workflow changes – presumably we are implementing a technological solution to become more efficient.  Efficiency means doing things differently and when you do things differently it means that people are doing things differently.  Simply put . . . what you did before the system was implemented will be different than what you do after and you have to build in this change into your implementation.
• Staff training – There is no great surprise here . . . if you change workflow and introduce new systems you need to train staff.  There are two aspects to training; initial and on-going.  It’s easy to build in initial training into your implementation but much more difficult to incorporate on-going training.  One is “one-off” while the other requires continual monitoring (and budgeting!) and consequently is the one most often dropped.  On-going training is, however, just as important if not more so unless of course you are in an organization that has no staff turnover.  If you have no staff turnover then forget on-going training!
• Additional resources – There is a myth or, more accurately, an assumption made about information technology; it saves resources…i.e., you can get rid of people.  Although this might be true in sectors that traditionally employed great numbers of people to get the job done it doesn’t apply in local government.  More often than not, the organization was under-resourced in the beginning.  Adding a new IT solution generally means that existing workflows can be done more efficiently but really what it means is that you can do more with less.  That doesn’t mean you can stop hiring.  What it means is if you needed three people to do the job before IT then you might be able to get away with one additional resource rather than three to do the same job.  Note I said “one” and not “none”!

Within all of this is an embedded fear of change that must be acknowledged as part of a successful implementation and you can only ease the pain of fear by taking a people-approach (more on this in another post).

People-Technology

I believe that IT has matured to the point where any given solution is high quality and the steps to implement are well laid out and straight forward.  Given this, we should be able to focus less on making sure the software and hardware works and more on how the people will work.  Let’s start thinking about IT projects as PT projects. . . people-technology projects.

By focusing on people rather than technology an amazing thing happens.  Almost by magic, the technology we implement will work no matter what option we happen to choose.  In fact, the organization will have vested so much of itself in the success of the implementation it will be next to impossible to fail even if the technology itself is lacking.  No solution is perfect and the sooner we realize that it’s people that make the difference the better.

In my last post I talked about assessing and planning for risk as part of good IT management practice.  Risk assessments are also an important component of the evaluation process when determine which solution to choose amongst many offerings.  Although it might make sense to choose solutions that minimize risk (the IBMs of the world) there are drawbacks to placing too much emphasis on minimizing risk as a strategy for a successful IT project implementation.

When embarking on a new system, what is the number one thing that keeps you awake at night?  For me, it would be that the system fails to deliver what was promised after all is said and done.  This is why we assess and manage risk.  When any system fails it’s usually because risk was not properly identified and contingency not adequately accounted for.

There is a huge temptation to minimize the chance that a failure to manage risk causes the downfall of a project by choosing a solution that is proven.  That is, the solution has been implemented in many other organizations and is seen as somewhat of a defacto standard.  In local government, there is the tendency to do the same as the neighbouring municipality as a way to not only minimize risk but allow for opportunities to collaborate and thereby reduce costs.  All noble and legitimate rationals to be sure and an approach I often advocate in my consulting work.

There is, of course, a downside.  Bigger is not always better and the incremental decisions amongst many IT professionals to minimize risk by going with what is proven stymies innovation.  More often than not, the provider in the enviable position of having the solution that everyone wants develops a level of arrogance along with increased costs of ownership.  Everyone knows you have the best solution going and ye shall pay for it accordingly.

It takes considerable courage to go with a solution that is different than what is seen as the norm.  In the case of local government, there is often not a lot of wiggle room to go with a riskier solution.  However, if risk is properly managed even these smaller riskier solutions will work out fine and likely at much less cost than following the herd.  It really comes down to the culture of your organization and how sensitive it is to risk.  Some municipalities have a sense of competition and innovation and others don’t.  Just like managing your own investment portfolio you take on the amount of risk you are comfortable with; municipalities are no different.  In the end, risk can pay big dividends so it might not always be a good idea to minimize it . . . it could hurt!

Risks are elements of a project that have the potential to derail successful implementation.  Generally, if you have several options to solve a business problem you will go with the one that has the least risk; all other things being equal.  The solution you finally chose will still have some risk but you at least have put some effort into understanding what the risks are and can take measures to minimize their impact on your project.

A risk assessment is the process of identifying all the nasty things that can happen to your project then evaluating each of them with respect to their seriousness and likelihood of occurrence.  I find it helpful to bring together project stakeholders and have a discussion to identify risk since it tends to be hard to think of everything on your own.  At this stage, don’t rule anything out.  You will quite quickly narrow your list of risks down to a number of key ones worth mentioning while others can simply be discarded as so remote that they don’t warrant consideration.  Also make sure that you have your IT mission and vision in mind as there can be risks that directly impact your strategic direction.

Once you have identified risks, evaluate each one in terms of their seriousness and likelihood.   In the insurance industry, seriousness and likelihood are supported with copious amounts of research and statistics wherein a quantitative assessment can be done.  Less opportunity is available for such quantitative analysis in IT so your assessment will be more qualitative.  I believe in keeping things simple so I use a rating of Low-Medium-High for both seriousness and likelihood.  You could also use something like the graph below (if you don’t see the graphic click here) and have stakeholders place a point where they think the risk should fall.  After, you could overlay the graphs and see clusters indicating a consensus assessment for a risk.

Once you have evaluated seriousness and likelihood it’s time to grade each risk depending on their combined seriosness/likelihood score.  If you are using the graph, the action required to limit the risk depends on which quadrant your assessment score fell.  If you are using the Low-Medium-High method then you grade each risk based on the following table which, in turn, corresponds to the required action:

It is good project management practice to review your risks periodically and evaluate whether their condition is changing.  It is possible for a low level risk move to be a high one as the project develops and thereby requiring a different course of action.

So, in summary, to assess risk of your project do the following:

1. Identify risks particularly those that have the potential to impact your mission
2. Evaluate each risk based on seriousness and likelihood of occurance
3. Grade each risk according to the seriousness and likelihood rating
4. Plan action according to grade
5. Re-assess risks frequently to monitor change

Take these steps and you’ll go a long way to implementing a successful project and minimizing surprises!

When Donald Rumsfeld made his famous speech it sounded silly and ridiculous but what he was getting at was actually quite profound.  Consider any management decision you might make; you usually make decisions based on the best available information (some people use dart boards but I’ll talk about them in another post!).  But of that information, how do you know you have enough?  Presumably, to make the decision you reached a point where you felt there was enough information but what if there were significant gaps of knowing that you are not even remotely aware?

I’m not talking about gaps in your knowledge that you do know about.  I, for example, know that I don’t know everything there is to know about wireless data protocols but if I needed to make a decision that involved this I would know how to find out or who to ask.  I, at least, knew the gap in my knowledge exists and can take measures to address it.  But there will still be a component of any decision that is your blind spot; that part of your decision making that you didn’t even know that you didn’t know.

There is no way to ensure that you know everything you possibly need to know for a decision but you can certainly take action to make sure your decisions don’t fall victim to your knowledge blind spot.  The trick is humility.

If we accept that we don’t actually know everything (nor can we ever hope to) then we open to other possibilities.  We begin to listen to other perspectives that might cause us to stop and see that we do have a blind spot and may learn what to do about it.  If pride gets in the way (“I do” or “should know everything”) then we remain closed in our own known knowns . . . a sure fired way for those unknown unknowns to get you. . . as they did with Mr. Rumsfeld.

Article: Please do not change your password.

Strategic plans are formed through an analysis of an organizations strengths, weaknesses, opportunities and threats (known as SWOT analysis) relating to the mission.  For local government IT the mission is most likely providing the necessary infrastructure and support to assist in provisioning municipal services.  From this analysis comes a list of activities or projects that will be done (strategic goals and objectives) to support doing the things an organization is doing well and address those it isn’t in context of where it sees itself (known as the vision).   Each strategic goal and associated objective will have a measurable target that provides a way of determining how well the organization is doing.  In this way, projects that are in a plan are linked to a rational for why its being done.

Some might argue that strategic planning for IT is too difficult since the technology changes so rapidly that it’s impossible to plan meaningful strategies.  This argument focuses too much on the technology and not enough on the need to use technology to solve business problems.  Focus on the business problem and the technical solution becomes almost secondary.  If you can solve a business problem with today’s technology it’s likely the problem will still have been solved three years from now.

Most IT strategic plans that I have seen are simply technology plans that outline the organizations wish-list of IT projects.  They are not tied to any particular objective other than to satisfy someones need (legitimate or otherwise) for a particular system.  In itself, this may not be bad.  Some good work has been done by people who champion (bully?) a particular IT project into existence.  However, in this approach, those who are not successful at championing projects usually get nothing.  The strategic plan helps to keep the focus at the organization level so that all areas of the business contribute to success of meeting objectives.  It’s all about making the whole organization better not just a single department.

It has been my experience that organizations that embrace strategic planning and do it well are high performance organizations.  They are efficient, well run and, most of all, have developed a culture of excellence that permeates every aspect of the organization.   In IT, strategic planning keeps the focus on the business and not on the technology.  A good IT strategic plan is clear that technology is a tool to make the organization run better.  It’s not about how many IT projects you can cram into your three year plan.  If there is any one department that would benefit most from doing strategic planning well it would be IT.

A common request for local government GIS is to include inventories of all manner of municipal infrastructure.  This has recently come to the forefront with changes in many jurisdictions surrounding accounting reporting of tangible capital assets.  But even before accounting rules changed there has been an almost irresistable lure to use GIS to capture inventories.  What more could one ask for than to simply and quickly bring up all of the infrastructure you are responsible for on a computer screen to report and print to your heart’s delight?

There is, of course, no doubt that a GIS is a wonderful tool for managing and reporting on this type of information however what often gets lost is the need to maintain the data once its in the system.  Consider this scenario

Public Works has seen the GIS and would love to use the system to keep track of street signs that, at this point, is kept track of in the head of the Roads Superintendent.  It makes perfect sense to get this data in a form that can be shared and seen by all those responsible for road signs.  A project is quickly undertaken to capture the location of all the street signs using GPS and load the data into the GIS.  Not too long after the data is displayed, staff begin to notice a difference between what’s in the sign database and what’s in the field.  The GIS becomes unreliable and staff go back to using their heads to manage the sign inventory.

During the course of implementing the sign inventory no one bothered to consider how or even who was going to maintain the inventory once it had been created.   If a sign is replaced, how would the database get updated with the change?  If a sign is cleaned, who updates the database to reflect the service was performed?  If a new sign is installed, how does the new record get added to the sign database?

These might seem like simple questions but once an organization starts to consider the implications of maintaining new datasets the reality soon becomes apparent that managing the technology is one thing . . . managing people is another.  In the example of the sign database, who’s job responsibility will change to add the responsibility of updating data records?  Most organizations, particularly municipalities, do not have a lot of excess resource capacity so where will the new responsibilities fall?  Are there additional training requirements?  In unionized environments, will positions need to be reclassified to allow for the changes in a job function?  Solving these issues can be far more difficult than any technical hurdles.

How do you avoid the proliferation of stale inventories?  As with any information system, a proper implementation plan is critical that must include a full understanding of the problem and its implications on the organization before touching any of the technology.  Understand why you need the inventory, what will be the benefits and, most of all, who is going to be responsible for its maintenance.  Once you understand the business you’ll be ready to pick up the tool!

Consider first the nature of managing an IT infrastructure.  Managing IT is often like managing an orchestra with its myriad of complex components that all must work together to provide an always-available service to our customers.  It amazes me that it all works as well as it does when you consider the many failure points that can bring everything crashing down!

When a mistake is made there is a huge over-arching temptation to blame one of the components (software, hardware, consultant, other team members, etc.) as the culprit.  I see this all the time.  A system is no longer performing up to expectation and the fingers start pointing everywhere except at the one doing the pointing.

I try to admit quickly to my mistakes but the key, of course, is recognizing that you have made one in the first place.  It is important to understand what role you have played in a mistake since rarely is a mistake the responsibility of only one person.   Here is the process I go through when a mistake is made:

1.  Understand the scope of the mistake; identify all the players involved and their role

2.  What was my role in the mistake?  Even in mistakes that appear clearly someone else’s fault, if they are part of my team then I had a role to play somewhere.  It works the other way too; if I blame myself, who else had a role?

3.   Admit readily to your role and where things went wrong.  Understand what you would do differently

4.  Learn from the experience and move on

By understanding your role in mistakes and admitting to them you take a non-defensive posture and will be less likely to destroy your own credibility and that of your team.  In the end you will be open to learning from your experience, less likely to make the same mistake again and ready to learn from a whole bunch of new mistakes in the future!

What other tips do you have that can make sure the computer gremlins don’t get you?