PruTech proposal supplied as Project Scope
Source: SUNY PruTech Project Scope.pdf. Its internal title is Attachment 13: Project Program Plan. The file contains 144 PDF pages, printed pages 2–145 of a stated 170-page document. PDF metadata names Jordyn Keeck Beach and a May 4, 2026 creation date; this does not establish the submission or approval date. The cover, later experience/staffing details, references and forms listed in its contents are outside the supplied copy. No annotations or embedded attachments were found.
This is a vendor proposal. It describes intended benefits, capabilities and methods, not verified delivery, research findings, a signed scope or a current schedule. Page references below are PDF pages; add one for the printed page number.
What it proposes
Learners would use one profile and catalog across participating campuses. Employers would arrange staff training. Campuses would retain local systems and policies, while SUNY gains a statewide view of participation and outcomes. These four groups organize the proposal. [Pages 5–7, 15–16, sections 1.2–1.3 and 3.1–3.2.]
The proposed foundation is Salesforce Education Cloud, Experience Cloud, Data Cloud and MuleSoft connections. The text favors configuration over custom development. It describes a 24-month implementation and recommends rollout by campus readiness, jointly decided with SUNY. Early adoption, learning from use, integration readiness and success measures are proposed rollout criteria. [Pages 6–7, 15–16.]
Source context and supplier claims
- Pages 1–4 are the contents. They include sections beyond this supplied copy. The footer's RFP identifier appears shortened to CM00425, while the project RFP is CM004257.
- Pages 8–12 describe PruTech, Salesforce Professional Services and Visionaryz. Examples include NYC school systems, Foreign Service Institute and Boise State. Claims about project scale, certifications, staffing and success are vendor statements, not independently verified evidence for SUNY's users.
- The organization chart on page 9 lists PruTech leads for engagement, overall solutions, project management, implementation, data/integration, Education Cloud, business analysis, quality, and change/training. Later onboarding names differ, so use this as proposal-era staffing.
- Page 10's company graphic claims minority/women ownership, 26 years, 1,100+ employees/consultants and 3,000+ projects. Page 11 lists software, infrastructure, security, data/analytics, consulting and digital services. These do not prove delivery capability for an individual feature.
- Pages 13–14 mark all eight minimum-requirement groups Yes and cite proposal sections. They cover data capacity, implementation services, source-system/SIS connections, migration, staffing, relevant experience, and functional features including multilingual support. This is a compliance response, not acceptance evidence.
- Page 16 promises continental-US data hosting, access controls, encryption, audit, and compliance with the RFP's privacy/security terms. Later details must be read with these promises.
Experience described for each group
| Pages | Proposed experience |
|---|---|
| 17–20, learner | One mobile-friendly profile, Global ID matching and communication preferences; statewide discovery by location, subject, format and schedule; transfer/credential details, maps, prerequisites, reviews and related recommendations. Registration would show deadlines, fees, funding and seats, with waitlist alerts and employer linkage. After enrollment, schedules, assignments, progress, credentials, career links, tutoring and support would be available together. Learners would control third-party sharing. These are intended outcomes, not evidence that all learners want the same dashboard. |
| 20–21, employer | Organizational portal, CSV or single registration, identity checks, participant replacement, progress reports and payments. The text promises consolidated billing across campuses, which needs comparison with later cart/payment decisions. |
| 21–24, campus | Choose direct Salesforce maintenance or connections to retained systems. Preserve payment processors, workflows and branding. Staff/instructors manage course data, schedules, rosters and support; leaders view enrollment, completion and outcome reports. Standard connections are intended to reduce integration work. |
| 25–26, SUNY central | Unified records, accurate unduplicated learner counts separate from registrations, activity index, comparisons across campuses, non-credit-to-credit progression and voluntarily reported employment/wages. Shared definitions and credential standards coexist with campus variation. Reporting can describe relationships; it does not by itself prove training caused an employment outcome. |
| 27–28, platform rationale | API/integration flexibility, capacity, education data model, security, configuration and responsive interfaces. Uptime, compliance, no-downtime updates and user satisfaction are proposal claims. The EDA description differs from later architecture direction. |
Functional responses
Pages 28–41 cover: profile creation/history and digital credentials (3.3.1.1.1–1.4), catalog/index (2.1–2.2), printable course details (2.3), direct or integrated campus maintenance (2.4–2.6), location search (2.7), browsing and funding information (2.8–2.9), timed waitlist offers (2.10), and campus-specific fees/payments (2.11).
These sections substantially repeat the proposal responses in the Jira source note. They have been read independently here; matching ideas are not independent evidence. Preserve the full proposal wording when Jira's requirement field is truncated.
Important conditions already visible: payment routes by the course's campus on page 41; campuses may manage in Salesforce or synchronize their own source; archived history is retained; waitlist offers have a SUNY-configured acceptance period; funding listings carry eligibility conditions; course detail can be printed for offline use or sharing. The proposal promises instructor search and saved-search notifications on pages 32–33, while later stories narrow search fields and leave notifications conditional.
Visual examples
The screenshots below are examples inside the proposal. They are not the October working prototype, a live production service, learner analytics or verified requirements. Only the visible image area can be assessed.
| PDF page | What the example shows |
|---|---|
| 17 | A sample Sofia profile with life events, academic indicators and alerts for library use, persistence and a registration hold. The examples include credit-style academic context. They do not establish that such monitoring is appropriate for every non-credit learner. |
| 18 | Course Finder has campus, format, subject, proximity, duration and class-time filters plus an almost-full option. Cards show campus, duration, seats, price and instructor; some show “Starts Invalid Date.” The waitlist email example gives a course, room, schedule, acceptance date and help contact, but its example acceptance date follows its course start date. These are visible sample-data inconsistencies, not live product defects. |
| 19 | Example AI certificate path has a completed unit, remaining units, duration, progress and enrollment actions. Points and progress bars are illustrated, not proven motivators. |
| 20 | Open support cases, hours, phone, request form and self-service links. The copy names SUNY Online/Brightspace support and includes degree/care-plan navigation. Its applicability to non-credit support needs confirmation. |
| 21 | Employer bulk registration lists names/emails and remove actions, including blank remaining rows and Purchase More Courses. This is a static illustration of assigning people to purchased places. |
| 22 | Card payment example includes name, expiry, security code and address, with a non-US toggle. Do not infer actual payment handling or compliance from the image. |
| 23 | Admin schedule example shows a course, building, 10:00–10:45 session, weekday selections and a schedule-template field. |
| 24 | Admin AI course example includes number, level, seats, duration, completion certificate, cost, format, provider, audience, objectives and several instructor roles. The example has several instructors, while a later Jira reply assumes one for now. |
| 25 | Salary-by-job chart with skill categories. No population, method or date is shown; its values are illustrative, not labor-market evidence. The same embedded image also occurs on page 74. |
Further functional and platform detail
All functional response text through page 81 has now been read. It covers every numbered requirement in 3.3.1, including the continuation of learner replacement and notifications on pages 48–49. The Jira note's response table summarizes the same proposed functions by requirement ID.
- Pages 42–43 describe credit relationships and credential preparation, including external tests. Pages 43–49 describe individual/guest/employer registration, waitlist priority by timestamp, staff overrides with permissions, withdrawal, replacement and notification preferences. Page 47 explicitly allows selected activities without an account, with later account creation optional.
- Pages 50–55 describe campus payments, invoices/receipts, direct financial-aid integration, funding applications/status, campus finance alternatives, refunds and gateway-specific methods. Page 50's home-campus routing differs from page 41's course-campus wording. Page 53's funding application process differs from the later information-and-external-link story.
- Pages 56–60 describe orientation, learning-system connections, personal progress, job/salary data and AI recommendations. Pages 60–64 describe credentials, ID matching, historical migration and staff verification. The SSN example on page 61 is clarified on page 86 as optional when supplied and allowed by SUNY policy.
- Pages 64–68 describe targeted announcements, channel/timing preferences with essential messages retained, campus communication integrations, appointments and mobile interfaces. Pages 69–72 describe surveys, reviews, integrated support, bot guidance, human transfer and synchronized tickets.
- Pages 73–81 describe warehouse links and all 17 reporting requirements. They include learner progress, voluntarily supplied demographics, unduplicated people, activity categories, non-credit-to-credit progression, campus finance and self-reported job/wage outcomes. None of the report screenshots supplies a research dataset or validates persona priorities.
- Page 82 describes component-based configuration, reusable interfaces and capacity. Pages 83–85 promise privacy/security controls, WCAG 2.2, keyboard/screen-reader support, clear form errors and all 12 required languages. SUNY supplies translations; PruTech exports/imports strings. Language preference is described at login and applies to messages and reports; guest language choice is not explained here. Other sections cite WCAG 2.1 (pages 70 and 95), so the proposal is not consistent about the baseline.
- Pages 86–88 describe SUNY Shibboleth authentication, Global ID matching before creating records, optional SSN, ambiguous-match review, campus enrollment provisioning, MFA and granular permissions. They also propose synchronizing staff roles from Global ID. Compare these with the later unresolved identity decision; this is not proof of a working public sign-in service.
- Pages 88–91 describe learner/SIS, course/LMS, payment and external-partner connections. The payment section says sensitive data never resides unencrypted in NCSIM, while page 50 says it is never stored. Actual payment responsibility needs a clear current decision. Source extraction, format conversion, rules and verified delivery are the four proposed integration stages, with monitoring and recovery.
- Pages 92–96 claim about 95% of requirements can be met through standard features/configuration and less than 5% through custom code, mainly campus payment flows. This is an estimate without a requirement-by-requirement calculation here. Data Cloud as the main repository, AI availability and broad integrations differ from the October architecture summary. Configuration-first can inform feasibility questions, but is not a measured limit on design.
Proposal schedule, not current progress
All schedule rows on pages 97–101 were read. The overall range is May 1, 2025 to May 24, 2027, 538 days as printed. Requirements/planning ends March 6, 2026; design/development October 23, 2026; testing February 15, 2027; implementation/integration March 18, 2027; closeout May 24, 2027. These planned dates differ from the October Sprint 1 snapshot and do not establish actual delay or the current baseline.
The rows cover kickoff, charter, stakeholders, risks, 12 discovery periods, gap analysis, mockups, requirements and integration specifications, architecture/data model, environments, Sprint 0–12, experience reviews, source-code handover, tests and traceability, UAT, source samples/mapping, migration validation, training and knowledge transfer. Deployment has no dates in its row; several code-package tasks have durations but no dates. The proposal asks for at least ten sample records per source object and again per extraction template for data mapping. This is data-sample planning, not a user-research sample.
Page 101 starts the planning method: kickoff minutes, stakeholder responsibility matrix, charter, work plan, review and infrastructure implementation plan are proposed outputs.
More visual examples
| PDF page | Visible content |
|---|---|
| 29 | Profile settings include email, password link, language, locale, time zone and email preferences. The sample uses a Pacific time zone; no SUNY-wide default is established. |
| 30 | Downloadable non-credit completion records, plus a Sofia 360 page with course/certificate/CEU counts and meal-plan/degree-style wording. May feedback later questions this academic framing. |
| 31–32, 34 | Bulk registration repeats; Course Finder repeats the earlier cards; page 34 isolates its filters. |
| 35 | Course detail sample includes code, science subject, duration without a visible unit, dates spanning 2022–2025, campus and a description containing lecture/lab units. Treat as sample content needing contextual review. |
| 37–38 | Staff course list uses credit hours; AI course and schedule views repeat earlier examples. |
| 39 | Salesforce Maps shows 64 campus markers and a Brockport campus address. It illustrates campus geography, not verified teaching locations or travel distance. |
| 40 | Course-preference wizard asks education level, field and years since education; credential path illustration repeats. Neither proves the need for compulsory profiling. |
| 41 | My Courses lists payment pending, waitlisted, enrolled, withdrew and completed alongside academic-term fields. |
| 42 | Fee example itemizes $500 base, $500 supplies and $1,200 tuition, total $2,200. Discounts say 10%, 15% and additional 5%, but show $200/$300/$100 and also say discounts cannot combine. No discount basis is explained. Age/diploma conditions are sample rules, not universal policy. |
| 44–45 | Staff course participant list shows enrolled/waitlisted people, five seats left and 25 waitlisted; employer registration repeats. Static values do not explain seat-hold or waitlist rules. |
| 46 | Staff registration form includes enrolled-by-staff, bypass validations and an override reason. This illustrates recording an exception, not unrestricted staff authority. |
| 47, 49 | Waitlist, registration and status email examples contain course, date, schedule and support contact. They are sample communications. |
| 50–51, 54 | Card form repeats; invoice shows unpaid balance and campus contact, receipt says paid and seat confirmed, payment email confirms receipt. These are separate example states, not one verified transaction. |
| 55 | Multi-person withdrawal form asks course, reason and refund-policy acknowledgement. It lists enrolled, waitlisted and in-progress participants. Exact refund amount is not shown in the visible example. |
| 56 | Career-resource tasks link interest, skills and personality assessments. No results, validation or endorsement are supplied. |
| 57 | Appointment wizard illustrates choosing an academic advisor, tutor, career advisor or aid advisor. This does not demonstrate the learning-system integration discussed on that page. |
Delivery and research methods promised
| Pages | What the proposal says |
|---|---|
| 101–103 | Identify stakeholders and their responsibilities, agree a charter, define success, plan dependencies and validate environments. The schedule becomes a baseline only after SUNY approval. |
| 104–109 | Review existing systems, rules, data, roles, personas and user requirements before new interviews. Compare current and future needs. Proposed methods include individual/group interviews, surveys, observation, focus groups, site visits and workshops. Record requirements, flows, wireframes and data models. Validate clarity, need and testability. The validation report should say who gathered, checked and approved requirements. Track each requirement through design, development, testing, acceptance and deployment. These are promised methods, not proof the studies happened. |
| 110–114 | Design architecture, data, components and interfaces, including site maps, journeys and prototypes. Page 112 describes learning from people, testing ideas and refining from feedback. Page 113 defines personas as patterns drawn from observations of many people. The supplied draft personas do not contain that research. Trace design elements to requirements; obtain design/architecture approval before establishing a baseline. |
| 114–116 | Assign build work, set up environments and delivery tools, implement rules/content/forms/connections, and use agreed branding/wireframes. A design system and content assets are proposed. Reports should match the needed information. |
| 117–119 | Test complete business tasks, connections, performance, converted data and regressions. SUNY stakeholders perform acceptance checks before production. A changed requirement should be managed as a change. No test results are supplied here. |
| 119–123 | Define data direction, timing, endpoints and formats. Use repeated trial migrations, growing the dataset each time. Compare source and destination, record failed data, resolve it and verify downstream tasks. The proposed approach changes source-system data before extraction; this is not authorization for this design review to modify any data. Historical years, detail level and in-progress cases need decisions. |
| 124–126 | Closeout includes technical documentation, sign-off, knowledge transfer and training. Training covers administrators, end users and technical staff. Train SUNY trainers, provide quick starts/manuals and validate delivery. The figure on page 125 reinforces these groups and activities. |
| 127–128 | Proposed measures include registration efficiency, campus adoption, administrative work, integration performance, persistence/completion and non-credit-to-credit movement. No baseline, target or observed result is supplied. The diagram maps planning/requirements, design/build, tests, integration and closeout to communication, risk, quality and change management. |
| 129–131 | Proposed communications include kickoff, team/business meetings, weekly status/time reports, monthly billing and achievement reports, and incident-specific service reports. The agenda image is a blank template with objectives, attendees, discussion, decisions and actions with owners/dates/status. It is not another meeting record. |
| 131–135 | A shared project site should hold current records, status, risks and decisions. Jira/Confluence, SharePoint and Zoho are examples, not a selected system here. Formal changes after baseline go to a change board, with impact, rationale, decision and updated estimates/traceability. Configuration roles and all 14 process steps cover versioning, change approval, audits and correction. |
| 136–138 | A typical review cycle is five business days for SUNY, three for vendor revision and two for further response. This is a proposal example. Quality checks include inspections, walkthroughs and tests. Risk tracking records probability, impact, timing, response and owner. Probability bands are subjective estimates, not statistical evidence for learner problems. |
| 138–144 | Sponsors and a project control board oversee scope and business value; project managers handle daily work; user leads represent final requirements. The proposed board is chaired by the agency CIO/appointee. An independent senior vendor owner represents business interests, with a suggested board of no more than six. These roles are not confirmed current approvers. The final pages cover clear decision rights, records, reporting, audits, issues, scope/schedule changes, quality and resources. |
Remaining visual examples
| PDF page | Visible content and limits |
|---|---|
| 40 | A small banner invites a guided course questionnaire. It does not show its full question set or prove that profiling is required. |
| 59–62 | Academic performance, GPA, degree progress, library fees/use, residence incidents and alerts appear in examples. Recommended-course cards show price/duration but no explanation of the recommendation. Sofia's profile/360 view repeats credit-style context. These are illustrations, not learner analytics or validated personalization. |
| 63–64 | Credit-transfer wizard asks destination institution/program, reason and date, then credential type/issuer/completion/expiry and a validation action. Screens alone do not show a working verification service or establish automatic credit recognition. |
| 65 | Communication controls for email, SMS, push and academic updates, with frequency/topics and a save action. Critical-message rules are in the text, not demonstrated by this screen. |
| 67 | Appointment-topic step lists academic/career topics. A marketing-flow image includes welcome/targeted/re-engagement emails, waits, branching on opens, social retargeting and webinar follow-ups. It is an example flow, not a SUNY consent or communication decision. |
| 68–69 | Staff course view repeats the AI sample. A completed sample survey gives course/content/instructor ratings and praise. This is example content, not collected feedback from a learner. |
| 71–72 | Brightspace support view repeats. Course Finder chat asks for a name and permission for more questions; the remaining conversation is not visible. It does not demonstrate recommendation quality or human handoff. |
| 75–78 | Example dashboards show engagement, ethnicity by year, enrollment, activity effectiveness, feedback and credit progression. They lack dataset definitions and cannot support claims about SUNY users. The enrollment donut combines overlapping categories such as gender and attendance type. Feedback uses a “Sum of Value” axis without an aggregation method. These are chart-definition questions for later reporting review. |
| 81 | Degree-progress illustration includes completed and unplanned credit hours and academic requirements. It is not a confirmed non-credit progression model. |
| 125, 128, 131 | Training cycle, delivery-process diagram and blank meeting template, summarized in the methods table above. |
What this adds to the evidence
E-017. Research with people, journey maps and evidence-based personas were part of the proposed method. This supplies a reason to seek any resulting research records; it does not establish that they exist. [Pages 104–113, sections 3.5.1.2 and 3.5.2.1.5.]
E-018. The proposal's screenshots and report values are illustrations. Several use academic/credit concepts, sample data and unverified chart definitions. Use them to understand the proposed direction, not as facts about learner behavior or as the current prototype. [Pages 17–25, 29–81.]
Coverage and reuse
Fully reviewed: all 144 supplied pages, all text/tables and meaningful figures. All 203 extracted unique images were inspected: 65 large figures and 138 smaller assets (mostly section numbers/logos, plus the course-questionnaire banner). Repeated images share the same content. No annotations or attachments were found. Material outside the supplied page range remains unavailable.
The 82-page S08 excerpt is identical in normalized text and rendered page images to this source's PDF pages 15–96, corresponding to printed pages 16–97. It shares this reading and is not independent evidence.
Related topics: cross-source findings.