MBA Field Project Statement of Work Template

Field Project Statement of Work: [Client organisation] [Project title]

Statement of work (SOW) for an MBA action-learning or consulting field project, in which a student team works on a real problem for a host client organisation under faculty supervision. It fixes the client, the problem statement, scope and out of scope, the starting hypotheses, the workplan with a Gantt chart, deliverables, governance, confidentiality and data handling, and the success criteria, so that the team, the client sponsor and the faculty advisor agree in writing before the work starts. Source basis: the action-learning tradition (Revans 1980), experiential learning (Kolb 1984), hypothesis-driven problem solving and common consulting engagement practice, written in original words. Many schools run field projects; your school's course handbook, project agreement and any non-disclosure agreement always take precedence over this template. Replace every [bracketed] value and every row marked Example. This is a planning document, not legal advice: the school or the client provides any binding contract.

Document control

Approvals

Contents

• 1. Purpose and the field project model
• 2. Client and context
• 3. Problem statement and key question
• 4. Scope and out of scope
• 5. Starting hypotheses and issue tree
• 6. Approach and workstreams
• 7. Workplan and milestones
• 8. Deliverables and acceptance
• 9. Governance, roles and communication
• 10. Confidentiality and data handling
• 11. Success criteria
• 12. Resources, client commitments and budget
• 13. Risks, assumptions and change control
• 14. Quality checklist and common mistakes
• Sources and further reading
• Revision history
• Standard and licence note

1. Purpose and the field project model

A field project (also called an action-learning project, a consulting lab or a client project) places a team of three to six MBA students with a host organisation that has a real, open business problem. The team diagnoses the problem, gathers and analyses evidence, and recommends what the client should do, under the supervision of a faculty advisor who also grades the work. Unlike a case discussion, the facts are not given: the team has to find them, negotiate access to them and decide which ones matter. Unlike a paid consulting engagement, the primary purpose is learning, so the school, not the client, sets the academic rules, and the client usually pays little or nothing beyond expenses.

The model descends from Reg Revans's action learning, in which managers learn by working on real problems in small groups and questioning each other's assumptions, and from Kolb's experiential learning cycle (concrete experience, reflective observation, abstract conceptualisation, active experimentation). Many leading programmes run versions of it. For example, MIT Sloan describes Action Learning as applying classroom theories and frameworks to complex, real-world challenges, and says students experience this hands-on learning multiple times during the programme rather than in a single capstone (mitsloan.mit.edu/action-learning, checked 2026-10-28; check the school's current details). Other schools run required or elective field courses, global immersion projects and nonprofit consulting clubs with similar mechanics. Whatever the format, the same three documents structure the work: this statement of work, a mid-point review, and the final report (mba/mba-field-project-report).

The SOW does four jobs:

1. Aligns expectations. The client sponsor, the team and the faculty advisor agree on the question, the boundaries and what "done" looks like.
2. Protects the team. A clear scope is the team's defence against scope creep, which is the most common reason field projects fail.
3. Protects the client. The confidentiality and data-handling section tells the client exactly what data the team will hold, where and for how long.
4. Sets the grading baseline. Faculty advisors often grade against the SOW: did the team answer the question it agreed to answer?

2. Client and context

Example: Northfield Outdoor Co. is a mid-size retailer and brand of outdoor gear (apparel, footwear, camping equipment and accessories) with 38 stores and an e-commerce site. Online orders reached 420,000 in the last financial year at an average order value of USD 96. The company introduced free returns by mail two years ago to compete with larger online sellers. Its head of e-commerce reports that 77,070 online orders were returned last year (a return rate of 18.35%), and finance estimates the direct cost of returns at about USD 1.84m a year. The sponsor is the Vice President of E-commerce and Customer Experience, who can approve pilots up to USD 250,000 without board approval. No previous study of returns exists; a carrier rate renegotiation last year reduced shipping cost per parcel but not the volume of returns.

3. Problem statement and key question

Key question. [What should [client] do, by [date], to achieve [measurable outcome], given [main constraint]?]

Example: Which changes should Northfield make in the next 12 months to reduce the annual cost of online returns by at least USD 250,000 without reducing online conversion or customer satisfaction below current levels?

Write the problem in the SCQ form (situation, complication, question) that Minto (1987) recommends for business writing:

Example: Situation: free mail returns are part of Northfield's customer promise and online sales are growing. Complication: returns now cost about 4.6% of online revenue, apparel and footwear dominate, and nobody knows which causes are fixable. Question: which mix of product-page, process and policy changes reduces the cost most for the least customer harm? Decision maker: Vice President of E-commerce, with the CFO for any spend above the pilot limit. Decision date: budget meeting in [month year].

Quality test for the key question:

• It names a decision, not an area of study.
• It contains a measure and a time frame.
• The sponsor can act on the answer within their authority.
• It can be answered with data the team can realistically obtain in the project period.
• Everyone who signs the SOW reads it the same way.

4. Scope and out of scope

Example:

Rules the team applies when a new request appears: if it changes the key question, it goes through change control (section 13); if it fits inside the key question and the agreed hours, the team lead may accept it and records it in the decision log.

5. Starting hypotheses and issue tree

Hypothesis-driven work starts with a provisional answer and organises the analysis to test it quickly, a practice described in consulting literature (for example Rasiel 1999). Break the key question into a mutually exclusive, collectively exhaustive (MECE) issue tree, then attach one testable hypothesis and the analysis that tests it to each branch.

6. Approach and workstreams

Method notes:

• Interviews. Use a semi-structured guide, take notes in pairs, and code the notes against the hypotheses. Ask the sponsor to introduce the team to each interviewee.
• Surveys. If the team surveys the client's customers, the client sends the survey or approves the wording; follow the school's research ethics rules on consent and anonymity. See academic/stats-sampling-plan for sample design.
• Quantitative analysis. Keep raw data, cleaned data and analysis separate, and log every cleaning step (academic/stats-data-cleaning-log).
• Economics. Use the client's hurdle rate and the same time horizon for every option, so options compare on one basis (mba/mba-npv-irr-card).

6.1 Team hours plan

Example: 4 students at 10 hours a week for 12 weeks gives 480 hours (Excel: =4*10*12). Each workstream's hours are the share times the total capacity: type 480 in an input cell such as $E$1 and use =B2*$E$1 (not the Total row, which would make the formula circular). Most schools state an expected weekly workload per course; use it rather than an optimistic figure.

7. Workplan and milestones

8. Deliverables and acceptance

Acceptance process: the client has [5] working days to comment on each deliverable; the team responds within [5] working days; silence after the comment period counts as acceptance unless the school's agreement says otherwise. Academic deliverables (reflection paper, peer evaluation) go to the faculty advisor only and are not client deliverables.

9. Governance, roles and communication

Use a RACI for the main activities (business/raci):

Communication rhythm:

• Weekly status (written, half a page): done, next, decisions needed, risks. Sent by the team lead on [day].
• Steering meetings at M3 and M5, plus M4 if spend is recommended.
• Single channel for client communication: [email thread or shared workspace approved by the client]. No client data in personal messaging apps.
• Team operating rules: in the team charter (mba/mba-learning-team-charter).

10. Confidentiality and data handling

The school's project agreement and any non-disclosure agreement (NDA) govern confidentiality. This section records the practical rules the team will follow, so the client can see how its information is protected. Where the project involves personal data (for example customer records or survey responses), data protection law applies, and the client and the school decide the legal basis and roles; the team does not decide those questions.

Annex A, the data request list, names each dataset, the fields, the period, the owner and the date requested. Keep it in the same folder as this SOW.

11. Success criteria

Project success (team accountable)

Business outcome (client accountable, measured after the project)

Example calculation: baseline return rate 77,070 / 420,000 = 18.35% (=77070/420000). A 2 percentage point reduction at the same order volume means about 68,670 returns (=ROUND(420000*(77070/420000-0.02),0)).

12. Resources, client commitments and budget

Client commitments

Expense budget (if the school or client funds expenses; check the course rules on who pays and what is reimbursable)

13. Risks, assumptions and change control

Change control. Any change to the key question, scope, deliverables or dates is written as a change request: what changes, why, effect on hours and dates, and what is dropped to make room. The sponsor and the faculty advisor approve it, and the version number in Document control goes up.

14. Quality checklist and common mistakes

Checklist before signature

• The key question names a decision, a measure and a date.
• Out of scope is as specific as in scope.
• Each hypothesis has an analysis, the data it needs and a disproof condition.
• Each workstream has one owner and a share of hours that adds up to the team's capacity.
• The Gantt chart and the milestone table show the same dates.
• Every deliverable has a format, a due date and an acceptance criterion.
• Client time and data commitments are written with owners and dates.
• Confidentiality and data handling follow the school's agreement, and the client has read section 10.
• Success criteria separate project success from business outcomes.
• The faculty advisor has approved the academic scope.

Common mistakes

1. A topic instead of a question. "Analyse our returns" cannot be finished; "which changes cut returns cost by USD 250,000" can.
2. Accepting every request. Without change control, the team ends up with ten partial answers and no recommendation.
3. Boiling the ocean. Requesting every dataset the client has delays the start and raises data-protection risk; request what the hypotheses need.
4. No disproof conditions. If no result could change the team's mind, the analysis is decoration.
5. Ignoring the client's calendar. Recommendations that miss the budget cycle wait a year.
6. Unclear sponsor. A contact without authority cannot unblock data or accept deliverables.
7. Client data in personal tools. Personal drives, personal email and unapproved AI tools break most school agreements and NDAs.
8. Uneven workload. A plan that ignores recruiting and exam peaks puts the final report on one or two people.
9. Promising implementation. Student teams recommend and design pilots; building systems or changing policies is the client's work unless the agreement says otherwise.
10. No buffer. The last week always takes longer than planned because the client asks for changes after the draft review.

Sources and further reading

• Revans, R. W. (1980). Action Learning: New Techniques for Management. Blond and Briggs. The origin of action learning in management education.
• Kolb, D. A. (1984). Experiential Learning: Experience as the Source of Learning and Development. Prentice Hall. The experiential learning cycle behind field courses.
• Doran, G. T. (1981). There's a S.M.A.R.T. way to write management's goals and objectives. Management Review, 70(11), 35-36. The SMART test used in section 3.
• Minto, B. (1987). The Pyramid Principle: Logic in Writing and Thinking. Pitman. Situation, complication and question framing.
• Rasiel, E. M. (1999). The McKinsey Way. McGraw-Hill. Hypothesis-driven problem solving and issue trees (further reading).
• MIT Sloan School of Management, Action Learning overview, mitsloan.mit.edu/action-learning (checked October 2026; check the school's current details). Named only to illustrate the field project model.
• Your school's course handbook, project agreement and NDA (the governing documents for your project).
• Related templates in this library: mba/mba-field-project-report, mba/mba-group-project-report, mba/mba-learning-team-charter, business/statement-of-work, business/project-charter, business/raci, academic/stats-sampling-plan.

Revision history

Standard and licence note

Structure aligned with the action-learning model in management education (Revans), experiential learning (Kolb), hypothesis-driven problem solving and common consulting statement-of-work practice, which are general methods described here in original wording. MIT Sloan is named only to describe a publicly documented field project format; this template is not affiliated with or endorsed by any school, and it does not replace your school's project agreement, NDA or course handbook. Northfield Outdoor Co. and all figures are fictional. This template is original text written for this collection. It is not legal advice; data protection and confidentiality questions go to your school's project office or the client's counsel. Template licence: MIT.