- Introduction
- Is Lifecycle Management a Best Practice?
- Continuous Process Improvement
- The Impact of the Consumer Market
- What About Those Regulations?
- Making Lifecycle Management Decisions Consciously
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Is Lifecycle Management a “Best Practice”?
Best practices are generally defined as the processes followed to optimize service levels while minimizing risks and costs. Although few would disagree with this definition, there is often an assumption that “one size fits all” as relates to best practices in general.
Experience has taught, however, that a logical threshold determines whether a business can fully adopt best practices. Most important perhaps is whether a best practice can scale according to the complexity, size, and scope of a business. Most companies, for example, need different service levels for different types of users, and IT must be able to meet this requirement.
One way to put best practices into perspective is via an employee count or a count of the end-user population. Based on my experience, the following scaling perspective will help you understand best practices.
- Number of Employees or End Users with Access Devices
- Fewer than 5,000
- 5,000 to 10,000
- 10,000 to 20,000
- More than 20,000
If viewed in this context, lifecycle management can be more easily adapted to the unique requirements of businesses based on the criteria of scope, size, and complexity. The fewer the number of employees or end users, the more likely that the processes will be manual and that lifecycle management will have more of a high “touch” perspective. Affordability, as it relates to investing in lifecycle management, will factor highly in the “fewer than 5,000” category. Although automation, TCO, lifecycle management, and risk are important issues to these businesses, cash flow just might not suffice to address these issues at a high level yet. And so, these businesses put off addressing these issues until profitability and investment priorities are compatible.
Management tools and predefined processes for this size of business are being scaled to make things more affordable for these companies. The market has recognized their growth potential, and so this segment will clearly get favorable attention. Even as of this writing, investment dollars are focused on scaling solutions for those businesses in the “fewer than 5,000” employees or end users category. After all, the risks and liabilities are as important (some might say more important) to this business category as to any other.
In the “5,000 to 10,000” category, the perspective of lifecycle management is that the scaling is such that manual intervention and resources required suggest a higher level of best practices. This implies more tools and more well-defined strategies going forward. Businesses in this category often believe that they are on the cusp of requiring more sophistication as it relates to best practices. Although not scaled to be fully manual, and perhaps not sized to have a large, robust IT department, many of the processes and resources are stretched. The “5,000 to 10,000” category tends to be more resource intense and expense constrained.
The “10,000 to 20,000” category is a clear area where best practices can be scaled and are more easily defined. The governance is extraordinarily relevant, and the expectations are clearly higher. Accountability is necessarily high in this category because the scope of what needs to be managed becomes much more complex, simply because of the number of end users impacted. In this category, it is not unusual to find that businesses are growing organically or through acquisition. In this scenario, lifecycle management becomes a critical discipline that can impact how competitive the new organization can be in the market. Information is a key and critical asset. IT plays even a more pivotal role in the new enterprise.
When a company has more than 20,000 employees or end users, lifecycle management really becomes non-negotiable. Without doubt, to comply with regulations and governance, these businesses must fully embrace best practices relevant to the size and scale required.
The overall message in this section is not that best practices are inflexible or inadaptable; it is that best practices must be viewed in context. Scaling and scoping are key factors to consider. The fundamental work to be performed does not necessarily change, but how that work is accomplished will certainly vary. Lifecycle management, therefore, is a custom solution.
Lifecycle management itself is a best practice!
Why Does It Often Take a Compelling Event to Initiate Lifecycle Management?
According to closed loop lifecycle planning, a compelling event is an occurrence that triggers a review and potential change in access devices and support strategies. Such events are common and occur frequently. Another helpful term to understand is business as usual, which describes the stable state of a business.
In the client computing environment, having or anticipating an event can be enough to trigger an evaluation of lifecycle management. The events and scenarios listed here are types of business-as-usual activities that might trigger a lifecycle review. Each of these topics is covered in detail in various sections of this book. A compelling event might be any of the following, among others:
- Technology refreshes
- Software compliance audits
- Cost-reduction initiatives
- Acquisitions/divestitures
- New management
- Related industry developments
- New technologies
- New facilities
- Regulatory/legal requirements
- Risk-reduction initiatives
- Policy or governance
- Personal privacy protection
- Intellectual property protection
Any of these compelling events by themselves could be the catalyst for lifecycle management to be explored in earnest. In each of these compelling events, lifecycle as a solution becomes the lynchpin of the approaches to secure benefits (whether it is to reduce costs, avoid costs, mitigate risks, or improve service levels).
One common element in all of these compelling events is that they suggest change.
In today’s business-as-usual environment, most of these compelling events are considered the norm, not an exception. This change in the definition of a compelling event could be one reason why lifecycle management has remained constant and periodically seems to elicit renewed vigor with regard to the discipline.
“It Takes a Change Agent”
To implement lifecycle management, someone must act as a “change agent.” The change agent will be, simply put, a very unpopular person for a period of time; after all, change to many implies that something is “wrong.” The dynamics of change and the cost of change are discussed more fully later in this book. The reason to raise this point here is that in all organizations, there needs to be a focal point to establish and effectuate the vision.
Don’t confuse the role of the change agent with that of a program or project manager. The roles differ significantly, and to a large degree are unrelated. The change agent addresses the organizational, emotional, political, and cross-business issues relating to lifecycle management. The project or program manager provides very specific deliverables in terms of process and procedures relating to work actually performed. Depending on the size and structure of a company, someone on the staff can be given direct responsibility to implement the vision; this person is the change agent.
Lifecycle management will always require support at the executive level. Without this commitment, only portions of lifecycle management may be delivered. For many companies, a partial approach might seem adequate, and so not all businesses will fully embrace integrated lifecycle management. However, partial implementation ensures suboptimization. And although the business case for lifecycle management might have been effectively created and accepted, the cost of entry (in both political and economic capital) might entice some businesses to attempt a partial implementation.
One role of the change agent is to determine what the vision (solution) is at the governance and policy levels. The next step is to determine how this vision can be executed within the organization. Without executive sponsorship and a champion, however, no vision can be effectively implemented (or behaviors changed). One would logically look to the chief information officer (CIO) and chief technology officer (CTO) as key sponsors for change within the enterprise. The CIO, chief organizational officer (COO), chief financial officer (CFO), or CTO generally champions change within an organization. Any or all of these executives can be considered senior management change agents.
The staff person driving the change must be empowered by the executives and have their full support. If not, the changes are difficult (if not impossible) to implement. Experience has suggested that change agents have a high turnover rate due to the significant pressures; frustration and “burnout” are symptoms commonly expressed.
A change agent is a highly sought and a highly valuable resource. The role is so critical that it does relate to how competitive a business can be in its industry.
Pilot and Proof of Concept
The terms pilot and proof of concept are often used interchangeably in the industry. For lifecycle management, these terms have specific meaning and are not the same. It is important to understand the differences between the two terms as another foundation for lifecycle management.
A pilot is the testing to determine whether a technology works. Product specifications are provided, speeds are defined, networking connectivity is defined, and so on. Pilots are a technical evaluation process and are generally performed in a lab environment. The persons performing the evaluation are the engineers and architects. The objective is to ascertain whether the specifications provided perform correctly and the functionality is as presented. Piloting is a critical task within lifecycle management and is covered in more depth later in this book.
Proof of concept, on the other hand, is a business proposition. A proof of concept takes the approved technology (validated technically in the pilot phase) and rolls out the technology along with the support processes in a scaled production environment.
Lifecycle management should be viewed in a proof-of-concept perspective. Many businesses consider the proof-of-concept phase the initial phase of the overall deployment of lifecycle management practices. The thinking is that if the proof of concept is executed as expected, the policy, process, and procedures can be adopted.
The distinction between pilots and proofs of concept is critical. Lifecycle management is not a pass/fail proposition. Many of the business support decisions regarding the proof of concept should be made in this phase.
In summary, a pilot and a proof of concept are two different things, each with its own unique criteria: one technical and one business. These two lifecycle elements should not be confused.