How to Write a Project Charter: Template, Steps & Examples

To write a project charter, you’ll need to define project-specific goals, stakeholders, scope, and resource needs. Discussing the project with your team and stakeholders is mandatory. 

First, state the reason why the project is being made. Next, understand the key deliverables, outline roles, set budget, note risks, and get authorization from the project sponsor. These activities need to be conducted step-by-step in order to avoid conflicts. 

Key Highlights: How to Write a Project Charter

• A project charter is a high-level document (also called a project brief) that defines a project's goals, benefits, constraints, risks, stakeholders, and budget. It's written right after the business case is approved and before deep planning or resource assignment begins.
• Every strong charter covers 8 essential elements: purpose and business justification, measurable SMART objectives, in/out scope definition, deliverables and milestones, high-level budget and resource estimates, stakeholder roles with defined authority, risks/assumptions/constraints, and formal sponsor sign-off.
• Writing one follows an 8-step process: confirm the sponsor and business case, draft a two-sentence purpose statement, convert goals into measurable objectives, define scope boundaries and exclusions, list deliverables and milestones, estimate budget/resources/timeline, capture risks and assumptions, then route for review and secure sign-off.
• Weak charters stay vague ("improve customer experience"), while strong ones are specific and metric-driven, such as "reduce support resolution time from 48 to 12 hours." The most common failure point is scope, since teams often state what's included but forget to name explicit exclusions, which is the leading cause of scope creep and later disputes.
• Approval isn't a single signature. It's a sequence of collaborative drafting, internal alignment checks, sponsor review, governance board input, revision cycles, and version-controlled documentation. If a sponsor withholds approval, the project is deferred, scaled down, or redirected until scope, budget, or timeline objections are resolved.

Just like everything else in project management, there’s no single way to write a project charter. The most important thing when creating your project charter is to make it easy to read and accessible to anyone who's involved in the project. Remember, the charter should be a high level review of the project. Here, you can use short descriptions or even bullet points to help you keep it brief. 

In this guide, we will understand what is a project charter and when you can write one. We shall be covering the importance of a project charter, how to write the same in 8 steps. You will also understand the weak and strong examples of a project charter. To keep things simple, there will be templates shared with you. Post this, we’ll discuss how to get your project charter approved, common mistakes to avoid, and project management training for stronger project initiation. 

What a Project Charter Is and When You Write It?

A project charter is a document that details your project’s goals, benefits, constraints, risks, stakeholders, and budgets. It is also called a project brief. 

The purpose of a project charter is to set clear project expectations, helping you lead big teams and complex projects to an on-time and under-budget delivery. It also brings benefits like aligning stakeholders and teams with the project’s objectives and clarifying key details that could impact the project. 

You can get started with writing the project charter during the project initiation phase or post if the project idea is deemed feasible. To keep it simpler, check out key moments to write a project charter: 

• After the business case - Decision makers will agree upon the project’s financial and strategic requirements.
• Before deep planning - Begin with writing the project charter before you undertake work breakdown structures.
• Before assigning resources - It’s important to look at the project charter before the project manager receives authority to invest time, money, and resources. 

Project Charter vs Business Case vs Project Plan vs SOW

These four documents have their own purpose. It starts from justifying an investment, authorizing it, to planning its execution with work details showcased precisely. However, new project managers find it challenging to understand as they differ in timing, purpose, and audience. 

Let's look at some of the key differences.  

The 8 Essential Elements of a Project Charter

Here are 8 essential elements of a project charter: 

1. Purpose and Business Justification

This is one of the key elements of a project charter. As a team, you need to stay aligned and be on the same page with respect to understanding why a project exists. Some of the factors which your team must article include the following 

• The problem or opportunity
• The business needs
• Why the project is important 

Example: For a software development project, your project charter must state its purpose. This can be related to improving user experience by creating a mobile app for better access to services.

2. Measurable objectives and success criteria: 

The success criteria for a project is determined by the project’s objectives. Your progress can be measured via outlining key metrics in your charter. Start by defining the following:

• Qualitative metrics - latency and activation rate.
• Quantitative outcomes - improved usability
• Measurement timeframes. 

Once you define the success criteria, sprint planning becomes easier. 

 3. Scope: What Is In and What Is Explicitly Out

Here, you ought to have a broader vision for your project;  including having clarity on what will be added to the project and what will be removed. By performing this activity, you’ll be able to set expectations with respect to project deliverables and boundaries. 

For example: If you need to relocate your office, the project charter can specify key requirements like moving equipment and employees to a new location. This doesn’t include renovations to the new office. 

4. Key deliverables and milestones

(a) Deliverables 

Having key deliverables in place helps you understand what needs to be done with respect to your project. These deliverables need to connect with your objectives and whether they can be tangible (product or a report) or intangible ( a process improvement ). 

For example - When it comes to executing a marketing campaign, a project charter can list deliverables like campaign reports, promotional materials, and social media content. 

(b) Milestones   

Mentioning critical phases or checkpoints which the project will go through is important to track progress. Consider writing down major deliverables or approvals, such as planning phase completion or final review of what’s been achieved so far. 

For example - If you’re having a product launch, a project charter can include milestones like “marketing campaign launch”, “product prototype completion”, and “user testing phase”.

5. High-level budget and resource estimation  

A successful project depends upon two important factors - budget and resource estimation. For a strategic and thoughtful budget allocation, we can look at two project cost estimation techniques 

(a) Analogous estimation 
Here, we estimate the project costs according to the budget spent in the past. 

(b) Parametric estimation 

Historical data is used to combine statistical modeling, helping in calculating the expected amount of financial resources for project completion. 

6. Stakeholders, roles, and project manager authority 

First, list down key stakeholders who would be part of the decision-making process. You can start with project sponsors, team members or other individuals who had previously shown interest in a project’s overall success. In this section, learn about who will be involved or informed regarding the project’s process. 

For example - For effective software project management, a project charter must have the details of project sponsors, end-users, IT department, and the quality assurance team as the best stakeholders.  

7. Assumptions, constraints, and high-level risks 

During project execution, there might be risks, constraints, or limitations that might impact the project. Your job is to identify them and help the project team to plan mitigation strategies. These risks can be in the form of regulatory issues or external dependencies. 

For example - Imagine there’s a new product development project. Here, you’ll be wondering what steps can we take in order to ensure project completion. A project charter that highlights risks like supply chain delivery delays or unforeseen regulatory hurdles, will be helpful. 

8. Approval and sign-off:

The relevant stakeholders and key decision makers take part in giving their final approval on the project charter. This process acts as a record of agreement to the scope, resources, and project’s objectives. 

For example - If there’s an organizational change; the leadership team and stakeholders’ signatures will be applied to signify their commitment.

 

How to Write a Project Charter in 8 Steps

Creating a project charter isn't as easy as it looks. You'll need to look at the project's objectives, goals, and scope. Here are the key steps that help you create a good project charter.

Step 1: Confirm the Business Case and Project Sponsor

The business case not only guides project decisions but also ensures that everyone involved in the project is aligned with its purpose. 

You will need to identify who will be the project sponsor, team members, project managers and confirm their presence with respect to the new project. They shall be the point of contact for communicating key updates of the project. 

Example: For a product development project, the stakeholders include: project sponsor, the project manager, and the design team. 

Step 2: Draft the Purpose Statement in Two Sentences

Here comes the crucial step where you share your project objectives and draft its purpose. Start by outlining the project’s importance and key objectives systematically. The project’s purpose must clearly explain why the project is crucial for business success and how it will lend a helping hand to your organization’s goals. 

Step 3: Convert goals into measurable objectives: 

As you are writing down the objectives for the first time, you might think of mentioning every detail. However, keeping these objectives short is recommended. It is advisable to follow the SMART method which highlights the objectives that’s specific, measurable, achievable, realistic and time-bound. 

Let’s show you an example of good and a bad project objective

(A) Bad: The launch of a new home page 

Many important characteristics are missing in this project’s objective. Although they are measurable, achievable, and realistic; it isn’t specific or time bound. 
(B) Good: Net-new home page assets and copy
They focus on 4 use cases and customer stories. Refresh the page with a customer-centric home page by the end of Q2.  

• Specific: This is with respect to creating a net-new home page assets and copy
• Measurable: Here, we're speaking about launching a fresh customer-centric home page
• Achievable and realistic: Next, we give importance to adding four customer stories and use cases
• Time-bound: Here, we are specifying by when the project needs to be completed [by the end of Q2] 

For setting project objectives effectively, involve the project team in the goal setting process. With their rich experience, they shall surely help in the overall development of the project. 

Step 4: Define the Scope Boundary and Name Exclusions

Once objectives are set, you need to define the project’s boundaries. This includes deadlines, goals, and deliverables of the project. Having a clear scope shall help you to stay focused on achieving your goals without much delay

Aligning with key project stakeholders is crucial in setting project scope. This ensures project boundaries are being agreed upon. If you are looking at a product marketing launch, the team might include 

• The product team
• The design team
• The content team 

To make things simpler, consider looking at a project scope statement - a written document that specifies your project scope. A scope statement can be a section of the project plan or project brief. 

Step 5: List deliverables and top-level milestones

Tangible and intangible outputs generated by your team during month end are known as project deliverables. Listing these deliverables upfront will help your team prioritize tasks effectively. 

Let’s understand why deliverables are important 

• Focus gets improved: Once your team knows what needs to be done, they perform their tasks more productively and efficiently. Not to mention, measuring team performance becomes easier.
• Better communication: Instead of having vague updates, teams can now pinpoint to specific outputs like completed or in progress.

On the other hand, top-level milestones are checkpoints which help mark progress as the team moves forward with the project. They give you a signal that you’re on track. 

Step 6: Estimate Budget, Resources, and Timeline Ranges

The total projected costs which are required to complete a given project is known as project budget. Here, we look at labor costs, operating costs, and procurement costs. Throughout the project, the budget will be revived and reviewed with the use of a project budgeting software. 

Next, we will evaluate the kind of resources we need to execute the project as per the timeline. 

Step 7: Capture assumptions, constraints, and risks

When we look at this step, there’s a need to identify potential risks and constraints. This can impact the project’s proceedings by making a few assumptions about uncertain factors. As a solution, let’s consider the following. 

(a) Identify potential risks - This is with respect to finding potential risks that can negatively impact the outcome of the project. 

(b) Define project constraints - Find any limitations that can impact the project. This includes timeline, budget, and resource availability. 

(c) Capture assumptions - Acknowledge uncertainties about factors that aren’t known to you. Capture assumptions on market conditions, user behavior, and technical feasibility. 

(d) Create a risk management plan - Identify strategies for mitigating risks and then reduce project’s impact. A contingency plan will be useful. You can also establish early warning systems or allocate resources in managing the risks. 

Step - 8: Route the Charter for Review and Secure Sponsor Sign-Off

This is the last and the most important step whereby stakeholders and subject matter experts get involved to review the project charter. Here, the feedback is gathered to make suitable changes if required. 

Project Charter Writing Guide: Weak vs Strong Examples

A project charter is only as useful as the clarity behind its words. Having a clear understanding on the 5 stages of project management is crucial for writing a good project charter. Below is a breakdown of common charter components, paired with weak and strong examples to illustrate the difference.

Purpose and Justification

The purpose statement should explain why the project exists and what business problem it solves. A weak version stays abstract and forgettable. A strong version ties directly to a business outcome.

Weak: "This project will improve customer experience."

Strong: "This project will reduce average customer support resolution time from 48 hours to under 12 hours by implementing an AI-powered ticket routing system, addressing a 23% increase in unresolved tickets reported in Q2."

The strong version works because it names the mechanism, the metric, and the current pain point. Anyone reading it, whether a sponsor or a new team member, immediately understands the stakes.

Objectives and Success Criteria

Objectives fail when they read like intentions rather than commitments. Strong objectives follow SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound) and leave no room for interpretation.

Weak: "Increase user engagement on the platform."

Strong: "Increase daily active users by 15% within six months of launch, measured through platform analytics, with a target baseline improvement validated by the product analytics team by the end of Q1."

Notice how the strong example specifies a percentage, a timeframe, a measurement method, and ownership. This is the difference between a wish and a deliverable.

Scope definition

Scope statements are where most charters fall apart, because teams often describe what the project includes but forget to state what it explicitly excludes.

Leaving out-of-scope items unstated is one of the most common causes of scope creep. Stating them explicitly gives project managers a reference point when stakeholders request additions mid-project.

Stakeholder roles and responsibilities

A charter that lists names without defined authority creates confusion about who can approve changes or unblock decisions.

Weak: "John from marketing and Sarah from IT will be involved."

Strong: "John Mathews (Marketing Director) serves as project sponsor with budget approval authority up to ₹5 lakh. Sarah Chen (IT Lead) owns technical delivery and reports weekly status to the sponsor. The steering committee, comprising the CFO and CTO, approves any scope changes exceeding ₹10 lakh."

The strong version answers three questions at once: who decides, who executes, and where the decision boundaries lie. This structure prevents the common problem of decisions stalling because no one is certain who has the authority to make them.

Budget and resource allocation

Vague budget language invites disputes later, especially when costs run over.

Weak: "The project has a reasonable budget for staffing and tools."

Strong: "Total approved budget is ₹42 lakh, allocated as ₹28 lakh for a five-person development team over four months, ₹9 lakh for third-party API licensing, and ₹5 lakh contingency reserve requiring sponsor approval for use."

Breaking the budget into categories with a defined contingency reserve gives the project manager flexibility while still keeping spending transparent and traceable.

Risk identification

Weak risk sections list generic concerns without context. Strong ones connect risks to likelihood, impact, and a mitigation owner.

Weak: "There is a risk of delays."

Strong: "Risk: Third-party API vendor has a historical delivery delay rate of 30% based on past engagements. Impact: Could push launch by four to six weeks. Mitigation: Parallel evaluation of a backup vendor initiated in week two, owned by the procurement lead."

This format transforms risk management from a formality into a working tool the team can actually reference during execution.

Project Charter Template You Can Copy

One-Page Project Charter Template for Small Projects

Full Project Charter Template for Enterprise and PMO Governance

3 Project Charter Examples Across Industries

Charters look different depending on the industry they serve. This is because the risks, deliverables, and stakeholder expectations shift with the domain. The three examples below show how the same document structure adapts to very different project realities. 

Example 1: IT Services - Application Modernization

An Indian IT services firm modernizing a legacy banking application for a client would frame its charter around technical risk and business continuity. The business case would cite the client's aging COBOL-based core system, which currently costs 40% more in annual maintenance than a modernized equivalent and cannot support upcoming regulatory reporting requirements. 

The objective would state a target: migrate 100% of transaction processing modules to a cloud-native architecture within nine months while maintaining zero downtime during business hours.

Scope would explicitly include the core transaction engine, reporting layer, and API gateway, while excluding the client's mobile banking front end, which is handled by a separate vendor. Stakeholder roles would name a client-side sponsor with final sign-off authority, a delivery lead from the IT services vendor accountable for sprint output, and a joint architecture review board empowered to approve any changes to the technical approach. 

Given the regulated nature of banking systems, this charter would run long and formal, closer to twenty pages, because compliance auditors and multiple vendor teams need a single point of reference.

Example 2: Construction - Commercial Fit-Out

A commercial office fit-out project for a co-working space brand illustrates how physical, timeline-bound work drives a different charter emphasis. The business case would center on a signed lease requiring occupancy readiness by a fixed date, since delays here carry direct penalty clauses rather than abstract business risk. 

The goal statement would specify completion of electrical, HVAC, flooring, and partition work across 15,000 square feet within 90 days, inspected and certified for occupancy by the local municipal authority.

Scope exclusions matter heavily in construction charters because contractors and clients frequently disagree over what counts as base building work versus tenant improvement. This charter would explicitly exclude structural modifications to the building shell and landlord-owned common areas. 

Risk sections would flag material procurement delays, since imported fixtures or specialized flooring often face longer lead times, and would name a procurement lead responsible for tracking supplier commitments weekly. 

The budget would be broken down by trade: electrical, civil, interiors, and contingency, with a defined threshold above which the client must approve additional spend.

Example 3: Marketing - Product Launch Campaign

A D2C brand launching a new protein-rich snack line, a category closely aligned with clean-label and health-conscious positioning, would build a charter around market timing and measurable reach rather than technical delivery. 

The business case would justify the campaign against a competitive gap, noting that rival brands captured a defined share of the healthy-snacking category in the past year without a comparable protein claim. 

The objective would set a concrete target: achieve 500,000 social media impressions and 10,000 units sold within the first 60 days of launch across e-commerce and quick-commerce platforms.

Scope would cover influencer partnerships, paid social campaigns, and packaging design, while excluding retail shelf placement negotiations, which run as a separate workstream owned by the sales team. Stakeholder roles would name the brand manager as sponsor with creative approval authority, the performance marketing lead as budget owner for paid spend, and a legal reviewer responsible for clearing health and nutrition claims before publication, an increasingly important checkpoint given regulatory scrutiny of food labeling claims in India.

Project Charters in Agile and Six Sigma Environments

Not every methodology treats the charter the same way. Agile and Six Sigma both rely on the document, but they shape it around different priorities: adaptability in one case, statistical rigor in the other.

How Agile Teams Use Project Charters?

Agile teams treat the charter as a living reference rather than a fixed contract. Where a traditional charter runs ten to thirty pages and locks down scope, timeline, and budget before work begins, an Agile charter is typically one to two pages focused on product vision, team composition, and boundaries around what is in and out of scope. Instead of fixed milestones, it sets release targets with flexible scope, and instead of a formal change request process, it evolves through backlog refinement and gets revisited during retrospectives.

The Project Management Institute's own Agile Practice Guide states that at minimum, an agile project needs a clear vision or purpose along with a set of working agreements among the team, which is a much lighter bar than the exhaustive documentation traditional charters demand. This does not mean Agile teams skip governance entirely. Stakeholder involvement is often more collaborative under this model, with the charter created jointly by the team and stakeholders rather than handed down solely by a sponsor or project manager. Risk management also shifts from a one-time upfront analysis to an ongoing assessment woven into every sprint.

The practical implication for teams working in fast-moving product or software environments is that the charter functions less like a legal authorization and more like a compass. It answers "what problem are we solving and who is authorized to solve it," while the specifics of what gets built emerge iteratively through the backlog.

How Does a DMAIC Project Charter Differ?

Six Sigma's DMAIC framework (Define, Measure, Analyze, Improve, Control) produces a charter that looks structurally similar to a traditional one but carries a distinctly statistical flavor. It anchors the Define phase and typically includes a business case, problem statement, goal statement, project scope, timeline mapped to DMAIC tollgates, and team structure covering the Sponsor, Champion, and Black or Green Belt roles.6sigma+2

The defining difference is measurement discipline. A DMAIC charter emphasizes process metrics such as defect rate, sigma level, cycle time, and yield, and often maps process boundaries using the SIPOC model, which stands for Supplier, Input, Process, Output, and Customer. The problem statement must include quantifiable data supporting the existence of the problem, not just a description of it, and the goal statement must close the specific performance gap identified in that problem statement, a stricter coupling than most traditional charters require.projectchartertemplate+2

Milestones in a DMAIC charter map directly to the five DMAIC phases rather than generic project stages: the Define phase produces the charter and data collection plan, Measure establishes baseline data, Analyze identifies root causes, Improve implements the solution, and Control sustains the gains through a formal control plan. This phase-by-phase tollgate structure is what most clearly separates a Six Sigma charter from a general project charter, and it reflects the methodology's origin in manufacturing and process quality rather than deliverable-based project work

Getting Your Project Charter Approved: The Sign-Off Workflow

Approval is not a single signature moment. It is a sequence of checkpoints that determines whether a charter is solid enough to authorize real spending, staffing, and delivery commitments. Here is how the workflow typically unfolds.

• Collaborative drafting. Stakeholders, technical leads, and in agile or hybrid contexts, product owners, contribute input before the charter is finalized. A charter drafted in isolation tends to generate objections later that could have been resolved at this stage instead.
• Internal alignment check. Before the charter reaches the sponsor, the project manager verifies that the business case, budget figures, and scope align with what was already discussed in earlier funding or planning conversations, so there are no surprises during formal review.
• Sponsor review. The sponsor examines whether the proposed budget, timeline, and scope match the project's actual funding and priority. This is also when governance details get built into the document, including how future change requests will be submitted and who has authority to approve them.
• Stakeholder and governance board input. For projects tied to a steering committee, client-side governance board, or regulatory function, the charter often needs sequential approvals rather than a single sign-off, particularly when budget thresholds or compliance considerations are involved.
• Revision cycle. Any objections raised during review get addressed here. Disputed sections, most often scope, budget, or timeline, are renegotiated and updated before the document moves forward again.
• Version control and documentation. Many organizations now store charters in a shared, version-controlled platform such as Confluence or a project management tool rather than as a static file, so the approval history and any amendments stay visible to everyone involved.
• Formal sign-off. The sponsor's signature or explicit written approval is circulated and recorded. Making this visible across the team matters, because everyone can see who authorized the project and under what terms, which reinforces accountability from the outset.
• Post-approval communication. Once signed, the charter is shared with the full project team and relevant stakeholders so that everyone starts from the same understanding of scope, authority, and success criteria.
• Periodic revisit. For longer projects, the charter is not filed away after sign-off. It gets reviewed again at phase gates or major milestones to confirm it still reflects the project's direction, especially in hybrid delivery models where scope can shift gradually.

Common Project Charter Mistakes That Cause Scope Disputes

Most scope disputes trace back to gaps that existed in the charter from day one, not to genuine surprises that emerged during execution. Recognizing these patterns early prevents the kind of mid-project conflict that derails timelines and strains stakeholder relationships.

• Ambiguous or unrefined scope definition. This is consistently cited as the leading cause of scope creep, because when boundaries are described loosely, every stakeholder interprets them differently, and each interpretation becomes a potential point of conflict later.
• Overloaded scope from the start. Charters that try to capture every feature or requirement upfront make scope creep almost inevitable, since there is no prioritization framework to fall back on when trade-offs are needed. A tighter approach, such as defining a minimum viable scope and using a prioritization method like MoSCoW, keeps the document focused.
• Missing exclusions. A charter that lists what is included but never states what is excluded leaves a gap that stakeholders will eventually fill with their own assumptions, usually in a direction the project manager did not intend.
• No formal change control process. Without a documented path for submitting, assessing, and approving change requests, changes get absorbed informally, often without anyone evaluating the schedule or budget impact before agreeing to them.
• Lack of sponsorship and stakeholder involvement during drafting. When sponsors do not actively shape the charter's scope language, it often defaults to generic phrasing that later fails to hold up against a stakeholder's specific expectations.
• Vague resource and budget allocation. A charter that does not clearly define bandwidth, budget, and expected outcomes leaves room for disagreement about what the project was actually funded to deliver, which becomes a recurring source of tension as costs run over.

The pattern across all of these mistakes is the same: specificity prevents disputes, while vagueness defers them. A charter that states clear exclusions and a defined change process does not eliminate scope pressure entirely, but it gives the project manager a documented basis to say no, or to negotiate a trade-off, rather than absorbing every request informally.

Project Management Training for Stronger Project Initiation

Writing a strong charter is a skill that improves with structured learning, not just repetition. Formal project management training, whether through certifications like PMP, CAPM, or Six Sigma belts, or through targeted workshops on Agile charter writing, gives project managers a shared vocabulary and a repeatable framework for the initiation phase rather than relying on trial and error across projects.

This is particularly relevant for professionals working across methodologies, since a project manager fluent only in traditional charter writing may struggle to produce the leaner, vision-focused charters that Agile teams expect, and vice versa. 

Training that covers both approaches, along with the statistical rigor DMAIC charters demand, positions a project manager to adapt the charter format to the actual delivery model rather than forcing every project into the same template. 

For those working in India's fast-growing IT services and digital delivery sectors, where hybrid methodologies are common and client-side governance expectations often lean traditional even when internal delivery is Agile, this dual fluency is becoming less of a specialization and more of a baseline expectation.

Beyond formal certification, mentorship from experienced sponsors and post-project retrospectives that specifically examine whether the original charter held up against what actually happened are underused but valuable training tools. They turn every completed project into a case study for what the next charter should do differently, closing the loop between initiation and delivery in a way that classroom training alone cannot.

Conclusion

A project charter earns its value not from its length or formality, but from how precisely it answers the questions that will otherwise resurface as disputes: what problem justifies the project, what is explicitly in and out of scope, who holds decision authority, and how success will be measured. 

Whether the context is a regulated IT modernization project, a time-bound construction fit-out, a fast-moving marketing launch, an Agile product team, or a statistically driven DMAIC initiative, the underlying discipline stays consistent. Specific, measurable, and clearly owned language at the charter stage prevents the ambiguity that later shows up as scope creep, budget conflict, or stalled decisions.

Writing a strong charter is ultimately a project initiation skill, and like any skill, it sharpens with structured training rather than trial and error across projects.