mardi 30 octobre 2012

The Top 5 Project Deliverables

A lire sur:  Method 123

Every project is different and this is especially true when you cross industry lines. A Construction project is going to be substantially different than an IT project and a Marketing project will have little in common with a Training project. However, there are similarities that transcend all project types. These are the:
The Top 5 Project Deliverables
The five deliverables outlined below must be present in any project that is undertaken in order for it to be successful.
Deliverable 1 - The Work Breakdown Structure
The Work Breakdown Structure or WBS is a critical project deliverable for any project that is being managed. The WBS details the scope of the entire project and answers the question "what are we building here". The top-down, hierarchical nature of the WBS is an excellent tool that ensures nothing is missed in the planning process. It can be compared to starting with an entire picture of something and then turning it into a puzzle with it's component pieces.
Once the WBS is created it is useful for planning, communicating, and tracking the progress of your project. The WBS allows you to assign durations and resources for each task that comprises your project. This is then used as the basis for communicating what needs to be done to the team as well as monitoring and tracking the progress of your project.
Deliverable 2 - The Project Charter The project charter is another critical project deliverable that transcends industries. The biggest value a project charter provides is that it ultimately serves as the green light that a project needs in order to get started. Along with this green light approval it bestows upon the project manager the authority and approved budget necessary to bring the project to completion.
The project charter also serves as a reference for project vision, objectives, scope, deliverables, known risks, issues and assumptions. This project deliverable will not include the high level of detail that will be generated in other project documents later, but it will provide enough information to give project stakeholders a 30,000 foot overview of what this project will accomplish and a general direction of how it will be done.
Deliverable 3 - The Project Schedule
The project schedule is the third deliverable that can be used across multiple industries. This is the document that breaks down what needs to be built into tasks, dependencies, timelines, and resource assignments. The project schedule is where the rubber meets the road because it drives the implementation, execution, and control of the project that is underway.
One point of clarification when it comes to the project schedule. You may frequently hear people say "we need a project plan to make sure we meet our dates". That is a true statement. However, a project plan is much more than just the project schedule. The project plan includes every project document such as a communications plan, risk management plan, procurement plan, and resource plan to name a few. The project schedule is a component of the project plan. You may want to receive clarification from the requestor to ensure you understand their definition of a project plan as compared to a project schedule.
Deliverable 4 - Escalation Plan
Something else that transcends all industries are obstacles that get thrown in the way of a project. These obstacles can include technical difficulties, resource issues, and a host of problems in between. It is the savvy project manager that will anticipate the fact that obstacles will present themselves and have a plan in place for their resolution.
This project deliverable doesn't have to be very long nor complicated. It essentially states that when certain conditions exists (such as a task being a certain percentage behind in the schedule) then these are the people that will be notified for assistance. The people that are on the escalation path need to have enough influence and authority that they can do something about the problem. This may include anything from throwing more resources at the problem to notifying the customer that the timeline may need to be extended.
Deliverable 5 - Lessons Learned
Last but not least is the lessons learned document. It's important to take a moment and reflect on what went right, what went wrong, and what can be done better on the next project. You will find that even if you move from one industry to the next, there are many lessons that were uncovered in one that can be applied to the next.
Unfortunately, this project deliverable is one that is often overlooked or neglected. The value that is derived from this deliverable is immeasurable. Take the time to reflect on your project and the time you save on future projects will dwarf this small investment.
The top 5 project deliverables above will allow you to scope, authorize, direct, clear the way, and reflect on your projects regardless of your industry.

lundi 29 octobre 2012

10 ways for IT to survive a merger

A lire sur:

Takeaway: Consolidating staff and system platforms during a merger is a highly charged and complex undertaking — and IT is right in the thick of it. Here’s what you should know going in.
Mergers are a fact of corporate life. They also require IT to play a major role because different systems must be consolidated. The work IT performs in mergers is so mission-critical that if it’s determined that systems can’t be readily consolidated and made to work together, the merger might be called off. Needless to say, performing IT work for a merger is risky — not only technically but politically. Here are 10 things to think about if you are tasked with IT for a merger.

1: Understand what is at stake

Mergers aren’t just “clinical” projects that convert systems so they work together. For IT and throughout the organizations involved, mergers mean that some jobs are likely to be consolidated as well. Some IT staffers are going to keep their jobs, while others might not. The IT staff also has technical allegiance to systems it’s familiar with. So if a favored system is designated for termination, there can be fear and bitterness because that also potentially eliminates a particular technical skill set.
Finally, there is the IT consolidation project itself. System merger work is major. Often, the systems that have to be converted are scantly documented, and the people who know about them aren’t overly helpful. The more you understand about this complex of conditions going into the project, the better you’ll be able to weather the pressures and the conflicts that are likely to arise.

2: Consider sabotage in your risk management strategy

Once I was tasked with a major system consolidation project for two behemoth companies that were merging. The “victim” company whose systems were going away had IT staffers who were uncooperative and withheld vital information needed to safely convert their existing system to the new system platform. It was a subtle form of non-cooperation, so there wasn’t really a way to call this “sabotage” out loud — but it was indeed a kind of sabotage of the low-grade variety.
Getting the situation under control extended the project timeline several months. It took numerous conversations with executives and managers in both organizations to convince them why a project extension was necessary. I also communicated regularly about the inherent risks of converting “black box” software routines without documentation. We factored in extra testing time to ensure that the converted software worked in every imaginable situation. This slowed the project down, but at least we didn’t have a disaster!

3: Know when it is ill-advised to convert a system

Sometimes, organizations wish to merge, but their systems are so incompatible that it doesn’t make sense to consolidate them. In these situations, CIOs take a longer view. They allow both companies to continue to function with their existing systems, and they identify a third “long-term destination system” that everyone will ultimately be on. If new organizations come on board and don’t have a previous history established with the unworkable systems, they are often placed on the final target system from the start. This at least pares down the future conversion effort.

4: Communicate

Even If project news is bad, give it to the people straight and as quickly as you can. I’ve known project managers who became so nervous at having to deliver bad news, they just wouldn’t. Consequently, small problems festered until they were nearly insurmountable. Seasoned business executives understand how difficult system consolidations are, so they expect to hear some bad with the good.

5: Lay out your go-forward staffing as soon as possible

If some staffers are going to lose their positions because of the merger, work hard to negotiate decent settlements and employment assistance for them. It’s the right thing to do — and it sends a message to remaining staff that management is taking the high road. For remaining staff, communicate as rapidly as you can what their individual roles are going to be and what the new IT organization is going to look like. This relieves anxiety and allows staffers to focus on the job at hand.

6: Manage by walking around

We’ve all heard “manage by walking around” so often that it has become trite. But the actual practice never goes out of style. Mergers mean change, even to those who get promotions because of them. By walking around, you can visit person to person with staff, see how they are doing, and observe body language. This puts you in a position to see whether staffers are comfortable or need to be reassured. The system consolidations brought about by mergers are always emotional projects. Make it your job to watch the people side of the project as closely as you watch the progress of the work itself.

7: Develop a vendor strategy

Vendors don’t like to lose accounts. So if a vendor’s system is designated for de-implementation as a consequence of the merger, beware. You might find that the vendor is unusually slow to respond to requests for de-conversion programs, data, and documentation — or slow to respond if you run into a problem while de-converting. This is an important area to check out while you are still analyzing the system merger project. The vendor contract should be reviewed to see what the conditions for a de-conversion are — or whether there are any provisions at all. You should assess the level of risk from vendor non-cooperation and convey this to other top-level managers so everyone has up-front awareness of the issue.

8: Have a fallback plan

Once you’ve performed all your testing and you’re ready to cut over to the consolidated system platform, make sure that you have a “way back” for failover in case something unforeseen happens. It never hurts to have a plan B — and your auditors will love you for it.

9: Provide visibility

It’s impossible to overdo visibility in a project with so many complications and sensitivities. Whether the system consolidation project is running smoothly or whether it’s in the rough, let key stakeholders know present status and what you’re going to do next. Projects are never perfect. But for most stakeholders, half of every project’s success is feeling that they’re in control.

10: Don’t cut over to production until you are ready

I’ve seen project managers get so pressured by their bosses to cut over to production that they proceeded even though they knew the system wasn’t ready. What these project managers invariably discover is that they’re in an even bigger mess than the one they would have been in if they had stood their ground and said the project wasn’t ready to go yet. If your boss overrides you, there isn’t much you can do. But you owe it to your boss and to yourself to speak up and say that the project requires more time if you think that is the situation.

Other advice?

What other suggestions do you have for handling the technical and political issues surrounding a merger? Have you been involved in a relatively smooth one — or seen the wheels come off as the merger progressed?

dimanche 28 octobre 2012

Les DSI affrontent une utilisation sauvage des technologies grand public

A lire sur:

Vendredi 26 octobre 2012
La troisième étude annuelle d’Unisys sur la consumérisation de l’IT, menée dans neuf pays par Forrester Consulting, montre que 88% de la mobile elite hyper-connectée française utilisent ses propres applications au travail, tandis que 84% des employeurs le voient comme une source potentielle future de conflit juridique. Le fossé semble de plus en plus important entre les salariés mobiles connectés à internet (iWorkers), de plus en plus nombreux, et les départements IT qui les assistent au sein de leurs entreprises. Le groupe restreint d’employés appartenant à la mobile elite exploite intensivement plusieurs appareils personnels et applications grand public pour répondre aux besoins de leurs activités et apporte de nombreuses innovations et changements à leur entreprise. Tout en générant par la même occasion de nouveaux défis de sécurité et d’assistance pour leurs départements IT. La DSI et ce groupe, qui représentent 22% des iWorkers français, présentent généralement des opinions divergentes sur l’utilisation  de la technologie grand public.

Cette étude annuelle s’appuie sur les réponses apportées à deux enquêtes différentes menées dans neuf pays, dont la France. Au travers de la  première enquête, 2 600 employés dits  iWorkersont été interrogés sur leur lieu de travail pour mesurer leur utilisation de technologies grand public dans un cadre professionnel. La deuxième enquête a été menée auprès de 590 dirigeants et responsables DSI afin de mieux comprendre leur point de vue et leur façon de traiter de telles technologies. En France 315 iWorkers et 67 responsables métier et IT ont été interrogés.

Après avoir étudié les comportements de ces individus, l’étude souligne que la mobile elite a plutôt tendance à utiliser des technologies grand public pour travailler et échanger avec ses clients afin d’être innovante, plus efficace et plus productive. Ainsi 65% de cette catégorie française affirme être plus productive et efficace grâce à l’utilisation d’appareils et d’applications personnels, contre 42% de l’ensemble des iWorkers. En outre, 46% affirment que l’utilisation d’appareils et d’applications personnels facilite la résolution de problèmes liés à son travail, contre 33% de l’ensemble des iWorkers. Enfin 48% achètent sur ses propres deniers des technologies grand public pour son travail, contre 19% de l’ensemble des iWorkers.
L’enquête montre également que la tendance du Bring Your Own (BYO) dépasse aujourd’hui la simple utilisation d’appareils personnels au travail et évolue vers le Bring Your Own Application (BYOA). Les employés sont de plus en plus nombreux à utiliser des applications qu’ils ont acquises eux-mêmes et/ou des applications grand public. L’enquête révèle aussi un écart entre l’utilisation que font les employés de technologies grand public et la façon dont les DSI perçoivent cette utilisation dans le cadre professionnel : si 66% des employés interrogés en France affirment utiliser des appareils et applications personnels car ils en ont besoin pour leur travail et que leur entreprise ne leur propose aucune solution alternative, seulement 25% des DSI pensent que ces appareils et applications sont essentiels pour le travail de leurs employés.
En cherchant à améliorer sa productivité par le contournement des règles de sécurité et des chartes de bonne conduite internes, la mobile elite pourrait générer de nouveaux risques en matière de sécurité, d’assistance et d’encadrement au sein de leurs entreprises. L’enquête révèle que certaines DSI ne sont pas préparées à faire immédiatement face aux risques générés par leurs employés, mais qu’elles considèrent comme une priorité l’adoption de nouvelles mesures de sécurité dans les douze prochains mois.

jeudi 25 octobre 2012

Checklist for Determining Enterprise Readiness to Support Employee-Owned Devices

A lire sur:

18 June 2012 ID:G00234127
Analyst(s): Andy Rowsell-Jones, Nick Jones


"Bring your own device" is proving popular with businesses in most regions around the globe, with all the attendant device management, data security and cost control issues that brings. This research provides a high-level checklist to use when implementing a BYOD program.


Key Findings

  • Bring your own device (BYOD) is an increasingly common phenomenon. It is opening up the potential of productivity gains, serving as a stimulus for employee satisfaction and seeding innovation, while exposing the enterprise to data and device management risks.
  • There are several strategies for enterprise IT with respect to BYOD, ranging from laissez-faire to lockdown. However, the most effective strategy has enterprise IT taking the lead by segmenting employees into groups, and providing access and appropriate support for each.
  • BYOD implementations can be complex for enterprise IT, with many moving parts. Therefore, there is value in leveraging the lessons from other implementers.


  • For enterprise IT, a BYOD program has multiple phases and touches multiple stakeholders. Use the structured approach to planning, piloting, executing and reviewing in this research as a checklist for your BYOD plans.

Table of Contents




Enterprise IT is in transition again. Use of employee-owned devices in a work context is an organically emerging trend in a wide range of enterprises. The challenge for enterprise IT is to manage this transition to BYOD without exposing the enterprise to unnecessary device management, data security and cost control risks, and without stifling the innovation these devices may herald.
This research provides a high-level checklist (see Table 1) to use when implementing a BYOD program. Each step is discussed in greater detail later.
Table 1. A High-Level Checklist for Implementing BYOD
Key Deliverable
Deciding on a BYOD Strategy
Determination of Which Approach to Adopt to BYOD
Conduct a high-level BYOD issue review to scan for showstoppers.
Initial list of roadblocks and issues that may shape your response to BYOD
Justify the program and define the goals.
Evidence and goals for sponsor and stakeholders
Define the scope and identify the sponsor.
Charter for BYOD program, definition of goals, and identity of sponsors
Identify stakeholders and solicit input.
List of stakeholders and the issues/concerns that impact them
Grouping Employees, and Defining Support and Access for Each
Segmentation of Employees Into Three to Six Groups, and a Package of Policies and Technologies for Each
Define employee groups.
Employee roles/needs matrix and a list of applications/services to be supported on BYOD devices
Assess employee information sensitivity for each group.
Roles/needs matrix annotated with the sensitivity of information handled by employee roles
Identify the delivery and security options for apps and services for each group.
List of options to deliver each key app or service onto an employee-owned device, as well as management and security tools
Create scenarios for device/staff/application management regimes for each group.
Possible packages of policies and technologies to address the needs of selected employee roles
Select a scenario for implementation for each group.
Detailed proposal for the selected master scenario
Implementation Planning
Scope of Tools, Network Services and Financing Models
Select the tools and technologies.
List of tools for application delivery, device management, security and virtual desktop.
Define the networking and connectivity strategy.
List of network services/providers, and a technical and financial policy for each supported network type
Define the app management and licensing strategy.
Guidelines and policies for application licensing, management, sourcing and funding
Define/refine financial aspects and create a cost model.
Proposed reimbursement plans, expected networking costs and a total cost of ownership model
Define employee education requirements.
Define education material for proper use and how to access corporate IT assets
Identify eligible employees.
List of employees taking part and line management approval for their participation
Analyze the risks.
Validation against social, business process, financial and data security risks
Project Setup
Staged Approval for BYOD Program
Create a detailed program proposal for stakeholder sign-off.
Detailed program description for stakeholder approval
Educate stakeholders and ensure their sign-off.
Approval from stakeholders and sponsors
Create policies and procedures.
Internal policy documents, procedures, staff BYOD contracts and agreements
Define support processes.
Supported principles, processes and budgets
Obtain external stakeholder deliverables.
External policy documents (such as finance policies and legal wording for contracts)
Create instructional material.
Training materials (such as presentations and webcasts)
Select employees and obtain agreement.
Lists of participants and signed employee agreements
Roll out employee education.
Rollout of education material on proper use and how to connect to corporate IT assets
Proof of Concept
Successful Pilot and Key Lessons
Pilot the program.
Updated program deliverables addressing issues identified in the pilot.
BYOD Rollout Plan
Roll out the program.
Trained employees and related staff (such as support and managers) and replaced devices
Program Renewal
Periodic BYOD Health Check
Monitor and evolve the program.
12- to 18-month review of BYOD employee satisfaction, value and risk, as well as needed corrective actions
Source: Gartner (June 2012)

1. Deciding on a BYOD Strategy

It may seem odd to need a strategy for BYOD. After all, why should enterprise management do anything? Isn't it just a case of sitting back and waiting for employees to bring in their devices, create new business models and improve productivity? Unfortunately not.
The consumerization of IT with mobile devices and their ecosystem of applications — what we are calling BYOD — may have gone into overdrive of late, but IT leaders and their enterprises still need to make a considered trade-off between freedom of employee action, and the costs and risks of supporting these devices. In short, IT leaders need to balance a new set of potential business benefits with a new set of business risks.
One of the first considerations is what the enterprise's broad approach to BYOD should be. Options range from laissez-faire to lockdown:
  1. HR takes the lead: Ban employee-owned devices being brought onto enterprise premises and prevent them from connecting to any enterprise network assets.
  2. HR takes the lead: Allow devices on-premises but offer no access to enterprise network assets.
  3. Enterprise IT takes the lead: Allow devices on-premises but limit the connection for everyone to email, name and address book, and contacts.
  4. Enterprise IT takes the lead: Segment employees, allow the use of BYOD for enterprise business, and provide support in a way that is appropriate for each group (see "Use Managed Diversity to Support Endpoint Devices").
  5. Enterprise IT takes the lead: Segment employees. In addition, offer enterprise-purchased and enterprise-funded mobile devices to some categories of employees.
  6. No one take the lead: Allow employees to do what they like with their own devices.
Most risk-aware enterprises go into their early BYOD initiatives with enterprise IT playing a leadership role. In the rest of this research, we assume that, like most enterprises, the best strategy for you to follow is similar to Option 4.

1.1 Conduct a High-Level BYOD Issue Review to Scan for Showstoppers

Before embarking on a BYOD program led by enterprise IT, it's useful to consider fundamental questions:
  • Is this a high-security environment that precludes BYOD for anything but personal information management (including email, contacts and calendars)?
  • Are there legal or compliance issues that preclude BYOD for anything but personal information management (for example, especially in multinational organizations governed by different legislations, this might include e-discovery, data privacy legislation, employers' requirement to provide necessary equipment for an employee to do his/her job and so on)?
  • Do issues regarding remuneration, audit, taxation, industrial relations, and employee terms and conditions make enterprise-IT-managed BYOD unattractive?
  • Do any management, technology or policy barriers prevent robust, scalable and secure access that isolates enterprise digital assets on BYOD? Do any hardware, software or bandwidth requirements threaten to scuttle BYOD?
  • Do service-level agreement and support constraints — regarding uptime, remote support, availability of applications, and business processes — limit BYOD attractiveness? Does the enterprise need to make loaner devices available to high-value workers? Can the IT organization effectively deal with a mixed support model that would blend direct support, limited support (supported applications on nonsupported platforms), community support and self-support?
  • As a principle, should the enterprise mandate insurance, warranty and maintenance contracts for all employees using noncompany devices? If so, who pays — employees or their business units?
  • As a principle, what will IT pay for — the device, telecom charges and downloaded apps? What will employees and/or their business units pay for?
  • Can employees opt out of the program? What happens if an employee doesn't want BYOD (for example, older employees who prefer simple feature phones to mobile email)? A better option might be for this to be an opt-in program, and to offer an alternative if the employee doesn't want to opt in. This entails the provision of tools to ensure that employees can do their work if they don't want BYOD. In managed diversity, this is a platform-level device (see "Use Managed Diversity to Support Endpoint Devices").
  • How will the current application portfolio be impacted by employee-owned devices (for example, whether existing applications support multiplatforms, such as Microsoft Office for Mac)? Are existing Web-based applications written to run on multiple platforms, or are they written to run on a specific browser?
  • How will future application delivery be impacted by employee-owned devices (for example, whether IT can ensure that devices and contracts are compatible with planned or likely new application versions)? What happens if new applications have substantially greater data needs that exceed an employee's personal contract limits or process needs exceed the processing capacities of the most common BYOD devices?
  • Do software licensing, hardware sourcing or support issues make BYOD unattractive (current software licenses, for example, may not extend to employee-owned devices)? Are required third-party support schemes available for the proposed BYOD scheme?
  • Should limits be placed on any existing vendor relationships to control device choice?
  • Who oversees user behavior? Who will educate users on the data risks of BYOD? These may be subsumed into a broader question: Who, if anyone, monitors social discourse in public media?

1.2 Justify the Program and Define the Goals

Even though, in theory, enterprise management may see the wisdom of funding enterprise IT to play a leadership role in BYOD, when it comes to paying the check, they may change their mind. The challenge initially is that no one has experience running an enterprise-IT-managed BYOD program. In addition, the benefits case may be unclear, because adoption, business use and business value are all evolving along with the devices.
A proven way to avoid this trap is to define the BYOD program's goals and costs at a high level. To fill in the blanks, conduct a high-level strength, weakness, opportunity and threat (SWOT) analysis to identify what confronts the enterprise when employees adopt BYOD. This need not be onerous:
  • Collect evidence about the level of informal BYOD by surveys asking how many employees use personal laptops, tablets or smartphones.
  • Discuss the potential benefits (such as increased innovation, need to allow choice to recruit the best staff and displacement of support costs to employees) with key enthusiastic adopters.
  • Highlight the risks of uncontrolled BYOD (such as data loss and costs).
  • Review the network's capacity and security arrangements, and IT's ability to support employee-owned devices. Armed with the results of the SWOT, it should then be possible to fund a pilot to test out the opportunities and challenges. When conducting this analysis, be mindful that one of the biggest challenges with enterprise-IT-led BYOD is for support. Employees want anything they want and blame IT for anything that goes wrong.
If, on the other hand, the implications for BYOD are better understood, a more traditional business case approach can be used to justify investment. This business case typically features a range of benefits, such as enhanced brand image, improved field and sales effectiveness, potentially reduced cost, employee efficiency gains, employee satisfaction improvements and so on.

1.3 Define the Scope and Identify the Sponsor

BYOD pilots and programs seldom involve the whole organization. Instead, it's generally sensible to choose a small subset of employees — perhaps belonging to a single department — or a few job roles to start with and to roll things out from there.
All process change demands a sponsor, and BYOD is no exception. Ideally, sponsors should come from a business background and be in a position to influence or direct employees participating in the pilot. Many organizations will find they have passionate BYOD supporters among the senior executives who may be candidate sponsors.

1.4 Identify Stakeholders and Solicit Input

Any major BYOD initiative relies on many stakeholders and raises wide-ranging technical, policy, financial and legal questions. These stakeholders should be identified and contacted as appropriate to obtain inputs and opinions that will shape the program. Example stakeholders include insurers (as risks change), HR (for changes to terms of employment or contracts), IT (application delivery and deployment, support), employees and their representatives (such as unions and workers councils), lawyers (to validate contractual changes) regulators and tax authorities, enterprise architects (architecture changes), auditors, and so on.

2. Grouping Employees, and Defining Support and Access for Each

A one-size-fits-all approach to BYOD is suboptimal. Instead, segment employees into three to six groups, and determine which package of policies, mobile device management and network access technologies to adopt to support employees choice of devices for each.

2.1 Define Employee Groups

Diversity of employee needs and the assortment of mobile technologies mean that one-size-fits-all management is not ideal. It means costs are too high, risks are too high or both. Instead, enterprises should segment their employees into three to six groups based on how much mobility and secure access to enterprise data they need. The Gartner managed diversity model takes this approach (see "Use Managed Diversity to Support Endpoint Devices").
To do this, a good starting point is to model employee location and BYOD work style and usage pattern (which may be simplified) and their business requirements. Showing role versus business requirement as a matrix whose rows are the job roles and whose columns are the applications or services that a job role needs when mobile aids analysis (see Table 2). These employee groups should be cognizant of porous boundaries where the definition of an employee may include noncontract, part-time and ecosystem co-workers. (Think R&D communities, nomadic project and construction endeavors, marketing campaigns that attract and coalesce feedback from customers, outsourcing representatives working on internal systems, prospects outside organizational boundaries, and so on.) An intersection is highlighted when a job role needs a particular mobile service. It is also useful to capture the likely employee context for each intersection. For example, determining whether the employee is in the office, in the corporate Wi-Fi cloud or in cellular coverage will help when considering application delivery and networking options.
Table 2. Illustrated Roles Versus Needs Matrix
Mobile Email
Board Papers
Lead Tracking
Document Sharing
Meeting Notes
Sales staff
Sales manager
(Add others)
Source: Gartner (June 2012)
This planning matrix can be used in many ways and provides several key pieces of information required in later steps of this process.

2.2 Assess Employee Information Sensitivity for Each Group

For each job role identified, define the sensitivity of data that the role accesses. This assessment by role is necessary, because some tools (such as mobile email) may be used by staff accessing information of very different sensitivity. A coarse scale will suffice, focusing on an agreed measurement of risk, such as potential financial loss. For example, 0 equals no material loss, and 5 equals high material loss.

2.3 Identify the Delivery and Security Options for Apps and Services for Each Group

To optimize application delivery and architecture across the BYOD program, consider each application or service in the planning matrix, and identify alternative options for how it might be delivered with adequate security in a BYOD context. BYOD commonly triggers changes to application architectures and, in many cases, to application delivery architecture and security.
Common methods of securing applications include:
  • Mobile device management (MDM) tools that can provide application containerization, control access, inventory security levels and generally serve to lock down a device
  • Application delivery tools to isolate business applications from the consumer side of the device
  • The use of thin-client architectures that obviate the need for a device to contain data
Other popular approaches include sandboxing (for example, email systems that separate personal and corporate email).

2.4 Create Scenarios for Device/Staff/Application Management Regimes for Each Group

Now that the groups are in place, it's time to strike the right balance between employee freedom of action with respect to their devices and enterprise control for each. When doing this, bear in mind that BYOD is different. Why would anyone bother with BYOD if his or her machine (particularly if it's personally paid for) ends up weighed down with corporate security and device management software, along with stifling rules and regulations regarding its use and associated costs. BYOD is not the same as employee-purchased corporate device (EPCD).
Usually, there are several equally plausible ways to deliver and secure applications and support that have different costs, benefits and trade-offs (for example, MDM tools, thin clients, sandboxed email, virtual desktops and even not using any tool at all if the decision has been made for a very risky approach).
To determine which combination is best, develop a series of high-level scenarios that feature different approaches to device management, application delivery and application design, and funding and support. Although the scenarios may lack a highly detailed definition of a program, they do contain enough details to enable a rational selection. For example, two simple scenarios might include:
  • Scenario 1 for sales staff and sales managers: Deliver email using a sandboxed solution from Good Technology, develop thin-client HTML interfaces for all applications, and implement a system to allow access to SharePoint for secure document cloud storage. In this scenario, there is no need for MDM, provided SharePoint is configured not to allow offline downloads. Funding will be via a stipend. Although this is OK for services, stipends for devices leave the enterprise on the hook for support. Employees will be liable for networking costs, and the corporate element will be covered by the stipend.
  • Scenario 2 for all staff: Port key applications to native iPad implementations (so they can wrap and secure their own data), implement email using the new iOS 5 mailbox partitioning approach, allow employees to take meeting notes using any tool they want, but secure the device and application data using an MDM tool. Implement a board portal tool for directors only to secure sensitive meeting papers. Funding will be via a stipend. Senior staff will use company-provided cellular contracts to allow for the negotiation of roaming costs. Junior staff will use employee-liable cellular networking funded by the stipend.
These examples illustrate that some job roles may require additional tools or special treatment because of the applications they need or the sensitivity of the data they access. Scenario selection will be driven by many factors, including usability, cost, acceptability to employees and so on.

2.5 Select a Scenario for Implementation for Each Group

In consultation with stakeholders, select plausible scenarios for implementation to support each employee group. Bundle these scenarios to create a master scenario for implementation.

3. Implementation Planning

Determine the scope of tools, network services and financing models.

3.1 Select the Tools and Technologies

Select technologies and vendors to implement the chosen master scenario. Examples include mobile development tools, MDM tools, VPNs, hosted desktop tools, cloud storage and so on.

3.2 Define Networking and Connectivity Strategy

  • Which networking and voice technologies will be used (for example, cellular and Wi-Fi)?
  • Will personal devices be permitted to connect to corporate networks? If so, what controls and restrictions will be applied?
  • How will connectivity be funded — for example, through stipends, through the provision of corporate data accounts, through employees claiming connectivity on expenses or through some other method?
  • How will personal and corporate use of network services on the same device be managed? Some organizations may allow personal calls and data usage on corporate contracts, for example, if they can negotiate flat rate plans. Or, if the employee is liable for the data, contract reimbursement beyond the stipend may be necessary.
  • What mechanism (for example, identity management) will be used to identify the user and control application access (see "Roundup of Identity and Access Management Research, 1Q12")?
  • Are additional supporting technologies or services required (for example, VPNs, network access control systems, network auditing and monitoring systems, or telecom expense management solutions)?

3.3 Define the App Management and Licensing Strategy

BYOD models also pose challenges in application licensing and funding. These include:
  • Licensing existing software products for potential access by many more endpoint devices: This is more complex under BYOD because it includes a mix of personal and corporate devices. Review license agreements and ensure that cost models reflect the true cost to provision (see Section 3.4).
  • Funding essential mobile apps: Do the app store owners offer a bulk licensing arrangement? How will bulk licensing be managed (the options differ between app stores and even countries)? What should you do about apps that are not available for corporate licensing? Establish guidelines for each jurisdiction and ensure that cost models reflect the true cost to provision.
  • Employees expensing the cost of certain apps for personal devices: Expensing apps can be complex. Because most apps are of low value, treat them like any other expense. Establish guidelines by jurisdiction, instruct employees to submit expense claims as usual, and instruct local management to approve the expenses if they are within the guidelines.
  • Apps purchased by employees who then leave the enterprise: If an employee leaves the organization, what happens to the apps and content on his or her personal device that were purchased with corporate funds (many mobile app vendors have no mechanism for transferring licenses on low-cost apps, so the investment may be lost)? Because most apps are of low value, most enterprises are willing to write off these small sums, as they would for employee-purchased books and other small items.
  • Required apps as part of a mobile application management (MAM) solution: Some organizations choose to adopt a MAM solution as part of their BYOD strategy —essentially a minimum set of apps that should be present on all BYOD devices. This may be provided in several ways (for example, by a dedicated corporate app store product or as a feature of an MDM tool).
  • Common app management among multiple platforms: One of the challenges of BYOD is that it is highly likely multiple different devices will be in use from different vendors. Identify the most common devices in use, and create different app stores, different settings for MDM tools, different platforms and different policies for each.
  • Apps purchased from consumer stores that have different and inconsistent licensing terms and conditions: Although this is true, and may well be an issue surfaced by the audit or finance departments when considering the enterprise's BYOD, in practice, few consumer apps represent a real licensing issue. A realistic risk assessment and measured advice (as a policy) on what to do if you are an employee with one of the shortlist of problem apps is appropriate.

3.4 Define/Refine Financial Aspects and Create a Cost Model

The goal of this step is to produce a detailed cost assessment for future approval by stakeholders. At this stage, we know and can cost the technology and processes required for proposed BYOD scenarios. We also know and can address issues such as employee data requirements and stipends. Nevertheless, issues remain that may make BYOD unattractive from a tax perspective. These include:
  • Software licensing: Some license agreements are based on endpoints (device licenses), which may imply substantial additional costs as new endpoints are added (such as employee-owned tablets).
  • Tax implications: There are two broad tax implications of BYOD. There is no ability to write off against tax devices the organization does not own. An employee may also face an increased tax bill if the enterprise provides taxable benefits to employees to fund corporate use of personal devices.

3.5 Define Employee Education Requirements

Although users shouldn't need enterprise IT to tell them how to use the devices, they still require education on acceptable use policies, as well as how to connect to and use corporate information assets and networks.

3.6 Identify Eligible Employees

In many organizations, not all employees, qualify for participation in an enterprise-IT-led BYOD program. Identify groups, and seek line management approval.

3.7 Analyze the Risks

BYOD programs introduce new risks, including financial, security, data loss and employee satisfaction risks. Validate the proposed program from at least four directions:
  • Test against likely scenarios. Examples include lost or stolen devices, failure of key vendors and invalid assumptions (for example, about how much data employees might need).
  • Validate from each of the four (somewhat conflicting) goals of a BYOD program:
    • Social: Will the employees be happy?
    • Operational: Can the process continuity be assured?
    • Financial: How are costs controlled and managed?
    • Risk management: What bad things could happen, and how will they be prevented?
  • Ensure that all key stakeholder issues identified in Section 1.4 have been addressed (particularly any legal issues — for example, whether it is acceptable to wipe an employee's personal device).
  • Consider implications of corporate applications and device usage coexisting with personal applications and device usage.

4. Project Setup

Gain final approval for the proposed BYOD approach. Set up conditions to run the pilot.

4.1 Create a Detailed Program Proposal for Stakeholder Sign-Off

Create a BYOD proposal with sufficient details for stakeholders to approve it. This should follow your usual project proposal format and process.

4.2 Educate Stakeholders and Ensure Their Sign-Off

Submit your BYOD proposal to all the stakeholders identified in Section 1.4 for comment, discussion and ultimate approval. Ensure that all are aware of their responsibilities in a BYOD program (for example, IT staff can't roll out new applications without first understanding whether they might cause employees to exceed personal contract data caps; if employees travel abroad, additional reimbursement procedures may be required if stipend models are inadequate for roaming data charges). Iterate as required.

4.3 Create Policies and Procedures

All device management is a blend of policy and technology. In consultation with legal, audit, HR, insurance groups and so on, extend these to include BYOD-created ones (for example, to define the permissible use of corporate data, to allow e-discovery, to audit devices and to permit wiping personal devices). See "Toolkit: BYOD Mobile Device Policy Template" for a powerful tool to define BYOD policies.
On a related topic, given the rate of evolution of employee-owned devices, specification (which forms part of a BYOD policy) that describes the minimum device features should be issued at least every two years (the practical useful life of a smartphone or tablet). The danger of not doing so is that, if no update is issued, employees may perceive that they can keep their device and enjoy the same level of access and support indefinitely. If this situation occurs, it is highly likely that the device would slip below the specification needed to match the requirement for enterprise applications.

4.4 Define Support Processes

New support principles and processes must be defined. BYOD demands a new tiered approach to support. No organization can afford an open-ended commitment to fix any problem on any device. When a device is unsupported, alternatives include increased use of peer support and social networks, and techniques such as time-boxed support to limit costs (see "Gartner's View on 'Bring Your Own' in Client Computing").

4.5 Obtain External Stakeholder Deliverables

Some deliverables must be created by external stakeholders (for example, changes to reimbursement processes and updates to contracts of employment). Ensure that all the necessary external deliverables are available.

4.6 Create Instructional Material

It's likely that employees participating in a BYOD program will need training in new policies and procedures. Create the necessary material.

4.7 Select Employees and Obtain Agreement

Identify employees who will participate in the program or pilot. Ensure that they understand it and sign any necessary agreements.

4.8 Roll Out Employee Education

Roll out education material on proper use and how to connect to corporate IT assets developed in Section 3.5.

5. Proof of Concept

Conduct a pilot, learn from the results and adjust the implementation as required.

5.1 Pilot the Program

Typically, organizations run a pilot involving a limited number of users and/or device types before fully deploying their BYOD program.

6. Implementation

Roll out the BYOD program.

6.1 Roll Out the Program

On completion of a successful pilot, rollout activities will include training, perhaps reclaiming corporate devices, rolling out new tools and applications, configuring tools such as MDM, and providing additional support for employees.

7. Program Renewal

Periodically monitor the progress of the program.

7.1 Monitor and Evolve the Program

It's unlikely that the first version of a BYOD program will be perfect. Even if it is, circumstances change. Regularly track costs, support issues and security issues, and conduct surveys regarding employee satisfaction. Every 12 to 18 months, review the results, and be prepared to tune the program as issues are discovered.