Bring your own device (BYOD)

October 23, 2012

The 10 Danger Signs of a Failing IT Project – webinar on Oct. 30

Learn the red flags you should watch for in major IT projects.  I’ll share with you insights about identifying and responding to problems in management of IT projects.

Join me in this free one-hour webinar on October 30 at 10 AM Pacific time.

Register here

 

“Bring your own device” (BYOD) is the latest watchword in corporate IT.  For mid-sized companies and organizations, how should we think about mobile Apps?  Are we ready to embrace them?

Back in the good old days (before the iPhone, for example), companies only worried about laptops and their applications, and about lost BlackBerrys.  Applications did not change more than once every 3 to 6 months at the most frequent, so IT departments could spend a fair amount of time vetting the applications before deploying them for use at the office and away from the office.

Now, everyone has a smartphone and everyone wants to use one for access to the company’s databases.  This opens up a lot of security and usability issues.  Here are some of them:

Security – Can unauthorized people get access to the databases?

Portability – Will access from a smartphone compromise the effectiveness of the data because input is less reliable?

Accessibility – Will access from a smartphone make it difficult for the user to read or use the information?

Now that the Apps are in a small portable device, we have to worry about both old and new threats to security:

Spam – unwanted messages coming into our network

Phishing – malware injected into portable devices and crooks getting access to valuable data or login information

Data leaks – loss of valuable data by accident

Lost devices –  loss of the mobile device itself, together with its data and login information

Should I try to control the Apps?  The answer is yes and no.  Yes, make sure that you thoroughly test Apps that are to be used to access corporate data.   And no, don’t prevent people from downloading what works for them.  If and when you run into problems with a particular App, you can always ban its use.  Of course, this means that you should monitor which Apps are being used.

How can I avoid disaster?  Here are a few general principles:

Develop a list of trusted partners & suppliers for mobile Apps.  Also develop an in-house capability for testing and verification of operation (and problems).

Also develop a program of training for everyone who uses a mobile device for accessing corporate databases.  Make sure they understand the company policies about access and sharing of data.

Perform regular review of security policies and procedures.  The policies don’t have to be extensive, but they should be clear and enforceable.  Don’t try to enforce policies related to activities that you can’t monitor.

When introducing new capabilities, start by rolling out a new App on a small group first.  Monitor the new App more closely than you do for mature Apps, and make quick corrections when there are problems.

We are at the beginning of the mobile device era. PCs will have less and less influence on the future of IT interactions, while mobile devices will have more and more influence.  There is no way to stem this tide, so you may as well embrace the mobile devices and their Apps.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , ,

When you need IT advice

September 25, 2012

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

 

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , , ,

Eliminate your IT department?

September 10, 2012

Cloud-based services are transforming business IT in major ways.  What does this mean for the structure and mission of the enterprise’s IT department?  Is there anything left that can’t be done by the cloud and by cloud service vendors?

Yes!  There are three major areas in which every enterprise still needs a collection of people who focus on IT.  And it is best to have them gathered in a department where they are able to exchange information at high bandwidth – in other words, in an IT department.

1.    Expertise

While it can be advantageous to place IT specialists inside of business departments where they can advise their business counterparts on specifics of applications, data and cloud services, keeping up with the range of IT offerings is a job best done at a central location.

Building a center of expertise will enable IT specialists to respond to requests from business units for recommendations and advice on cloud vendors, facilities and functions of various IT packages, and general information on what solutions are now available.  In addition, the experts can create informative newsletters and workshops on what’s around the corner, the progress of corporate IT initiatives, and other current IT topics.

This type of dissemination of information cannot typically be done as well by department-captive IT specialists.

2.    Strategy

Your business has a business strategy.  Almost certainly, that strategy depends on certain IT initiatives.  Defining, aligning, and guiding those initiatives must be done by people who understand the business strategy and also understand IT deeply.  These people should be IT experts who also are involved in strategic planning for the business.

As a result, they are strategists for IT as well as for the business.  So they need to keep up with the latest trends and possibilities in IT as well as know a lot about all of the enterprise’s current IT implementations.  These people are natural members of a central IT department.

3.    Management

IT management involves several different perspectives.

First is managing the IT-business interface across all IT initiatives and across the functional components of the business.

Second is managing the IT department and its initiatives, including developing, training and promoting IT specialists.

Finally, there is management of vendors, including cloud service vendors – and increasingly crucial portion of the management workload.

All three of these aspects of IT require an IT department – or an equivalent – that concentrates IT expertise and IT-related missions into a place where communications are very frequent and easy.

Don’t eliminate IT, transform it

As cloud-based services begin to transform the way in which IT functions are accomplished, the IT department should concentrate on developing its expertise in the following areas:

Cross-connecting siloed business functions and helping to eliminate duplication in IT activities and services.

Teaching, training and informing business leaders about IT, including which cloud-based services can best help get their jobs done.

Monitoring, measuring and rewarding vendors who are supporting business functions in the enterprise.  This includes setting standards for performance, helping with contractual arrangements with vendors, and monitoring both positive performance and negative incidents surrounding IT vendors.

Creating IT strategic plans, including corroborating those plans with enterprise strategies and plans.  And finally, adapting the enterprise to the rapidly-shifting cloud services environment.

In other words, there’s plenty left to do in an IT department.  Don’t eliminate it.

John’s webinar titled will be held on September 25 at 10:00 AM Pacific time.

Designing, implementing and integrating major IT systems has numerous pitfalls that don’t appear, for example, in building construction. If you’re responsible for delivering a major IT project – or if you are paying for one – you need to be aware of what indicators are red flags for possible failure of the project.

See more information and register at 

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

Deliver the promise of technology to business


https://johnlevyconsulting.com

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

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , ,

Why isn’t software more secure?

August 13, 2012

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

Filed Under: Painless IT Tagged With: , , , , , , , , , , , , , ,

How to generate team energy

July 23, 2012

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.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , ,

Is your software stable or static?

July 10, 2012

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. 

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,