Project Management for Solopreneurs

Project management is the structured planning and control of temporary work undertaken to produce a defined result. For a solopreneur, that result might be a new website, digital product, service, migration, research report, content hub, automation system, or client deliverable.

What Is Project Management?

The PMI definition describes a project as a temporary endeavor undertaken to create a unique product, service, or result. Project management applies the decisions, plans, resources, controls, and communication required to move that endeavor from authorization to completion.

A project has:

• A defined reason for existing
• A temporary beginning and end
• A unique intended result
• One or more deliverables
• Limited time, money, attention, or capacity
• Uncertainty that must be managed
• People or systems affected by the result
• Conditions under which the work succeeds, fails, pauses, or ends

Project management answers questions such as:

1. Why should this project exist?
2. What outcome must it produce?
3. What is included and excluded?
4. What evidence will prove completion?
5. Which work is required?
6. In what order should it happen?
7. What depends on what?
8. How much capacity and money can be committed?
9. What could prevent success?
10. How will changes be evaluated?
11. When should the project continue, change direction, pause, or stop?
12. How will the result enter normal business operations?

It is not simply the use of project-management software. A board, timeline, or template can display project information, but it cannot determine whether the project is worth doing or whether its result creates value.

Project Management in a One-Person Business

In a larger organization, project responsibilities may be distributed among a sponsor, project manager, subject-matter experts, finance team, delivery team, and operational owner.

A solopreneur may perform all of these roles:

These roles still exist when one person fills them. Making them explicit prevents one perspective from dominating every decision.

The contributor may want to continue polishing. The investor may prefer to stop. The customer representative may need a simpler result. The operational owner may reject a solution that would be expensive to maintain.

Good solopreneur project management creates enough separation between these perspectives to make deliberate decisions.

Project vs. Task, Workflow, Process, Operation, and Product

Not every piece of work should become a project.

A website launch can be a project. Updating the website every week is an operation. Each update can move through a workflow. A major redesign may become another project.

The distinction matters because projects must end. If the work has no finish condition and must continue indefinitely, it should eventually move into an operational process, recurring service, or product-management system.

When Work Deserves Project Management

Treat work as a project when several of the following conditions apply:

• The result is unique rather than routine
• Several deliverables must fit together
• The work spans multiple weeks or phases
• Sequence and dependencies affect completion
• A client, contractor, partner, or specialist is involved
• The work requires a meaningful financial commitment
• Failure could create significant commercial, legal, technical, or reputational harm
• Requirements are uncertain or likely to change
• The result must be tested, approved, launched, or transferred
• Existing operations must continue while the work is performed
• The project could consume capacity needed elsewhere
• Success must be evaluated after delivery

A small piece of work may need only a result, owner, deadline, and checklist. Adding a project structure to a two-hour task can cost more than it protects.

The purpose of project management is not to make work appear important. It is to reduce the uncertainty and coordination cost of creating a result.

What Project Success Means

Traditional project reporting often emphasizes scope, schedule, and budget. These remain useful delivery controls, but they do not fully describe success.

A project can finish on time and within budget while producing something customers do not use. It can also exceed an early estimate while creating far more value than expected.

Evaluate success across four levels.

1. Delivery success

Did the project produce the agreed deliverables within the authorized constraints?

Measures may include:

• Acceptance criteria passed
• Required scope delivered
• Target date met
• Budget respected
• Mandatory quality checks passed
• Material risks controlled

2. Adoption success

Did the intended users or operating systems begin using the result?

Measures may include:

• Activation rate
• Migration completion
• Usage frequency
• Process compliance
• Customer onboarding completion
• Reduction in use of the replaced method

3. Outcome success

Did the project create the intended change?

Measures may include:

• Increased conversion rate
• Reduced delivery time
• Lower error rate
• Higher retention
• More qualified inquiries
• Reduced operating cost
• Increased recurring revenue
• Improved service capacity

4. Investment success

Was the value worth the money, attention, risk, and opportunity cost?

Measures may include:

• Payback period
• Return on investment
• Cost avoided
• Capacity released
• Revenue protected
• Strategic option created
• Risk reduced
• Knowledge gained

Recent PMI research defines successful projects as those that deliver value worth the effort and expense. Its 2026 study included 2,023 project professionals and 511 senior leaders across 35 countries. It found that 31% of complex projects failed to achieve the full scope of their intended benefits.

This is organizational research, not a direct solopreneur benchmark. Its useful lesson is that completing deliverables and realizing benefits are different achievements.

Define both before starting:

• Project finish: What must be delivered and accepted?
• Benefit realization: What should improve after the result enters use?

Start With the Project Decision

Project management begins before planning. The first decision is whether the project deserves scarce business capacity.

A project should not be approved merely because:

• The idea is interesting
• A competitor has done it
• A new tool makes it possible
• Work has already started
• A contractor is available
• The project has been discussed for months
• The owner feels guilty about postponing it
• Completing it would make the business look busier

Create a short project case.

Problem or opportunity

Describe the current condition.

Example:

“New consulting inquiries receive inconsistent information, and each proposal requires approximately two hours of manual reconstruction.”

Intended outcome

Describe what should become true.

Example:

“Qualified prospects can understand the service, provide the required information, and receive an accurate proposal without rebuilding the same material for every inquiry.”

Beneficiary

Identify who receives the value:

• Customer
• Business owner
• Contractor
• Partner
• Search visitor
• Subscriber
• Operational system

Expected value

Estimate what the project could create or protect:

• Revenue
• Margin
• Time
• Capacity
• Customer trust
• Strategic access
• Risk reduction
• Learning
• Reusable intellectual property

Total expected cost

Include more than invoices:

• Owner working time
• Contractor fees
• Software and infrastructure
• Research
• Testing
• Migration
• Launch
• Training
• Maintenance setup
• Displaced work
• Contingency

Evidence

State what makes the opportunity credible:

• Customer requests
• Sales data
• Search demand
• Support history
• Delivery records
• Financial data
• Experiment results
• Regulatory requirement
• Technical limitation
• Contractual obligation

Alternatives

Compare the proposed project with:

• Do nothing
• Repair the existing method
• Reduce the scope
• Buy an existing solution
• Outsource the result
• Run a small experiment
• Delay until a dependency changes

The best response to a problem is not always a project.

Rank Projects Before Starting Them

A solopreneur’s primary project constraint is usually not ideas. It is focused execution capacity.

Score proposed projects against consistent criteria.

A simple priority calculation is:

Priority score = expected value × confidence × strategic fit ÷ estimated effort

Use a consistent scale, such as 1 to 5. The result is a decision aid, not an objective truth. A mandatory security repair may deserve priority even if its immediate revenue score is low.

Limit the number of simultaneously active projects. Starting five strategic projects does not create five times the strategic capacity.

Create a One-Page Project Charter

A project charter authorizes the work and establishes the initial decision boundary.

For most solopreneur projects, one page is enough.

Project name

Use a result-oriented name.

Weak:

“New website”

Stronger:

“Launch the self-service consulting website”

Reason

Why should this project happen now?

Intended outcome

What business or customer condition should change?

Deliverables

What tangible outputs must exist?

Non-goals

What is intentionally excluded?

Acceptance criteria

What observable evidence will prove that each deliverable is acceptable?

Success measures

Which delivery, adoption, outcome, and investment measures will be reviewed?

Constraints

What cannot be exceeded or changed?

Assumptions

What is currently believed to be true but has not been guaranteed?

Dependencies

What must arrive, happen, or remain available?

Budget and capacity

How much cash and owner time are authorized?

Target dates

What are the main decision, delivery, and launch dates?

Decision authority

Who approves changes, accepts deliverables, or stops the project?

Stop conditions

Under what circumstances should the work pause or end?

A charter is not a complete plan. It is an authorization agreement that prevents the project from quietly becoming something else.

Define Outcomes Before Deliverables

An outcome describes the change the project should create. A deliverable is an output produced by the project.

Example:

Outcome:

“Reduce the time required to qualify and propose new client work.”

Deliverables:

• Service information page
• Qualification form
• Proposal template
• Pricing calculator
• Automated confirmation email
• Internal review checklist

Producing all six deliverables does not guarantee the outcome. They may be confusing, unused, poorly integrated, or aimed at the wrong customer.

Connect each major deliverable to the outcome it supports.

If a deliverable has no clear contribution, remove it or explain why it remains necessary.

Define Scope With Boundaries

Scope is the complete set of authorized project outputs and required work.

A scope statement should include:

• The intended result
• Required deliverables
• Required capabilities
• Quality expectations
• Included users, markets, products, or systems
• Required integrations
• Data to be created or migrated
• Testing and approval requirements
• Launch or transition work
• Documentation required for ongoing use
• Explicit exclusions

Exclusions are particularly important.

For a website-launch project, exclusions might include:

• Multilingual content
• Custom customer accounts
• A mobile application
• Historical content migration
• Advanced personalization
• Ongoing search optimization
• Paid advertising after launch

An exclusion is not a promise that the work will never happen. It means the current project has not funded, scheduled, or authorized it.

Write Acceptance Criteria

Acceptance criteria convert broad expectations into observable conditions.

Weak criterion:

“The website looks professional.”

Stronger criteria:

• The five approved page templates match the agreed design system
• Checkout completes successfully using the required payment methods
• Transactional emails are delivered after a test purchase
• Required pages display correctly at the agreed mobile and desktop widths
• No critical or high-severity accessibility defects remain
• Analytics records the agreed conversion events
• The owner can update standard page content without developer assistance

Acceptance criteria should be:

• Specific
• Observable
• Relevant to the intended result
• Testable at a reasonable cost
• Agreed before substantial production begins

Avoid criteria that depend entirely on unrecorded personal judgment.

Separate Constraints, Assumptions, and Dependencies

These categories often appear together but require different management.

Constraint

A condition the project must work within.

Examples:

• Maximum budget of €5,000
• Launch before a contractual deadline
• Use of an existing platform
• No collection of sensitive health data
• Maximum of eight owner hours per week

Assumption

A belief used for planning that may prove false.

Examples:

• The contractor will remain available in September
• Existing customer data can be imported
• The payment provider will approve the account
• Customers will understand the new pricing structure

Dependency

Something required from outside the immediate project work.

Examples:

• Final copy from the client
• Domain verification
• Legal review
• API access
• Contractor delivery
• Product photographs
• App-store approval

Review assumptions throughout the project. Once an assumption is confirmed, rejected, or converted into a dependency, update the plan.

Choose the Right Delivery Approach

Project management does not require one universal method.

The current ISO guidance applies across project sizes and allows predictive, incremental, iterative, adaptive, and hybrid delivery approaches.

Predictive approach

Define most of the result and plan before production.

Use it when:

• Requirements are stable
• The result is well understood
• Change is expensive
• A fixed compliance or contractual standard applies
• The work has strong physical or technical sequencing

Examples:

• Office relocation
• Legal entity closure
• Migration with a fixed data specification
• Production of an approved print asset

Iterative approach

Develop the result through repeated refinement.

Use it when:

• The broad outcome is known
• Quality depends on feedback
• Several versions are expected
• The best design cannot be specified in advance

Examples:

• Brand identity
• Sales-page copy
• User experience
• Course curriculum

Incremental approach

Deliver usable parts separately.

Use it when:

• Value can appear before the complete scope is finished
• Deliverables can operate independently
• Earlier release reduces risk
• Feedback from one increment should affect the next

Examples:

• Publishing one topic cluster at a time
• Launching one product category before the full marketplace
• Migrating customers in controlled groups

Adaptive approach

Plan in short horizons and revise direction as evidence changes.

Use it when:

• Requirements are highly uncertain
• Technology or market conditions change quickly
• Experiments are required
• The route to the outcome cannot be predicted reliably

Examples:

• Developing a new business model
• Exploring an unfamiliar acquisition channel
• Building an AI-supported service with uncertain quality

Hybrid approach

Use different methods for different parts.

A digital-product project might use:

• Predictive planning for tax and payment requirements
• Iterative development for the product content
• Incremental release for modules
• Adaptive experiments for customer acquisition

Choose the approach based on uncertainty and cost of change, not fashion.

Design the Project Life Cycle

A practical solopreneur project life cycle can contain six stages.

1. Selection

Decide whether the opportunity deserves investment.

Output:

• Project decision
• Initial value case
• Priority
• Authorized discovery budget

2. Definition

Clarify the outcome, boundaries, stakeholders, assumptions, and acceptance criteria.

Output:

• Project charter
• Defined deliverables
• Initial risks
• Decision authority

3. Planning

Design how the authorized result will be produced.

Output:

• Deliverable breakdown
• Estimates
• Schedule
• Budget
• Dependencies
• Risk responses
• Communication method

4. Delivery

Produce, review, and integrate the deliverables.

Output:

• Completed components
• Tested increments
• Decisions
• Approved changes
• Updated forecasts

5. Transition

Put the result into real use.

Output:

• Deployment or launch
• Data migration
• Customer or user communication
• Operating instructions
• Ownership transfer
• Support preparation

6. Closure and evaluation

Accept the result, close commitments, preserve knowledge, and schedule outcome measurement.

Output:

• Formal acceptance
• Closed contracts and invoices
• Archived decisions
• Lessons recorded
• Remaining work transferred
• Benefit-review date

A stage should end with a decision, deliverable, or verified condition—not merely the passage of time.

Use Decision Gates

A decision gate is a point where the project must earn further investment.

Possible gates include:

• Approve the business case
• Approve the solution
• Approve production
• Approve launch
• Accept the delivered result
• Continue, change direction, pause, or stop

At each gate, ask:

1. Is the intended outcome still valuable?
2. Is the evidence stronger or weaker?
3. Has the expected cost changed?
4. Are the main assumptions still credible?
5. Have new risks appeared?
6. Does the project still fit current strategy?
7. Is continued investment better than the available alternatives?
8. What must be true before the next gate?

Past expenditure should not decide future expenditure. Money and time already spent are sunk costs. The relevant question is whether the remaining investment is justified by the remaining expected value.

Break the Project Down by Deliverables

Begin with outputs, not isolated actions.

For a course-launch project, the first level might be:

1. Validated course concept
2. Course curriculum
3. Recorded lessons
4. Student materials
5. Sales system
6. Delivery platform
7. Launch campaign
8. Support system

Break each deliverable into smaller components until the work can be:

• Estimated
• Assigned
• Sequenced
• Verified
• Completed within a manageable period

Do not break work down so far that the plan becomes a diary of minor actions.

A useful project plan shows enough detail to make decisions about scope, capacity, sequence, risk, and completion.

The task-management system can contain the actions required to perform the plan. The project plan should retain the relationships between those actions and the intended deliverables.

Create Milestones That Prove Progress

A milestone is a meaningful zero-duration event that shows a deliverable, decision, approval, or transition has occurred.

Useful milestones include:

• Concept validated
• Requirements approved
• Prototype accepted
• Content complete
• Payment integration verified
• Migration test passed
• Launch authorized
• First customer completed onboarding
• Project accepted and closed

Weak milestones include:

• Work started
• Fifty percent complete
• Continue development
• General progress

A percentage can hide uncertainty. A project may appear 90% complete for weeks because the unresolved final 10% contains integration, approval, or technical risk.

Prefer evidence-based milestones.

Identify Dependencies Before Setting Dates

A dependency means one item cannot begin or finish until another event or output exists.

Common dependency relationships include:

• Finish-to-start: Copy must be approved before page production begins
• Start-to-start: Testing can begin after development starts
• Finish-to-finish: Documentation cannot finish before the final interface is stable
• External dependency: Launch requires payment-provider approval

Create a dependency list containing:

• Required item or event
• Dependent work
• External owner
• Required date
• Current confidence
• Confirmation status
• Effect of delay
• Fallback

The project’s finish date is controlled by the longest chain of dependent work, not the total number of tasks.

Pay particular attention to:

• One-person specialist work
• Client approvals
• Platform reviews
• Data access
• Legal or financial decisions
• Physical delivery
• Seasonal launch windows
• Work that cannot be parallelized

A short task on the critical dependency chain can matter more than a long independent task.

Estimate With Ranges

A single estimate hides uncertainty.

For important work, record:

• Optimistic estimate
• Most likely estimate
• Pessimistic estimate
• Assumptions behind the range
• Confidence level
• Main causes of variation

A simple three-point expected estimate is:

Expected estimate = (optimistic + 4 × most likely + pessimistic) ÷ 6

Example:

• Optimistic: 10 hours
• Most likely: 16 hours
• Pessimistic: 30 hours

Expected estimate:

(10 + 4 × 16 + 30) ÷ 6 = 17.3 hours

The formula does not eliminate uncertainty. It prevents an optimistic scenario from silently becoming the official plan.

Estimate different categories separately:

• Production time
• Review and correction time
• Dependency waiting
• Learning time
• Integration
• Testing
• Launch
• Transition
• Project administration

Do not treat elapsed duration and working effort as the same quantity. Eight hours of work may require three weeks if it depends on several external responses.

Account for Effective Capacity

A solopreneur may have 40 nominal working hours in a week without having 40 project hours.

Capacity is also required for:

• Customer delivery
• Sales
• Support
• Financial administration
• Maintenance
• Health and recovery
• Unexpected operating problems
• Existing project commitments

Use:

Effective project capacity = available working time − operating commitments − protected contingency

If 35 hours are available, operations require 22, and five are protected for uncertainty, project capacity is eight hours.

A simple duration forecast is:

Estimated duration = remaining project effort ÷ effective weekly project capacity + unavoidable waiting

If a project has 80 hours of remaining work and receives eight effective hours each week, it needs approximately ten working weeks before dependency delays or contingency.

Do not create a six-week commitment by dividing 80 hours by an imaginary full-time project week.

Build a Real Project Schedule

A useful schedule connects:

• Deliverables
• Work packages
• Sequence
• Dependencies
• Capacity
• Milestones
• Decision gates
• External commitments
• Contingency

Build the schedule in this order:

1. List the required deliverables.
2. Break them into manageable work packages.
3. Estimate effort and uncertainty.
4. Identify dependencies.
5. Identify work that can happen in parallel.
6. Apply actual resource capacity.
7. Add decision and review time.
8. Add dependency waiting.
9. Identify the controlling sequence.
10. Add contingency where uncertainty exists.
11. Set milestone and forecast dates.
12. Check the result against the value case.

Do not begin with an attractive launch date and force every estimate to fit it.

If the date is fixed, at least one other variable must remain negotiable:

• Scope
• Cost
• Quality threshold
• Delivery method
• Capacity
• Risk exposure

Some quality, safety, legal, or security conditions should not be negotiable. In those cases, reduce scope, increase capacity, or change the date.

Budget for the Whole Project

A project budget should include:

Direct cash cost

• Contractor fees
• Software
• Equipment
• Hosting
• Licences
• Advertising
• Legal or financial advice
• Research materials

Owner capacity cost

Owner hours committed to the project cannot be used for other delivery, growth, or recovery.

Choose an internal capacity value for comparison, even if no money changes hands.

Transition cost

Include:

• Migration
• Customer communication
• Training
• Documentation
• Temporary duplicate systems
• Launch support
• Data cleanup

Operating impact

Estimate what happens after launch:

• Monthly software fees
• Customer-support demand
• Content updates
• Technical maintenance
• Contractor dependence
• Compliance work
• Data storage
• Quality review

Contingency

Contingency covers identified uncertainty. It should not conceal an incomplete estimate.

Keep a separate management reserve for significant unforeseen events when the project justifies it.

Total project cost can be expressed as:

Total expected cost = cash cost + owner capacity cost + transition cost + expected risk cost

Expected risk cost can be estimated as:

Probability of risk × financial effect if it occurs

This is not precise forecasting. It creates a more complete investment comparison.

Manage Project Risk

A risk is an uncertain event or condition that could affect the project. An issue is a problem that has already occurred.

Create a short risk register.

Common solopreneur project risks include:

• Owner illness or reduced capacity
• Dependency on one contractor
• Client approval delay
• Underestimated learning
• Tool or platform limitation
• Failed data migration
• Cost increase
• Unclear rights to content or software
• Customer rejection
• Security or privacy defect
• Launch during an unsuitable market period
• New work disrupting existing customers
• Maintenance requirements exceeding capacity

Possible responses are:

• Avoid: Change the plan so the risk no longer exists
• Reduce: Lower its probability or impact
• Transfer: Shift defined exposure through insurance or contract
• Accept: Monitor it without preventive action
• Exploit: Increase the probability of a beneficial opportunity
• Contingency: Prepare a response if the event occurs

The most useful risk response changes current behavior. “Monitor closely” is incomplete unless it defines what will be monitored, how often, and what evidence triggers action.

Manage Stakeholders

A stakeholder is anyone who can affect the project, is affected by it, or believes they may be affected by it.

A solopreneur project may involve:

• Customers
• Client representatives
• Contractors
• Partners
• Suppliers
• Accountants
• Lawyers
• Platform providers
• Regulators
• Family members affected by the commitment
• The owner in several operational roles

For each important stakeholder, record:

• Interest in the project
• Authority
• Information required
• Decisions they control
• Required response time
• Preferred communication method
• Effect of non-response
• Engagement required at each stage

Not every stakeholder needs every update. Communicate the right decision to the right person at the right time.

The 2026 PMI study found that projects rated highly effective at managing complexity were far more likely to be rated successful than projects rated ineffective or only slightly effective. Among the practices associated with stronger performance were sponsor alignment at initiation and phased stakeholder engagement.

For a solopreneur, sponsor alignment can mean writing down the investment case and stop conditions before entering contributor mode.

Establish Decision Rights

A delayed decision can block several dependent activities.

Define:

• Which decisions the owner makes
• Which decisions require client approval
• Which decisions a specialist must make
• Which decisions a contractor may make independently
• The information required for a decision
• The response deadline
• What happens if no decision is received
• Whether the decision can be reversed

Use a decision log for material choices.

Record:

• Date
• Decision
• Decision owner
• Options considered
• Evidence
• Reason
• Consequences
• Conditions that would justify reconsideration

A decision log prevents the project from repeatedly reopening settled questions without new evidence.

Control Project Changes

Projects change because assumptions fail, new information appears, users provide feedback, dependencies move, or better options become available.

Change is not automatically a failure. Uncontrolled change is the problem.

For each proposed material change, record:

1. What is changing?
2. Why is it needed?
3. Which outcome does it support?
4. What happens if it is rejected?
5. How does it affect scope?
6. How does it affect cost?
7. How does it affect the schedule?
8. Which new risk does it create?
9. Which existing work becomes unnecessary?
10. Who has authority to approve it?

A change should produce one of four decisions:

• Approve and update the plan
• Reject
• Defer to a future project or release
• Exchange it for existing scope

“Small” additions accumulate. Track their combined effect rather than evaluating each one in isolation.

Protect the Project From Scope Creep

Scope creep is the uncontrolled expansion of project work without an equivalent adjustment to capacity, budget, schedule, or acceptance conditions.

Common causes include:

• Vague outcomes
• Missing exclusions
• Informal client requests
• Unrecorded assumptions
• Design exploration continuing after approval
• New tools discovered during delivery
• Confusing “useful” with “required”
• Fear of launching an incomplete first version
• Failure to create a later-work list
• No person explicitly responsible for scope decisions

Use a parking lot for valuable ideas outside the current scope. Review them at the next gate rather than inserting them immediately.

Ask of every addition:

“If this becomes part of the current project, what leaves, moves, costs more, or finishes later?”

Track Progress With Evidence

Project status should answer:

• What has been completed and accepted?
• What is being produced now?
• What decision is required?
• What is blocked?
• Which risk has changed?
• What has changed from the previous forecast?
• What is the current completion forecast?
• What requires intervention?

Use evidence such as:

• Accepted deliverables
• Passed tests
• Approved decisions
• Resolved dependencies
• Completed migrations
• Verified customer usage
• Closed defects
• Remaining work estimates

Avoid relying on:

• Hours spent
• Meetings held
• Files created
• Messages sent
• Percentage complete without a defined basis
• How busy the project feels

Activity consumes resources. Progress reduces the remaining uncertainty or work required to reach an accepted result.

Use a Compact Project Dashboard

A small project does not need extensive reporting.

A useful weekly dashboard may contain:

Use status categories consistently.

On track

Current evidence supports the authorized scope, cost, quality, and forecast.

At risk

Success remains possible, but one or more conditions require intervention.

Off track

The existing plan can no longer achieve the authorized result within its constraints.

Do not label a project green merely because no one has updated the evidence.

Forecast Instead of Reporting the Original Plan

The original plan is a baseline. It is not a prediction that must remain unchanged.

At each review, update:

• Remaining effort
• Effective capacity
• Dependency dates
• Expected cost
• Risk exposure
• Scope
• Completion forecast
• Benefit assumptions

A simple schedule variance is:

Schedule variance = current forecast finish date − approved finish date

A simple cost variance is:

Cost variance = forecast total cost − approved budget

Also track value variance:

Value variance = current expected value − originally expected value

A project can remain within budget while its expected value collapses. That should trigger a decision.

Run a Weekly Project Review

A weekly review should be brief enough to maintain and structured enough to expose drift.

Review in this order:

1. Confirm whether the outcome remains valuable.
2. Review accepted deliverables.
3. Review the next milestone.
4. Re-estimate remaining work.
5. Review external dependencies.
6. Review the highest risks and active issues.
7. Review required decisions.
8. Review scope changes.
9. Update cost and finish forecasts.
10. Decide what receives capacity next.
11. Decide whether the project should continue unchanged.

Ask:

• What evidence changed this week?
• What is now the controlling constraint?
• What is older or harder than expected?
• Which assumption is least credible?
• Which deliverable can be simplified?
• What must finish before more work starts?
• Does the project need a decision rather than more activity?

Recover an At-Risk Project

Do not begin recovery by asking everyone to work faster.

1. Restate the outcome

Confirm whether the project is still solving the right problem.

2. Establish the current state

Record:

• Accepted deliverables
• Unfinished work
• Active issues
• Remaining dependencies
• Committed cost
• Forecast cost
• Available capacity
• Current expected value

3. Find the controlling problem

Possible causes include:

• Scope larger than authorized capacity
• One delayed dependency
• Poor-quality inputs
• Rework
• Unresolved decision
• Inadequate specialist knowledge
• Technical limitation
• Reduced business value
• Too many parallel projects
• Incorrect delivery approach

4. Create recovery options

Options may include:

• Reduce scope
• Deliver in increments
• Change the method
• Add specialist capacity
• Replace a dependency
• Move the date
• Increase the budget
• Pause
• Cancel

5. Reauthorize the project

Choose a recovery option and update the charter, budget, schedule, scope, and expectations.

Do not continue operating against a plan that everyone knows is impossible.

Know When to Stop a Project

Stopping can protect more value than finishing.

Consider termination when:

• The underlying problem no longer exists
• Customer evidence rejects the main assumption
• Expected value has fallen below remaining cost
• A required dependency is unavailable
• The project no longer fits strategy
• Risk exceeds the authorized tolerance
• The result would create an unsustainable operating burden
• A better alternative now exists
• Required quality cannot be achieved
• The project repeatedly loses capacity to higher-value work
• Legal, ethical, security, or contractual conditions cannot be met

Use:

Continue only when remaining expected value exceeds remaining expected cost and the project still fits current constraints.

Do not include sunk cost in that comparison.

A stopped project can still create value through:

• Reusable research
• Tested assumptions
• Customer evidence
• Technical discoveries
• Recovered assets
• Documented lessons
• Avoided future investment

Close it deliberately rather than leaving it permanently “on hold.”

Transition the Result Into Operations

Delivery does not automatically create an operational result.

Before closure, define:

• Who owns the result
• How it will be maintained
• Which recurring work it creates
• Which workflow will control that work
• Which procedures are required
• Which access and permissions are needed
• How failures will be detected
• How customers will receive support
• Which costs continue
• Which data must be retained
• Which performance measure will be reviewed
• When the result should be replaced or retired

A new automation, for example, is not operational merely because it succeeded once. It requires monitoring, failure handling, logs, access control, and a manual fallback.

Transition work belongs inside the project scope.

Close the Project Properly

A project is ready to close when:

• Required deliverables have been accepted
• Mandatory checks have passed
• Approved changes are reflected in the final result
• Contracts and payments are reconciled
• Unfinished work is transferred or cancelled
• Access and assets are handed over
• Operational ownership is confirmed
• Project records are stored
• Benefit reviews are scheduled
• Stakeholders are informed
• The project is no longer consuming active capacity

Create a closure record containing:

• Final outcome
• Delivered scope
• Excluded or cancelled scope
• Final cost
• Final completion date
• Acceptance evidence
• Known limitations
• Remaining risks
• Operating owner
• Maintenance commitments
• Lessons
• Benefit-review date

Closure is not the same as declaring every idea complete. It establishes that the authorized project has ended.

Review Benefits After Closure

Some results can be measured immediately. Others require weeks or months of use.

Set review dates during project definition.

At the benefit review, ask:

• Is the result being used?
• Is the intended outcome appearing?
• Did any unexpected benefit emerge?
• Did the project create new operating costs?
• Which assumptions were wrong?
• Does the result need optimization, expansion, replacement, or retirement?
• Was the investment worthwhile?

Do not quietly convert every disappointing project into a second project. First determine whether the original value case remains valid.

Use Contractors Without Losing Project Control

A contractor can perform specialist work, but the project owner remains responsible for the project result.

Before assigning work, define:

• Deliverable
• Required inputs
• Acceptance criteria
• Dependencies
• Due date
• Review stages
• Change process
• Rights and ownership
• Confidentiality and access
• Payment conditions
• Required documentation
• Handover
• Support after delivery

Manage contractor deliverables, decisions, and dependencies—not every hour of activity unless the commercial arrangement requires it.

Allow time for:

• Contractor selection
• Brief clarification
• Access
• Review
• Corrections
• Integration
• Handover

An external delivery date is not the same as the project completion date.

Use AI Within Defined Project Boundaries

AI can support project work by:

• Drafting a charter from notes
• Identifying missing requirements
• Converting deliverables into a work breakdown
• Comparing estimates
• Summarizing project records
• Extracting risks and dependencies
• Preparing status updates
• Checking deliverables against criteria
• Detecting inconsistencies between documents
• Creating scenario options
• Recording decisions

Define:

• Approved inputs
• Required sources
• Expected output
• Confidentiality restrictions
• Human review
• Acceptance criteria
• Prohibited decisions
• Evidence retained
• Failure route

AI should not silently approve its own output, alter project scope, commit money, accept contractor work, or declare a deliverable finished without the authority and verification defined by the owner.

The project plan remains the record of authorized work. AI-generated suggestions are proposals until accepted.

A Solopreneur Project Example

Project

Launch a paid research subscription.

Problem

Existing research is published irregularly and produces limited recurring revenue despite repeated reader requests for deeper analysis.

Intended outcome

Create a subscription product that attracts at least 100 paying subscribers while remaining deliverable within 20 owner hours per month.

Deliverables

• Validated audience and topic
• Subscription structure
• Three launch-ready research editions
• Sales page
• Checkout and billing
• Subscriber onboarding
• Publishing workflow
• Cancellation and support process
• Launch campaign
• Performance dashboard

Non-goals

• Community forum
• Mobile application
• Daily publishing
• Custom subscriber research
• Multiple pricing tiers at launch

Acceptance criteria

• Test subscriptions activate correctly
• Payment, renewal, cancellation, and failed-payment cases are verified
• Subscribers receive access and onboarding without manual intervention
• Three editions pass the editorial standard
• Required legal and privacy information is published
• The owner can produce the service within the capacity limit

Constraints

• Maximum setup budget: €4,000
• Maximum ongoing owner capacity: 20 hours per month
• Existing email platform must be used
• Launch content must not reduce service to existing clients

Major assumptions

• Readers will pay for deeper research
• Monthly publication is frequent enough
• The current audience includes at least 100 qualified buyers
• The chosen platform can handle billing and access

Gates

1. Approve audience evidence
2. Approve paid pilot
3. Approve platform
4. Approve public launch
5. Review after the first 30 subscribers
6. Review continuation after three months

Main risks

• Low paid conversion
• Production time above 20 hours
• Subscriber churn
• Payment-tax complexity
• Research quality declining under a fixed schedule

Stop conditions

• Fewer than 15 paid pilot subscribers from the validated audience
• Delivery requires more than 30 hours per month for two consecutive months
• Expected twelve-month contribution does not justify remaining investment
• Required payment or tax controls cannot be implemented

Success measures

Delivery:

• All launch deliverables accepted
• Billing and access verified
• Launch completed within the authorized budget

Adoption:

• 60% of new subscribers open the onboarding message
• 80% access the first edition

Outcome:

• 100 active paid subscribers
• Delivery within 20 owner hours per month
• Acceptable three-month retention

Investment:

• Defined payback period achieved
• Positive contribution after delivery and support costs
• Business remains within total capacity

Build a Minimum Project System

A practical project system can consist of seven records:

1. Project list
2. One-page charter
3. Deliverable plan
4. Schedule and milestones
5. Risk and issue register
6. Decision and change log
7. Closure and benefit record

The project list should show:

• Proposed projects
• Authorized projects
• Active projects
• Paused projects
• Completed projects
• Stopped projects
• Benefit reviews due

Each active project should have one authoritative status. Avoid maintaining separate plans in a spreadsheet, task manager, email thread, contractor tool, and private notes without identifying the controlling version.

Plan a Small Project in 90 Minutes

Minutes 0–15: Define the investment

Write:

• Problem or opportunity
• Intended outcome
• Beneficiary
• Expected value
• Main evidence
• Maximum acceptable investment

Minutes 15–30: Define the result

Write:

• Deliverables
• Non-goals
• Acceptance criteria
• Success measures

Minutes 30–45: Establish constraints

Record:

• Budget
• Owner capacity
• Target date
• Mandatory quality conditions
• Assumptions
• Dependencies

Minutes 45–60: Build the delivery plan

Break deliverables into manageable work packages. Estimate effort, sequence the work, and identify milestones.

Minutes 60–70: Review risk

Identify the five highest exposures, warning signs, preventive actions, and contingencies.

Minutes 70–80: Establish control

Define:

• Weekly review
• Decision authority
• Change process
• Status measures
• Stop conditions

Minutes 80–90: Test the plan

Ask:

• What is missing?
• What cannot happen in parallel?
• Which estimate is least reliable?
• Which dependency could invalidate the date?
• What happens after launch?
• What would make this project no longer worth completing?

Begin delivery only after the project has a credible reason, finish condition, and capacity allocation.

Common Project Management Mistakes

Treating every large task as a project

Use project management when coordination, uncertainty, investment, or risk justifies it.

Starting without a value case

A detailed plan cannot make an unnecessary project valuable.

Defining activities instead of outcomes

“Create ten pages” describes production. It does not explain what should improve.

Omitting non-goals

Unstated exclusions are easily mistaken for missing work.

Using vague acceptance criteria

If completion depends on personal interpretation, approval and rework become unpredictable.

Planning with total available time

Project capacity must exclude operations, existing commitments, and protected contingency.

Confusing effort with duration

A small amount of work can have a long elapsed duration because of dependencies and waiting.

Setting the date before estimating the work

A fixed date creates a scope, capacity, cost, or risk decision. It does not make the work smaller.

Running too many projects simultaneously

Every active project creates review, restart, dependency, and decision overhead.

Reporting activity as progress

Time spent does not prove that a deliverable is closer to acceptance.

Hiding bad news to preserve the original plan

A forecast is useful only when it reflects current evidence.

Allowing informal scope changes

Useful additions still require a decision about their cost and effect.

Ignoring transition work

A delivered result may fail if nobody owns, maintains, monitors, or supports it.

Declaring success at launch

Launch proves delivery. Adoption and business value require later evidence.

Continuing because of sunk cost

Past expenditure cannot be recovered by spending more on a weak project.

Failing to close paused projects

A permanently paused project continues to consume attention and create false commitments.

Buying a complex tool too early

Start with the decisions and records the project needs. Add software when coordination or scale creates a real requirement.

Letting AI approve its own work

AI output requires acceptance criteria, authority limits, and independent verification.

Frequently Asked Questions

What is project management for solopreneurs?

Project management for solopreneurs is the structured selection, definition, planning, delivery, control, transition, and evaluation of temporary work undertaken to create a unique business result.

Does a solopreneur need project-management software?

Not necessarily. A small project may need only a charter, deliverable plan, schedule, risk list, decision log, and weekly review. Software becomes useful when dependencies, contractors, volume, or several active projects make manual coordination unreliable.

What is the difference between project management and task management?

Project management controls the temporary investment, intended outcome, scope, deliverables, dependencies, risks, budget, schedule, changes, and transition. Task management controls the individual actions required to perform the work.

What makes work a project?

Work becomes a project when it is temporary, creates a unique result, requires coordinated activities, and has a defined beginning, finish, investment, and success condition.

How many projects should a solopreneur run at once?

Run only as many as can receive regular capacity and management attention without damaging operations or existing commitments. For many solopreneurs, one primary strategic project plus one small maintenance or compliance project is more realistic than several major simultaneous initiatives.

What should a project charter include?

Include the reason, intended outcome, deliverables, non-goals, acceptance criteria, success measures, constraints, assumptions, dependencies, budget, capacity, dates, decision authority, and stop conditions.

What is the difference between an outcome and a deliverable?

A deliverable is an output produced by the project. An outcome is the change the output is intended to create. A new sales page is a deliverable; a higher qualified conversion rate is an outcome.

How should a solopreneur estimate a project?

Break the project into deliverables and work packages. Estimate production, review, rework, integration, testing, transition, learning, and dependency waiting. Use ranges for uncertain work and schedule against effective project capacity rather than total working time.

How much contingency should a project have?

Base contingency on identified uncertainty rather than one universal percentage. Projects involving unfamiliar technology, uncertain requirements, several external dependencies, or difficult integration need more contingency than repeated, well-understood work.

What is project scope?

Project scope is the complete set of authorized deliverables, capabilities, quality requirements, users, systems, transition work, and supporting activities required to produce the project result. It should also state what is excluded.

What is scope creep?

Scope creep is the uncontrolled addition of project work without an equivalent change to capacity, cost, schedule, or another part of the authorized scope.

How do you measure project progress?

Measure accepted deliverables, passed tests, completed milestones, resolved dependencies, remaining work, current cost, and forecast completion. Do not rely only on hours spent or subjective percentage complete.

How often should a project be reviewed?

Review an active project at least weekly when meaningful work occurs each week. Use a shorter cadence for time-sensitive or high-risk projects and a longer cadence for slow projects dominated by external waiting.

What should a weekly project review include?

Confirm continuing value, accepted deliverables, the next milestone, remaining effort, dependencies, risks, issues, decisions, changes, cost, available capacity, and the current completion forecast.

When is a project at risk?

A project is at risk when current evidence shows that scope, quality, cost, schedule, adoption, or value may fall outside the authorized conditions unless action is taken.

When should a project be cancelled?

Consider cancellation when the need disappears, evidence rejects the main assumption, remaining cost exceeds remaining expected value, a critical dependency fails, risk becomes unacceptable, or the result no longer fits business strategy or operating capacity.

What is a project milestone?

A milestone is a meaningful event that proves a deliverable, approval, decision, or transition has occurred. It has no working duration of its own.

What is a project dependency?

A dependency is an output, event, decision, person, or system that another part of the project requires before it can begin, continue, or finish.

What is the best project-management method for a solopreneur?

Use the lightest method suited to the uncertainty and consequences of the work. Predictive planning suits stable requirements; iterative delivery suits refinement; incremental delivery suits independent releases; adaptive delivery suits high uncertainty; and hybrid delivery combines them.

Can a solopreneur use agile project management?

Yes. Adaptive and iterative practices are useful when evidence should change the solution. Agile should not mean working without a value case, boundaries, acceptance criteria, capacity limits, or decision authority.

Can AI manage a solopreneur project?

AI can help structure plans, identify risks, summarize status, check criteria, and explore scenarios. The owner should retain authority over investment, scope, acceptance, sensitive information, material risk, and project closure.

What happens after a project is completed?

Transfer the result into operations, confirm ownership, close contracts and payments, archive project records, schedule benefit measurement, and remove the project from active capacity. Later, compare actual adoption and value with the original project case.

How do you know whether a project was successful?

A project is successful when it delivers an acceptable result and creates value worth its total cost, risk, effort, and opportunity cost. Schedule and budget performance are important, but they are not sufficient without adoption and beneficial outcomes.