The Role of Project Management in Closed Loop Lifecycle Planning
Posted on Fri, Oct 22, 2010 @ 10:48 AM
MCPc has been fortunate to benefit from Bruce’s breadth of knowledge related to PC lifecycle management. Closed Loop Lifecycle Planning offers a comprehensive view on all aspects of lifecycle management, including the importance of project and program management. We appreciate Bruce’s willingness to be interviewed for our blog, bringing together two of our core competencies — project management and PC lifecycle management.
Please offer a brief overview of Closed Loop Lifecycle Planning©, and why project management is a critical element.
Closed Loop Lifecycle Planning is the bill of material that is required to support client computing, as well as server computing and component peripherals. There’s also a user segmentation cost-of-change aspect, all of which has evolved from initial research in developing the methodology.
One of the conclusions of my research is simply that lifecycle management (LCM) is a project, and if you try to manage the bill of materials without integration, you sub-optimize various components of it. Project management is really the glue that holds this type of project together and gives you the ability to secure all of the benefits from it.
What are the key project-management deliverables?
The key deliverable is a clearly defined plan complete with milestones. The plan must consider enablers and inhibitors: what obstacles may get in the way and what will enable the velocity of the project.
As you work on the plan, the maturity of the LCM practice levels will determine the reports you generate, how often you run them and how frequently you assess them.
One deliverable I look at in the planning phase is a clear understanding of costs. For example, let’s say that you’re planning a Windows 7 deployment and your goal is continued process improvement over what you’ve done over previous years. To know if you meet this goal, you must have a baseline of your cost.
Then in the definition phase, you need things like software rationalization reports and definitions of service levels (particularly if new service levels will be built).
As the architect, you need to address issues such as what client automation tools you’re using. If the last refresh of a significant nature you completed was 24 months ago (because of the recession, for example), you’re now looking at very mature client-management toolsets. Consider how you use them differently than before to deploy.
A key role of the project manager is to determine the unintended consequences from some of the strategies you’ve done. A good project manger will be able to look at business processes and determine their implications and costs. Those that are truly skilled will put things both in the technology context as well as business context.
Can you expand on the idea of enablers and inhibitors as they relate to risk?
It is critically important to understand the level of risk in a given project. If a project has a lot of risk, you need to develop countermeasures; if risk is minimal, then that gives a program more flexibility.
Inhibitors can include: regulatory and legal issues, culture and politics of the company and technological considerations. You also have to consider outcomes, such as disposing of old assets in an environmentally safe way, getting DoD 3-pass wipe at end of life and having certificates of destruction to protect consumer information and intellectual property.
The project manager must manage the risk cycle. This means that each element in the bill of material is reviewed for risk. For example, if you hire contract labor to do the deployment, you have to ask: Are you indemnified? Are they certified? Have you done all your due-diligence to treat them as a full-time equivalent of your company?
Enablers include things like senior leadership commitment — it’s always good to have senior leadership buy-in into the methodology and outcome, then have periodic reviews so that they are a part of the ongoing project. Other enablers could be the technology and the maturity of client-management automation tools. For example, tools that do end-user profiling enable end-user segmentation, which can get you to root-cause analysis — ideal for project managers to look at. In a PC deployment project, the PCs themselves can be an enabler if they allow for new service levels and ongoing support.
What are some key mitigation strategies for top risks of refresh projects?
I’ll give you a very specific example: If a project manager looks at risk for data protection, he or she needs an encryption strategy and password protection. Part of what he or she should do is look at the existing, business-as-usual model, determine the associated risk and exposure, quantify the business case and then report these findings to senior leadership.
With this example, you get into details such as software license compliance, harvesting licenses, encryption, whether a desktop is more secure than a laptop and user segmentations.
What reports are typically generated or maintained during the project?
Every project should have a scorecard or dashboard. The dashboard should include: size of the install base, percentage of deployment within the install base, customer satisfaction (using clearly defined metrics), incident management control, time to deploy, improvement strategy and status against the cost baseline that was established at project implementation.
The most important data for the project, which was identified in the project plan, should be included on the dashboard. In a successful project, all metrics on the dashboard should be met or exceeded.
We are seeing more clients attempting to blend domestic and international lifecycle refresh projects. What are the critical success factors for these complex global projects?
There’s nothing wrong with domestic and international deployments, but there is an additional complexity in global projects, and all parties involved should understand this.
Most businesses can do U.S.-based lifecycle planning, but when you add in the global complexities of local laws, customs, relationships, taxing structures and labor requirements, it’s clear that there is more needed from the project manager to ensure a successful project.
When blending the project management office (PMO), roles, responsibilities and workflows still need to be clearly fleshed out. There’s really no technical or business reason not to share that construct, but if you put together one blended figure you need to be good at sizing it, because it’s difficult to break specific elements out at the end if there are issues.
How does user segmentation blend across domestic and international deployments? Is it common to have different user segments and service levels?
The key point is that global projects must start with a service-level discussion. For example, let’s say a service level for executives is concierge, meaning that there are dedicated resources associated with them. Can you deliver that globally? Are there resources in the various countries you’re supporting that you can deal with that? Is the infrastructure in place?
Or, for road warriors: What is the support plan on a global basis? Is there a mail-in service? What’s the SLA? Does it vary from country to country or business unit to business unit? How is that priced out if cost drivers are different as users move around the globe?
Global LCM projects also add a level of risk and cost. If you look at imaging, for example: What’s your core image? Can you deliver that core image across the globe, consistently? There are global SKUs as well, in terms of product configuration. If different business units and user segments will have different images, that adds a lot of complexity, and then there is a dependency upon what software-management tools will be used.
What tools must the project manager have in their kit bag (i.e. tools, template, techniques) to ensure a successful project?
This can vary greatly from business to business. I do, however, try to encourage people to use tools that are commercially available, particularly for outsourced projects, because they are very predictable and mature.
There are several options when it comes to service- and software-management tools, from companies including HP, Symantec and Microsoft. The most important things for program managers to consider when determining what toolset to use is that it is comprehensive, understandable and easy to manage.
How often do you see customers complete a refresh without implementing additional tools, still managing assets in Excel?
I’m not seeing as much of that as I used to. Most businesses today recognize that management by spreadsheet is typically not sufficient due to regulatory issues and consumer protection laws.
To remain compliant, businesses often have to be able to look at their complete install base at any time, know what assets are on the network, validate that they are encrypted, validate end users, validate where that system might be on any given day for mobile users, and put an agent on the device to do remote asset management. All of this is awfully hard to do via spreadsheet. For larger enterprises in particular, asset management tools are clearly the way of the future.
That being said, some small businesses may be able to get away with management by spreadsheet, provided they put in a fair amount of manual effort and have a solid understanding of policies.
One thing that I encourage is to talk to your deployment team and planning partner to determine the most appropriate toolset for the scope of the project. Another thing to keep in mind is that lot of solution providers host these tools for their clients, so companies need not always purchase them in-house.
Many thanks to Bruce for his time. If you enjoyed the information here, read Bruce’s Client Computing Blog or check out his book, Closed Loop Lifecycle Planning.
 |
Ira Grossman, VP, Personal Systems Group, has more than 15 years of technology project management experience and is an expert in lifecycle management and mobile device management for the enterprise, including the iPad. Connect with Ira on LinkedIn.
|