The EIF is a model and not an absolute approach. Whether your organization remodels EIF wisdom into its own process or simply uses it as a conceptual baseline to measure the approach of contractors, the EIF is most effective when approached as a rough outline. You must adapt it, enhance it, and mold it to your organization.
Any well-established project practices in your organization that conflict with EIF prescriptions must be reconciled. You should also consider that the overall EIF approach assumes that a full Project rollout occurs after 4 weeks of pilot activity. While this may or may not suit your needs, it’s a reminder that the manufacturer’s recommendations should be tempered by your own organizational ability to absorb the technology. A strong go/no-go decision point is a legitimate step between piloting and rollout, and some organizations are best served by a slower-paced adoption than the one suggested by the aggressive project plan provided.
The EIF doesn’t emphasize project inception. It gives short shrift to activities such as determining stakeholders and identifying team implementation roles. These are conveniently bundled into the requirements gathering process. In the absence of a well-understood inception process in your organization, you should give this more time than the EIF suggests. You should have a good organizational understanding of the objectives and reasons for implementing the tool, the complexity of the work, and the organizational pain that you will face in making this decision. Make certain that everyone has the same expectations.
How will your organization go about implementing Project Server? Determining a deployment level is a fundamental decision early in the planning process. Is this a departmental deployment or a cross-departmental deployment? To some degree, determining a potential deployment level for Project Server in your organization is also necessary. Do you structure your configuration for a larger potential, or do you keep it contained? Most organizations benefit from expanded prework and implementation planning.
Rather than conducting the interviews to produce the Red Flags Report alone, expand the preparatory steps you take. A go/no-go decision point at the end of this process can spare you wasted effort if it reveals serious obstacles to success. Conducting the interviews has potential therapeutic value and reveals roadblocks as well as opportunities. These revelations may lead you to rethink your deployment strategies; therefore, this exercise offers the most value as an early step in the process. The flowchart shown in Figure 2-3 illustrates a structured approach, incorporating an assessment strategy at inception. This is the high-level process required to take a Project Server implementation to a pilot or proof-of-concept phase.
Figure 2-3. Project flow from assessment through pilot
The EIF tacitly drives both assessment and requirements through the single-interview format. In my opinion, initial assessment interviews are most effective when asked in absence of Project Server knowledge to avoid confusing solution capabilities with needs. Requirements discussions, on the other hand, benefit when the participants are familiar with the potential of the tool. It’s not entirely realistic to believe that one interview process will fulfill both needs. It’s more realistic to expect a good requirements straw-man document as a by-product of the interview process and that additional Joint Application Development (JAD) sessions are necessary to flesh out requirements to a ready-for-configuration state.
A consultant can add significant value to the assessment process. It’s often much easier to get interviewees to open up to an independent third party than to a company insider. A nonthreatening interview forum is important to get at disconnects that drive the Red Flags Report. Interviewees should not feel as though they must recite what the interviewer wants to hear.
The assessment phase presents a collateral opportunity to perform some more extensive organizational analysis. Piggybacking the Red Flags interview process onto a Project Management Maturity Model (PMM) and/or Capabilities Maturity Model (CMM) assessment takes advantage of synergies, but requires an additional prework investment. Here, again, the assistance of a consulting firm can be invaluable.
The EIF appropriately emphasizes system documentation by providing both Requirements Specification and System Design templates. It’s most important to maintain complete configuration documentation because Project Server is deficient in its presentation of custom information in its administration interface. For instance, custom field names don’t appear on the pick lists provided for adding fields to Web views. Therefore, you must have a readable, concise guide to these when performing administration work. You may fall in love with the Excel format of the System Design template, but I think its format is cryptic and awkward. Further, I suggest an evolutionary approach to both the requirements and system design deliverables whereby the requirements document evolves into the design document, keeping the rationale with the specifications.
Simply put, to improve the EIF make sure that your inception process follows your organization’s practices or is designed to be a model for your organization, spend more time in the assessment phase and get more value from it, and consider streamlining the documentation process.
Although the EIF Interview produces good input for the Red Flags Report, the focus is narrow. By adding more depth to the assessment, you can strive to identify underlying causes for the process disconnects identified in the Red Flags Report. To accomplish this, you should add questions focused on project management maturity. If your organization doesn’t have a mature project management process, your risk of failure is high. If you don’t know what project management maturity is, Harold Kerzner’s Strategic Planning for Project Management Using a Project Management Maturity Model  is the gold standard for understanding the challenges and the benefits.
To understand the complexity of implementing a process maturity program, in this example the CMM, Diane Burwick provides a comprehensive implementation program framework in How To Implement the CMM.  Although the material is specific to software development, the underlying management philosophies and process fundamentals contained in the program manual support advancement through either CMM or PMM. Adapting and right-sizing a solution for your business is one of your most significant challenges.
The EIF Interview is an Excel workbook with validations applied to many of the questions. The validations are incidental and tend to be more limiting than they are helpful. For your convenience, I’ve converted the interview to a Word document, which you can download from http://www.projectserverexperts.com. Many of the validated questions restrict answers to yes or no. This is particularly limiting because sometimes the proper response and good collateral information you may otherwise capture becomes cumbersome, forcing you to add text outside the form margins.
Harold Kerzner, PhD, Strategic Planning for Project Management Using a Project Management Maturity Model (New York, NY: John Wiley & Sons, Inc., 2001).
Diane M. Burwick, How to Implement the CMM, Second Edition (Louisville, KY: BPS Publications, 2001).