|< Day Day Up >|| |
In the planning phase, you lay the foundation for your project. As in every project, you define the overall goal and the timeline for its realization. This chapter cannot get into the details of project management, but we will discuss some aspects that are of particular relevance to the implementation of a directory. Exhibit 2 shows an overview of the steps necessary in the planning phase. As you can see, there is no strict sequence in the necessary steps. Every step will result in the output of one or more documents.
Exhibit 2: Activities in the Planning Phase
One can divide the planning phase into following activities:
Define the overall goal of the project
List the benefits of the project
Define the objectives that must be met to achieve the project's goal
Determine the target of the project
Analyze the actual situation
List the steps to perform
Identify the project plan
A directory is often a strategic project for the whole enterprise, so a proposal defining the project's goal assumes a particular importance and is typically scrutinized closely by top management. Costs aside, they want to see a clear definition of two things:
Goal of the directory services project
Metrics to determine whether the goal of the project has been achieved
An unambiguous definition of the goal helps avoid misunderstandings between the project manager and the project sponsor. Perhaps more importantly, it helps the sponsor understand the purpose of the proposed project. The proposal should also clearly define some metric for evaluating whether the goal of the project has been achieved. The sponsor surely will want to know whether the money spent for this project was a good investment. With the help of the proposal document defining these two points, both the project sponsor and the project manager should arrive at a mutually agreeable definition of the project's goal.
Unless you are working in a pure research project, and very often even then, achieving the goal of the project will result in a benefit for your organization. This part of the planning activity explains the advantages of accomplishing the goal to management. In turn, management understands what it is buying when it agrees to invest the money required to reach the particular goal.
To achieve the goal of the project, you need to define objectives. It is important to understand the difference between the goal and the objectives of a project. The goal is the end result achieved when the project is finished and is defined in a more general way than the objectives. Normally, a project has only one goal. To arrive at the goal, you break the project down into objectives. An objective is more specific than a goal, and a project has more than one objective. The main property of an objective is that it be measurable. The overall goal of the project is measurable in time, effort, and cost.
Because the individual objectives have to be measurable, you and the other actors involved have to agree about the appropriate metrics. This will help in avoiding misunderstandings about who has to do what and when.
The planning group will have to confer with a number of people with different roles. Again, the precise identity of those with whom you have to engage during this process depends on your environment. There are substantially three types of roles for the people involved in your project: project sponsor, management, and users. This does not mean that the sponsor and the user are different persons. On the contrary, it is very probable that the sponsor will also use the directory, and it is likely that management also assumes the role of sponsorship.
It is a near certainty that your sponsor will want you to provide a compelling reason why she should spend money on directory services, so try to understand her perspective of what she expects your work should achieve. Note that this is not the place to address the technical aspects of the project. Indeed, the sponsor may not even understand what directory services are. Political and strategic goals should be your principal focus.
You will also be in contact with management. Again, you will have to understand what management wants to achieve with directory services. These goals are strategic and should define how directory services are located in your reality and set the priorities of the objectives to be achieved.
Finally, and most importantly, you must speak with the future users of your services. You have to understand what they expect from directory services. Here you will learn functional and technical goals. There are two types of users of directory services: technicians and end users. The technicians include the persons administering the directory server and those who are responsible for writing applications using the directory server. End users include the persons supplying data, such as human-resource people filling in new records, and the end users, who finally connect with an application to get the information they need.
The target of the project describes who in the end will benefit from the project. The target can also be called the end user. You describe the target to understand the importance of the whole project. Note that it is not simply a matter of counting the number of persons who will benefit from the result of the project. You will have to measure the improvement in the performance of the target users and then calculate the benefit the enterprise will gain from this improved performance.
Note that the target is not limited to physical persons. The project also will benefit applications. Thus, part of the planning phase is to understand what applications will use your directory data. Again, you will have to see where these applications are finally located. Gaining a clear picture of where your data could be needed is not an easy task, and it is essential to maintain a very tight contact with the users. Sometimes it is up to you to discover what applications could benefit from your directory. The more potential consumers you find, the less likely it is that you will have surprises later on. And the greater the number of applications that will use your directory, the more your work will be appreciated. It is a good idea to make a list of potential application types and then check to see whether these applications are actually being used in your enterprise. Examples of candidates are mail systems, calendar systems, room booking, help-desk applications, phone books, and every type of service using authentication services.
A further activity to be done is the analysis of the actual situation. The overall goal defines where you want to be tomorrow; this step shows where you are today. The objectives show the status of individual stations.
Because we are speaking of a project of data management, the first thing to understand is the data to be managed. That is, you need to know which repositories you actually have in place. It may be there is just one or more directories in place. Indeed, this is often the case, and then you have to understand the quality of the data in the directories. This means that you need to understand whether this data can be used in the project, including a means of controlling consistency between the individual data sources.
Because directory services are handling data, an important point you need to consider is what kind of data and what kind of information your directory should hold. Do not confuse this step with the data design you will make in the next step of the project. Here, you simply need to understand whether the directory should hold the data in question or not. What you have to do is decide whether the directory is suitable for holding the data in question.
Data appropriate to be held in the directory includes the following:
Data that is accessed from more than one application
Data that is accessed from more than one physical location
Data read more frequently than it is written
Data that can be expressed in attribute form, for example, sn = Voglmaier
Data not suitable for the directory includes:
Large, unstructured data objects like images, video, or binaries
Frequently changing data
Other data stores can be relational databases, file systems, file servers, ftp servers, http servers, etc.
Using the objectives you have defined, your analysis of the actual situation, and your knowledge of the actors involved in the project, you will break each objective down into a series of individual steps to perform. As you can surmise from Exhibit 3, the steps to perform depend on the actual situations, the objectives, and the resources available. Feedback from the individual steps can affect nearly all activities discussed until now and can even change some of them. These steps are indeed the first confrontation with reality.
Exhibit 3: Overview of the Directory-Design Process
The last action in the planning phase is the production of a project plan. You produce the plan using all of the information you have gathered. The most important part of the project plan is the Gantt chart. The Gantt chart assigns the steps to be performed by the different teams in the project and puts the steps in a timeline specifying a date when the actions must be completed.
What your project plan will look like depends on a number of factors, including the number of people participating in the individual work groups and the budget at your disposal. It will also depend on your reality (factors such as dimensions of network, design of network, number of clients, number of servers, etc.) and the standards on your site. Furthermore, it will depend on the complexity of the directory you will develop, such as the amount of data, the type of data, how the data is connected, and similar factors. Finally, it will depend on which departments in your enterprise are involved in this project, the strategic importance of the directory, and also the dimension of your enterprise. A plan for a project involving one little department will be vastly different than a plan for a whole enterprise operating in many countries spanning different continents.
Once you have all the information at hand, you will have a very extensive document. At this point, it is worth considering whether, instead of handling a monolithic project, you should break the whole project down into a number of subprojects. Subprojects are much easier to handle and help you in a natural way to develop strategic milestones, thus keeping your timelines under control. Furthermore, it permits you to develop working prototypes quickly that you can show your sponsors to show how work is proceeding.
|< Day Day Up >|| |