When you need IT advice

When you ask for advice from an IT specialist, often the response is too technical, too closely tied to a commercial product, or simply off the mark because the underlying problems are management problems.  Who can you turn to for useful and practical advice?

What kind of technology advice do you need?

As a manager or executive you may have a variety of questions about “technology.”  Here is one way to classify those questions:

1. Pure technical analysis – what’s possible, what does it cost?

You already have a clear idea of the functions or capabilities you need.  But now you need to know what technologies can be used to get those functions, and what they are likely to cost.   An IT specialist with experience in building those functions can elaborate the technologies and give you a roadmap for building what you want.

If the specialist also has enough experience, you can get a fairly accurate estimate of how much it will cost – if things go well.  But always be prepared for bumps in the road.  Many time, due to evolving technologies, unforeseen glitches due to incompatibilities, and changing requirements, the costs will go up – even as much as doubling the initial estimates.

The best countermeasure to escalating costs is to define incremental delivery of the features.  Ask for demonstrations and delivery of working systems every few months, so that you can personally verify that things are on track – and that you’re getting what you want.

 

2. Help in selecting between competing alternatives – evaluating vendors and their products/services

When the times comes to select a vendor or to choose a team for building the capabilities you want, ask for help from someone who has done it before.  In other words, make sure the advice you get is from someone experienced in the particular functions and capabilities you’re asking for.

Be sure that your advisor is not “married” to a particular vendor.  Of course, this eliminates the sales representatives of the vendors from being the advice-givers you need.  Even your own IT staff may have prejudices based on their own history and experience with particular vendors’ products.  You may want to find a consultant who knows the field and can give you accurate information without being involved in the sale of a product.

Evaluating vendors also includes business aspects.  You need to know that the vendor will survive to support the product, has the infrastructure needed to provide what you need, and is willing to commit to meeting your service standards, whatever they may be.

 

3. Guidance in managing the implementation of new IT services

Once you’ve committed to implement a new capability, you form a team to carry out the project.  At this point, you may need help in assuring success of the project.

Projects fail all too often.  Most failures are due to one of the following:

•  Inadequate planning and scoping of the project

•  Unrealistic expectations about what can be done in what time

•  Unadequate management structures for coordinating the project

•  Unforeseen complexity and rapid change in the requirements

Hiring an experienced management consultant can insure you against project failure for a small fraction of the project cost.  You’ll want to find someone who speaks in business terms, has management experience, and knows technology well.

This third area — managing implementation — is the area in which I work.  I’ll be glad to offer you a free strategy session in which we examine your project and your plans in an initial consultation, to see if I can help raise your confidence that your project will succeed.  Simply contact me by any of the methods below.

 

SUBSCRIBE FREE: https://johnlevyconsulting.com/blog

Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”

 

John Levy Consulting                                415 663-1818

Deliver the promise of technology to business

https://johnlevyconsulting.com

PO Box 1419                  Point Reyes Station, CA 94956

 

What’s different about mobile apps?

The adoption of smart phones across a wide cross-section of the world has opened up a new arena for business application software: mobility.  This article outlines what’s different about mobile “apps” – and what remains the same as desktop PC software.

Small screen

In the world of media (such as movies), the big screen is in a movie theater, the small screen is a television set, the smaller screen is on a PC, now the tiny screen is on your mobile phone.  While you may be able to watch a movie on a mobile phone, you can’t expect to interact with business software the same way on this tiny screen as you do on a PC.

On the other hand, you’re not always sitting in front of your PC.  But your mobile phone is nearly always at hand, so this makes it attractive as an “always on” device that you can use for interacting with your business.

Since the introduction of the Apple iPhone, the underlying operating system software of the smartphone has had nearly all of the capabilities of a PC operating system, with one exception:  only one app can run at a time (up to now).

Aren’t mobile apps and PC applications the same?

Some characteristics of apps are the same as for PC.  For example, apps must be developed to match the specific operating system found in the smartphone.  This means that a iPhone app has to be deliberately designed for the Apple IOS system, an app for a Samsung phone has to be designed for the Android system, and so on for Nokia and Blackberry apps.

The people who develop apps have to use a development environment (a bunch of software tools) specific to the target OS, or else use an environment that is “cross-platform,”  so that their resulting app is adapted to the target OS.  There are many of these cross-platform tools.  If you’re interested in them, see http://en.wikipedia.org/wiki/Mobile_application_development .

Other restrictions

Each target operating system may have other restrictions, such as the requirement that all apps for the iPhone be reviewed and approved by Apple.  This makes the job of the developer harder if he is trying to make an app that runs on any phone.

A mobile app is software that runs on the phone and uses the underlying operating system to perform certain functions, such as interacting with the user and communicating with a website or the telephone system.  Some of the functions available in a smartphone are unique to the mobile environment, such as being able to find out where the phone is right now from the GPS.

Browser-based interactions

Just as with a PC-based user, one way to implement business functions is to use a browser to access a server offering the functions.  In fact, a server can implement both PC and mobile versions of its user interface in order to offer the same – or nearly the same – features to both PC-based and smartphone-based users.

One of the current developments in browsers is the HTML5 language, which allows a single software package to offer adaptable results that can make mobile/PC apps easier to move around to different phones and/or PCs.

Of course the designer of the user interaction has to be aware of the size of the screen.

What about security?

Whether an app is PC based or smartphone based, security is still an issue.  And moving the functions into a browser-based app in a server does not take care of all the security issues, either.  We’ll take up the question of security in a future blog entry.

 

For more information about app development, here’s a link to one of the commercial companies that do mobile application development.

Why isn’t software more secure?

What makes software insecure?

Software is often insecure because it is complex, abstract and not completely understood even by the people who create it.  A software specialist who designs a human interaction module may not know much about the database software that the module depends on, for example.

In addition, software runs in a hardware environment (the computer system) that is not completely known by the creator of the software.  For example, when a software package is designed to run in a Microsoft Windows system, the hardware may have been manufactured by any of a dozen companies, each of which has its own detailed hardware environment (including things like BIOS, memory, storage, and input/output subsystems).

And the software itself has to keep changing to keep up with user expectations.  Software that doesn’t get updated gets stale.  [See more about this in my previous blog: stable or static]:

What vulnerabilities are there in software?

Software is vulnerable to many possible conditions that it may not be prepared for.  For example, unexpected inputs can lead to errors: if the software is expecting a number and it gets a value that is outside of reasonable bounds, it may have unpredictable consequences.

In addition, computer hardware can have exception conditions occur during instruction execution, such as dividing by zero.  These exceptions must be anticipated by the software, or else the program can simply terminate without finishing its work.

For example, one of the popular ways for hackers to break into computer systems is to create a “buffer overflow condition.”  If the software does not anticipate this condition, the computer can execute code that the hacker put into a data structure in advance, causing the computer to come under the control of the hacker.

Why are they always discovering new holes & vulnerabilities in our software and systems?  Doesn’t testing take care of these problems?

Proper testing can reduce insecurities and other bugs.  Often, software development organizations simply don’t use the best tools for testing.  But testing every possible case is impossible.  Testing has to be done using human judgment to decide the testing strategy.

[For an excellent exposition on this subject, see Gerald Weinberg’s book, Perfect Software]

Often the failure to do adequate testing is the fault of management.  When a software development project is behind schedule, the temptation to short-change the testing is very high, because testing is usually tacked on to the end of the development cycle.

[For more on this, see my previous blog: good software]

How else is software insecure?

Most software does not run in a vacuum.  Often it is interacting with a human operator.  When a program and a human are interacting, there are plenty of opportunities for misunderstandings.  For example, error messages may be confusing, or the human may take the wrong action in response to a warning message.

The people who make it their business to take advantage of software vulnerabilities – call them hackers or attackers – are becoming more sophisticated.  They may be after money or industrial secrets, and they often know a lot about the system and the person who is interacting with the system.

A whole class of attack, called spear-phishing, is based on deliberately showing misleading information to the human, such as an email that appears to come from the person’s boss.  Vulnerability to these attacks occurs both in the system (email delivery without validation) and in the person (accepting what appears at face value).

What’s an enterprise to do about insecure software?

As a first step, make sure that you have engaged security specialists – people who have studied and are expert in attacks and in security countermeasures.  The specialists should include “white hat” testers – people who deliberately try to break into your own systems in order to demonstrate vulnerabilities.

You should also ask questions of your project managers about tradeoffs being made between testing and quality.   You must recognize that when you choose to emphasize schedule, you often invite lower quality and therefore higher vulnerability.

Never assume that software is of high quality – and therefore invulnerable – until you have seen it demonstrated in actual use by real users.  And even then, expect to find vulnerabilities regularly, and be ready to fix them.

 

TO SUBSCRIBE FREE: https://johnlevyconsulting.com/blog

Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”

John Levy — Turn Around IT
      Helping business get full value from IT

https://johnlevyconsulting.com

PO Box 1419, Point Reyes Station, CA 94956    415 663-1818

How to generate team energy

If you lead, manage or work with teams, you know that teams have their highs and lows, just like individuals.  Energy is a quality of the interactions going on in the room the team is working in, a quality that you feel when you’re in the room with them. The energy of a team is a key indicator of how well the team is functioning.  Here are things you can do as a leader to generate positive energy.

There are a variety of types of energy.  A team may have intensity caused by anger or by competitiveness; or it may have high enthusiasm expressed by outbursts of joking and fun.  There may be quiet most of the time, interspersed with interactions that express appreciation or admiration (the wow! factor).   Or there can be a sullen tone in a team that resents its mission or its management.  Sometimes, a team pulls itself together and generates camaraderie because it is facing a common enemy – often represented by its management.

The energy of a team is a good predictor of its effectiveness.  The best teams have at least occasional bursts of intensity, and they maintain respectful, if joking, relations with each other.

As leader of teams, part of your mission is to sense the energy of the team and to intervene when things are not going well.  Unhealthy interactions are an early predictor of decay in a team.  You should be ready to make necessary adjustments when you see things unraveling.

Here are two things you can do to keep team energy positive:

1. Embrace & appreciate diversity.

Most teams we work with have people from diverse backgrounds.  Rather than cover over the differences in culture and style among the team members, call upon those differences in an appreciative way.  For example, if one of the team members comes from a culture, such as Japan, the Philippines or Thailand, in which harmony is the supreme value, ask that person review the team’s interaction ground rules.  While many Americans relish confrontation and argument, others may prefer that the ground rules keep them from having to argue in a contentious way.

You should encourage everyone on the team to call on members who typically have different views to get feedback about a proposed technique, method or solution.  In this way you help the team to revel in diversity and appreciate their differences, rather than viewing differences as being in the way.

2. Hear all the voices, trust the team

A few years ago, I was facilitating a team of business and IT specialists who were working to overcome their history of finger-pointing and frustration with each other.  We had a dozen people in the room, and they quickly took to the task of listing what was working, what was not working, and prioritizing the actions to fix their dysfunction.  As the process entered the second full day, I noticed that one person had not yet said anything during the group work.  I began to wonder why the leaders had included this person.

Normally I would go out of my way to be sure that everyone’s voice is heard, no matter how briefly.  However, in this case I let the process continue without intervening.  Several hours into problem-solving, the team was looking for ideas to deal with how to communicate certain technical details between their offices, 750 miles apart.  Suddenly, the previously quiet person spoke up with a proposal.  The suggestion was brilliant, and the team quickly adopted it.  The lesson for me was to trust the team and the process – the leaders knew this person had something to contribute, and they knew he would speak up when he had something to say.

You have a responsibility to guide the energy of the team.  You can do this in a positive way by doing these things:

a.     Create a common space – common ground – where the team can interact informally, even if they do not inhabit a common room when they’re working.  This is where they can trade stories, post items of interest on the walls, and find out what’s going on with the team.  Put key information there, but leave a lot of room for their own preferred items.

b.    Set the tone for the team by being a good listener, appreciating the work of each individual, and providing honest feedback about what you observe.  Don’t indulge in disrespectful humor or gossip.  And keep your own energy up, so that you don’t need to draw energy from the team.

c.     Get out of the way.  Most of the team interactions don’t need your guidance.  Check in with what’s happening at various moments through the day or week, but don’t try to guide everything.  If you give your team permission to try out and adopt processes that aren’t necessarily pre-defined, they’ll generate their own enthusiasm and will often surprise you with their creativity.

Is your software stable or static?

In most professions, it’s good to have stability in the things you work with.  With software, stability is good, but often we confuse static with stable.  They are not the same.

Static software decays and becomes useless.

In a previous article, Why does it cost so much to maintain systems? I explained how software updates are critical to keep it alive:

Software by its nature is constantly evolving.  Not only do users ask for new and modified features, but the systems on which the software runs keep changing, so the software has to be modified to fit new environments.  These factors guarantee that updates have to be released several times a year to keep things current.

Here are some indicators that software is stable:

• Updates are regular but not urgent

• The list of bug fixes in each release is not excessively long

• You don’t experience crashes & freezes on the system

• The software “plays well with others” – there are no negative interactions with other software packages

• It scales up smoothly – there are no abrupt limits as the data size or workload increases, only a gradual slowing of response time

• The vendor’s support is consistently accessible and useful

On the other hand, static software is an entirely different thing.  If software is static it means that there are no updates, changes or evolutionary steps being taken to keep the software current.  As a result, some or all of the following will happen:

• The software will not run in new environments, such as latest release of the operating system

• The files being used with the software do not evolve with changing data formats, file systems and storage media.  Compatibility is lost with other software that begin using new data and file formats.  Old backup copies of data may not be readable on new storage devices.

• The software will not communicate using new network interfaces.  When it does communicate, it may be using old protocols that slow down the speed of transfers and do not use new features available in the network.

• The software may not be able to interact with cloud-based applications and databases that have been added since the software was released.

Stable software requires constant attention by the people who are maintaining it.  They should be in regular dialogue with the users of the software, have a list of issues they are investigating and correcting, and be using a set of maintenance tools that allow consistent and stable releases.

Strive to have stable, but not static software. 

Why is it so hard to get good software?

Once we get over our wonder at the broad capabilities of software running on modern computers and devices, we begin to ask why so much of the software we use is of questionable quality.  Between vulnerabilities to malware and constant updates to correct problems, it seems that software is never stable and reliable.  Why?

Software is abstract, invisible and runs at very high speed.  This combination of features makes developing software the domain of a special kind of person who can deal with the abstractions and with the incredibly fine detail of software creation.  Managing a group of such people also requires a special kind of talent as well, because there are tradeoffs to be made between getting new features added and stabilizing the functions that are already built-in.

Usually, the pressures of commercial software development lead software marketers to place much more emphasis on new features than on stability, because features are what differentiate one software product from another.  However, the long-term stability of a product also contributes a lot to the product’s reputation.

Software testing is the usual way to verify proper functioning before shipment.  But since software development routinely takes longer than anticipated, it is the testing that gets short shrift in many cases.  The result is premature delivery of software that is not yet ready for commercial use.

A 2002 study commissioned by the National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually. The same study found that more than a third of that cost — about $22.2 billion — could be eliminated by improving testing.     http://on.msnbc.com/Kae58w

In addition, the operating context of software is constantly changing.  As operating system upgrades are released, the software that works under that operating system often must be adapted to the upgrades.  This means that a lot of the work of keeping a software package current goes to merely maintain the capabilities that were already built.

Users continue to ask for new features.  And marketers want the software to be useful in more contexts – such as making an app useful on an Android phone in addition to an iPhone.  These demands guarantee that a software package will always have an endless backlog of potential changes in the “to-do” list.

As more contexts are supported and more features are added, the software inevitably becomes more complex.  And complexity multiplies the difficulty of testing, and also makes each change to the software riskier.  The more interactions that are possible with each part of the code, the more possibilities there are for mistakes.

What can I do to help make software better?

Purchasers of software don’t have very high expectations, because the track record of the software industry does not set a very high bar.  If users demanded better software and rejected poor software, software vendors would provide better packages – or go out of business.  Why don’t we demand better software?

One reason is that it is hard to switch.  Once we have adopted a piece of software for some function, we tend to stay with it.  First of all, it’s what we are familiar with.  This “makes us rather bear those ills we have than fly to others that we know not of.” [Shakespeare – Hamlet]  The cost of learning a new system is high, and we tend to stay with what is familiar, even if it is painful to use.

Second, the vendors of software don’t often make it easy for us to switch to another vendor.  Try taking an Access database and “porting” it to FileMaker Pro.  The conversion process is a barrier that most of us are unwilling to undertake.  In addition, there may be many people who need to be trained in the new system if we switch.  That adds to the cost.

In the future, we should look at the cost of switching before committing to a software vendor or cloud system.  The more “open” the system, the better for us in the long term.

And we should always insist on demonstrably high quality in software.  Keep this in mind the next time you’re making a purchase decision.