Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Webcast: In the Google Apps Cloud: How to Achieve Your Business Objectives
Dec 3rd, '09, 1 - 2 pm US/Eastern (GMT-5)
Join Council member Brent Hoag, Director, Global IT, at JohnsonDiversey, as he discusses the adoption of Google Apps which has helped meet four corporate goals; sustainability, simplification, increased employee productivity and global collaboration.
Webcast: Collaboration Initiatives: Benchmarks & Best Practices
Dec 15th, '09, 4 - 5 pm US/Eastern (GMT-5)
Join Council members Ruth Thorpe, VP & CIO at the U.S. Pharmaceutical Operations of Sanofi-Aventis, and Gary Kuyper, CIO at Bethany Christian Services, as they speak about their collaboration initiatives and experiences in how and why they chose the social networking and collaboration tools they are using and their business goals for collaboration, and facing culture change challenges.
Data Overview: Collaboration Initiatives Field Guide: Benchmarks & Best Practices
This appendix to the Council Field Guide provides an analysis which discusses benchmarks for collaboration IT implementation costs, adoption rates and payoffs. The overview identifies top IT and business goals and satisfaction rates for collaboration initiatives as well as best practices and lessons learned for implementing collaboration IT.
Learn more about the CIO Executive Council »February 29, 2008 — CIO —
Thus far we've looked at parts of an overall configuration management project. We've seen how to gather and analyze requirements, how to document the scope, granularity, and span of your Configuration Management Database (CMDB), how to customize the configuration management process, and what you need to understand to plan for data population. But thus far we haven't actually done anything. Now it is time to put all of this knowledge together into that most tangible of documents—a project plan.
Never get fooled into thinking a project plan is the same as a project schedule. The specific tasks, resources, and dates that make up a schedule are only a small part of a complete project plan. Each organization has slightly different requirements, but normally the overall plan is comprised of a communications plan, some sort of plan for supporting the system, and some kind of budget. You also want to document the outstanding issues that you know the team will face, and create a way to describe the architecture or design of the service you're planning. Although this isn't a book about project planning, this chapter at least examines the typical deliverables that make up a complete project plan and gives you some perspective on how these can be critical to a successful configuration management deployment. Expert project managers should still find enough content here to help hone the configuration management project plan.
In general, project planning should be about synthesizing the information from Chapters 2 through 5. We begin by reexamining scope, requirements, process, and data population from a project planning perspective. In the second part of the chapter, we pull together the other deliverables needed for a full plan. Figure 6.1 shows a visual outline of the chapter.
The first step in building a project plan is to gather together all the tasks that must be accomplished. For configuration management, the list consists of requirement tasks, scope definition tasks, process customization tasks, and data population tasks. The following sections serve as a reminder of the tasks involved with each of these activities and give some hints about the duration of the tasks and the dependencies between them. The intention of these sections is to give you a solid base for building a realistic project schedule.
The first thing that should go into your project plan is the scope and granularity that you documented in Chapter 3, "Determining Scope, Span, and Granularity." Setting the scope and granularity comes even before defining and analyzing the requirements because without a solid scope, it will be very difficult to structure your requirements gathering sessions. Those early requirements gathering sessions with your stakeholders must be based on some already derived work, and the scope documentation is a perfect starting point. Just be careful that you don't set the expectation that scope is completely finished—at this stage, it is really just a working model that will be shaped through the requirements gathering. Upon understanding even the basic concept of configuration management, most people will be eager to start talking about scope, so this is the first part of the plan.