• Clarify relationships between individuals to be in the directory and the institution. When does an admitted student become able to access online library resources?
• Determine who manages, who can update, and who can see common data. How does an address get changed? Who is responsible for its accuracy?
• Structure information access and use rules among departments and central administrative units. Who can download directory information? Who can access the directory information in real-time? What security roles or levels will be used for various directory data?
• Reconcile business rules and practices. What needs to happen in the systems of record in order to have new student accounts added? Who must initiate this?

Project methodology
Once a decision to go forward has been made, the next set of decisions involve fitting the project into the current political and business context of the institution. There are a number of ways to approach this:

• Campus strategic project. This approach entails creating campus-wide support for the implementation and selling the idea strategically.
• Application requirement. This approach ties a directory service implementation to the deployment of an application, such as a portal. The costs are then rolled into the portal costs, and political issues are resolved within the framework of a campus-wide application need. Experience has shown that in order to leverage the enterprise directory in a broad fashion, the strategic work has to be done at some point
• Stealth. Many implementations are done without campus buy-in and instead the business case is made and the project is done inside central IT. This approach requires the necessary data, systems, and network infrastructure groups to be cooperative, and a degree of trust to be present between the technical staff and data stewards. The drawback to this method is the lack of concurrent policy development, which is important strategically to avoid duplicated systems of record, and to achieve economies in data access made possible by a directory service. However, many institutions have used this approach at first to demonstrate value to campus stakeholders and provide incentive to engage them in the necessary strategic institutional policy and business process discussions.

A bit about risk
A strong middleware project plan will include a discussion of major risks in the applications the directory is serving as well as the project itself. For example project risks and contingency plans, refer to the "Internet2 Early Adopters Participants, Profiles, and Scope Documents."

Develop communications and promotion plan
Managing expectations and publicizing quick wins is critical to acceptance of directory-enabled applications. Like ERP systems, middleware cuts across divisions and requires broad support and needs a champion, a shared vision, and support from the executive levels.

Through a combination of face-to-face conversations and presentations and web/hard copy communications, many campuses have handled this aspect well. The former allows the presenter to tailor the message to audiences such as the financial officer, data stewards, and technical staff, and the latter keeps the overall message consistent. If possible, identify ways to involve stakeholders in the decision and policy-making process.

Project managers and staff may find they need to reiterate the overall goals and business case many times before the directory is deployed and applications are enabled. Experience has shown that it is not possible to over-communicate here.

Discuss with stakeholders when appropriate
When selling the idea to stakeholders, some presenters have mentioned the terms 'identity management" or "directory services" and some have focused more on the outcome for the audience. Whichever method is chosen, tailor the message to the audience, do not overwhelm them with details, and emphasize the points most important to them, such as security, privacy, less time to deploy, or increased service offerings with decreased risk.

Consensus is important, but not critical to the project if you have enough support elsewhere. Report progress as often as you can and keep a consistent, constant message. Allow plenty of time up front to work with data stewards, and include them in the policy/business process discussions, if possible.

The technical staff are also stakeholders in this project. Expect at least some disenfranchisement as some audiences will happily accept, some will reluctantly accept, and some will need dragging along in order to understand the benefits and needs. Look for ways to make IT services easier and better for building internal support.

Develop project specifics
The Internet2 Early Adopter's Scoping documents offer a good outline of how to structure a project plan and what to include when developing one. Below are a few highlighted items that are especially important to consider:

• Quick wins should be planned into the project early in the process to demonstrate value. Middleware’s benefit is often found in productivity gains or through self-service. Identify ways to measure this ahead of time.
• Success enables more success. If the first few enabled applications are accepted, the directory team will be approached with more. Make sure later requests can be accommodated to help keep enthusiasm high.
• Over-provision the first infrastructure to accommodate growth, both in the use of the first applications and the addition of new ones. Do not skimp on hardware or redundancy.
• Develop overall guidelines for the directory and project, such as criteria for adding data to the directory and how those decisions are made, and so forth. This helps in decision-making later, when the project members can get bogged down in details.
• Be prepared to redefine responsibilities of people as the workload changes. The initial development team might not be the best to support this once it is in production.
• Treat the directory as a formal application development project, and provide for a life-cycle of support and management.

• Technical architect grasps the breadth of databases, applications, security, and their interrelationships. Understands organizational needs and values, and can map these into functional and security requirements for middleware.
• Project manager has a level of influence equal to being near the top of the central IT organization chart, and manages overall project progress and policy issues. Could be the same as the technical architect.
• Policy developer works with stakeholders and university administrators to develop policy for the directory services.
• Systems analysts and interpersonal communication specialists interact with data stewards, ensuring that detailed designs mesh with real practices in business and academic offices.
• Systems, database, and application developers implement the selected technologies and understand the details of how they must be integrated into the existing infrastructure.

Institutions use a number of ways to assemble this expertise. Some train staff-in-residence, some hire new staff, and some use consultants. Others have traded staff for open positions with other IT departments and hired new staff. Be creative, share the vision often, offer incentives to staff to participate, and keep in mind outsourcing as an option, if that is acceptable. Whether using in-house or outsourced expertise, the technical staff should understand the strategic value of the project and focus on application development and deployment.

Tools and Resources

Articles
Directory Services: The Foundation for Web Portals (PDF) by Albert DeSimone discusses the importance of directory services to web portal implementations. This document may assist in making the business case for directory services, if a portal implementation is the main driver.

Identity and Access Management and Security in Higher Education (PDF) demonstrates how core middleware, including enterprise directories, addresses security and access management issues in an institution.

The Middleware Connection (PDF) offers information about and short business case for middleware tailored to your institution's financial and business officers.

Documents
Identity Management Project Readiness Self-Assessment Checksheet (PDF) assessment is intended to identify factors at your school that other campuses have found to be important in their Identity Management projects.

Identifiers, Authentication, and Directories: Best Practices for Higher Education offers an up-level technical overview of the core middleware pieces and how they fit together.

Project plans
Internet2 Early Adopter's Scoping documents offer examples of how several institutions structured and planned their projects, including risks, project drivers, and communications.

Slide presentations
"Introduction to Middleware" (PDF) (PPT) slide presentation can be used to explain what enterprise middleware is, and why it is important.

To learn more about Project Planning, review the "Middleware Planning and Deployment 102: Mapping Out Your Strategy" (PDF) (PPT) slides.

For a business-case presentation that speaks to institutional Registrars, refer to "On the Internet, We Should Know Who's A Dog: Security, Privacy, and Personalization of Online Services." (PDF) (PPT)

Bookmark & Print Version • Graphic Version