Working Model of a TAP Consult

This document outlines our current best assumptions about what questions are resolved during an effective TAP Consult. It is based mostly on the ITAG Review Process outlined in the Enterprise Architecture Guide (EAG).  This is a draft document and comments / updates are welcome.

Preparing for the Consult

1. Project Managers who are coming before the TAP need to prepare a Vision and Scope document. 
2. The original template for the V&S is here . Look also at the InsideMIT and Undergraduate Admissions examples from the 08-30-2006 review.

Goals of the Consultation Process

1. Ensure that projects are ripe enough to leave the Prepare stage of the Project Management Framework (PMF)
2. Encourage projects that conform to existing technology guidelines with rapid and explicit gating to the Execute and Control stage of the PMF.
3. Scrutinize projects that plan to use new or non-conforming technologies for:
   1. risks to key areas of concern (data security, e.g.,)
   2. precedent-setting potential
   3. new technology roadmaps
4. Maintain the integrity of MIT's IT environment and look for opportunities to expand the user community's access to MIT resources

Ground to Cover by Consultants

Project structure

• Is the project following the process outlined in the PMF?
  If 'yes', examine the Project Startup checklist.
  If 'no', an equivalent level of attention to the same details is necessary.  The project has to demonstrate a satisfactory level of documentation, effective sponsorship, financial backing, and achievable vision.
• Can the project team answer 'Yes' to the questions in the Project Startup Checklist? 
  (Perhaps only the first two sections are truly required; but without sufficient attention to this, the project may not be in a consultable state).
  NOTE: Suggest we have the Startup Checklist in the packet of  handouts at the review.
• Has the project progressed to the Design stage of the SDLC?
  If not, is this consult an informational one, or to offer advice as to guidelines that need to be followed?  What are we actually reviewing?

Compliance with local technology ordinances

• Does the system design wholly conform with established development guidelines (formal or community-of-practice) for applications at MIT?
  • does the project leverage the existing architecture at MIT?
• Do any parts at variance with established practice raise any red flags?  Why?
• Do the non-conforming aspects represent an extension to the MIT architecture?
• Are any existing Technology Roadmaps related to this project, or do new ones need to be prepared to accomodate it? 

Risk Assessment

• Security
  • does the design adequately defend against potential data spills or other security compromises?
  • will the system be handling sensitive data now, or would it in the future?
• Internal Impact
  • does the project present risk to the IT environment (infrastructure, other applications, users ... )
  • If IS&T is going to be supporting this project, are the necessary groups "on board" with it, or is a plan in place to mitigate.
• External Impact
  • what users are impacted by the project? What mitigation or migration steps will be needed?
  • what other systems will be affected by the project? (e.g., touched by data feeds) 
  • are there other project risks such as violation of state and federal regulations or Institute policy?

After the Meeting -- Our Method for Arriving at Findings

At the consult, after the presenters have left the room, there is an around-the-table straw vote as to the outcome of the proposal.  Voting by TAP members is for one of:

Approving a project proposal requires a 2/3ds majority of "Yes" or "No Objection" votes, and no "Discuss" votes.   

After the consult, meeting notes are summarized and posted to the TAP before the next day.   
A findings document is drafted and posted to the wiki for comment by the end of Friday of the following week. 
The final findings draft is prepared and circulated by the end of the following Monday. 
Approving the consult for circulation is a short agenda item at the next TAP meeting.  

One of the purposes of the Findings document is to articulate the perspective of the board members about the project, clarifying and reinforcing aspects of the design that are especially advantageous or potentially risky and why.

Types of Finding

At the November 22, 2006 meeting, the TRB adopted this scheme for defining its findings.