Project Management System: Requirements Document, Comparison and Implementation

What is a project management system in Israel — and why projects don't fail because of the software

A project management system centralizes the project, tasks, people, budget, documents, approvals, and communication in one place. A good project management software is not just a task board; it needs to show what was promised, who is responsible, what was delayed, how much was used, and what requires a decision.

Projects don't fail because a button is missing. They fail because there is no agreed definition of "done," a piece of data is stored in two versions, a change was approved verbally, or no one connects work hours, a purchase, and an invoice. A good system does not fix a vague process. That is why you start with a requirements document, a data model, and work rules — and only then compare systems.

Whether you are looking for a project management system for businesses, a task management system for a small team, or an engineering project management system, the first question is not how many screens there are in the demo. The question is whether the system creates a single source of truth you can work by.

When an Israeli project needs a system: signs, project types, and real scenarios

You need a system when the work can no longer be managed reliably through WhatsApp groups, Excel files, a personal calendar, and a shared folder. A clear sign is a situation where a manager asks "what's the status?" and gets different answers from sales, finance, and the field.

The need appears in different projects:

• Construction and infrastructure: bill of quantities, subcontractors, site log, execution approvals, exceptions, and payments.
• Engineering and planning: document versions, dependencies between disciplines, milestones, and client approval.
• Marketing and events: brief, creative, vendors, publication dates, and approval by many parties.
• Software development: requirements document, versions, bugs, tests, release, and support.
• Professional services: hours, tasks per client, profitability, invoices, and retainer renewal.

Scenarios that justify a proper requirements document include a client who adds a requirement without price approval; a contractor who reports on WhatsApp but the data never reaches the board; a purchase that exceeds the budget; a task that depends on an approval that was not recorded; or an employee who leaves and all the knowledge stays with them. In such a case, don't look only for a "task system." Define a system that connects an event, responsibility, decision, and outcome.

Requirements document for a project management system: a full template to copy — section by section

The following sections are a requirements document you can copy into an internal document or send to vendors. Fill them in before you ask for a quote.

1. System purpose

• Organization name and field.
• Project types: construction, engineering, marketing, software or services.
• The main problem the system needs to solve.
• The desired business outcome.
• Success metrics: fewer tasks without an owner, an up-to-date budget picture or fewer duplicates.
• Users by role: project manager, management, finance, field, customer or supplier.

Acceptance question: Does a person who does not know the organization understand what the system is supposed to improve?

2. System boundaries

• What will be included in the first phase.
• What will not be included in the first phase.
• Which systems will remain the source of truth, for example an invoicing, payroll or CRM system.
• Which data will be transferred from existing systems.
• Who approves a change in scope.
• What will be considered a change that requires pricing or re-approval.

Acceptance question: Is it possible to run the first phase without waiting for all future processes?

3. Entities and fields

• Project: name, customer, manager, type, status, start date, target date, budget and risk level.
• Task: name, description, owner, priority, dates, status, dependency and file.
• Milestone: name, date, completion condition, owner and approval.
• Change: requester, description, impact on time and budget, status and approval.
• Supplier or contractor: contact details, field, documents, payment terms and related projects.
• Customer: contacts, contract, charges, projects and communication preferences.

Acceptance question: Does every field have an owner, a source and a way to verify it?

4. Processes

• Opening a project: who opens it, which fields are mandatory and what is sent to whom.
• Planning: how a work plan is created and what is approved before execution.
• Execution: how progress, time, materials and blockers are reported.
• Change: how a new requirement is documented and who approves a price or a rejection.
• Closing: which conditions must be met before the project is closed.
• Deviation: who receives a notification and what stops further work.

Acceptance question: Does every process include an owner, entry conditions, an action, an output and exceptions?

5. Reports and alerts

• Status report by project.
• Overdue tasks and blocked dependencies.
• Planned versus actual budget.
• Approvals awaiting a response.
• Changes not yet priced.
• Alerts through an approved channel: the system, email or WhatsApp.

Acceptance question: Does every report lead to a decision, or does it only present more data?

6. Security, permissions and export

• Who is allowed to see a particular customer's projects?
• Who can edit a budget, approve an invoice or close a task?
• Does a supplier see only their own tasks?
• Is a record kept of who performed an action, when and from which address?
• How is the data exported in the event of replacing the system?
• What happens to the data after the engagement ends?

Acceptance question: Is it possible to test permissions with a dummy user before going live?

7. Acceptance criteria

• Every new project gets an owner, a customer, a due date and a budget.
• A task cannot be closed without completion criteria or appropriate approval.
• A customer change is recorded with its impact on time, budget and approving owner.
• A deviation report shows the source, the responsible party and the required action.
• An external user does not see projects that are not theirs.
• The data can be exported in predefined fields.

Acceptance question: Can every criterion be tested through a scenario and not only through a vendor's declaration?

The data model: project, task, milestone, dependency, resource, budget, document and customer

The data model is the system's map. Without such a map, the same thing is called "customer" once, "account" another time and "project" another time, and the reports lose credibility.

Project is the business framework. It contains a customer, a manager, dates, a contract, a budget, a status and a risk. Task is work that a person or a team can perform. It must include an owner, a date and a completion criterion, otherwise it is a list of intentions.

Milestone is a significant checkpoint, for example a planning approval or a delivery. Dependency defines what must happen before a task can start. Resource is a person, a team, equipment, a supplier or a contractor; each resource can have a different cost, availability and permission.

Budget must separate the approved amount, commitments, actual execution and forecast to completion. Document must include a type, a version, a date, an owner and a link to a project or a task. Customer must be a single entity from which contacts, contracts, charges and projects can be reached.

Also define history: who changed a due date, who approved a deviation and when a file was replaced. Ask the vendor what happens to the reports when a data item changes, and how duplication between customers, suppliers and projects is prevented.

Israeli work processes: WhatsApp, contractors, field, approvals, procurement and invoices

The system needs to fit the work that actually exists, not a theoretical process. Field updates, photos and questions arrive on WhatsApp. So define how a message becomes a task, who approves the conversion, and what happens to a message that does not include enough details.

On a construction project, a field worker might report: "The pour was postponed because there is no approval." The system needs to allow opening a blocker with a site, contractor, photo, date and owner — not just copying the text into a managers' group. Also build a track for a subcontractor: what he is allowed to see, how he reports progress, and who approves the account.

For approvals, define clear statuses: draft, pending approval, approved, rejected or conditionally approved. A customer change should not remain in a scattered reply; it should be a change with an impact on scope, price, date and approver.

In procurement, link a request to a quote, order, receipt and budget. For invoices, define what is sent to accounting and what remains for professional review. If an invoice arrives before approval of the work, do not let it disappear in an inbox. This is a process exception that should appear in the work list.

Separate urgent communication from binding record-keeping. WhatsApp can be a convenient input channel; it should not be the only place where the decision lives.

Permissions, budget control and profitability: who sees what, how to stop an overrun and how to measure

Permissions should be built by role and context, not by convenience. A project manager can see his project and edit a work plan; management can see a broad picture; a supplier can see only tasks assigned to him; finance needs access to billing data without edit permission for the professional plan.

Create a permissions table with the rows: project, task, budget, document, supplier, invoice and report. In the columns write: view, create, edit, approve and export. Also check the case of an employee changing roles and of an external user who has been removed.

Budget control should compare at least four figures: approved budget, committed cost, paid cost and forecast to completion. Define action thresholds: an overrun that requires approval, procurement without budget, hours beyond plan and a change that has not yet been billed.

Profitability is not just revenue minus invoices. In a services project, include hours, employee cost, suppliers and expenses. In construction, include commitments to contractors, materials and changes. The test question is whether the manager sees the expected profit before the project ends, and not only the result in hindsight.

Mandatory integrations: Greeninvoice, banks, calendar, CRM, Excel, WhatsApp and BI

Do not mark an integration as "existing" just because there is a connect button. Check which data passes, in which direction, at what frequency, and what happens when there is an error.

• Greeninvoice: Are the invoice, customer and amount linked to the project? Who approves before issuance?
• Banks: Is the matching done automatically, who handles unidentified transactions, and what is saved in the system?
• Calendar: Are a milestone or meeting updated without creating duplicates?
• CRM: Is a project opened from an opportunity, and what returns to the CRM after the win? Before connecting, define ownership of every field. CRM implementation: why projects fail and how to succeed helps examine the process side.
• Excel: Can fields be imported, duplicates checked and a readable report exported? Export is not a substitute for a source of truth.
• WhatsApp: Does a message, image or voice note become a record with a project, owner and date?
• BI: Can the data be used without copying it manually, and how are permissions handled?

For more detailed requirements you can use CRM system requirements document: the full guide and a work template to copy. If the connection between the tools creates more exceptions than value, also read about automation for businesses: when a connection between tools stops being enough.

How to choose a vendor: questions for the vendor, demo, pilot, contract, hidden costs and TCO

When comparing project management systems, don't ask the vendor to show the most impressive screen. Send them a written scenario: a customer requests a change, a contractor reports a delay, the invoice is higher than the order, and a manager wants to know the forecast. Ask to see the entire path, including an error, a cancellation and permissions.

Ask the vendor:

• Who defines the data model, and what can be changed without development?
• Is there a separate test environment?
• How is data imported from an existing file, and what happens to missing values?
• Who can view and export data?
• How are actions and permission changes logged?
• Which integrations are a real connection and which require manual work?
• What is included in implementation, training and support while the system is running?
• How do you get the organization's data for 30 days after the engagement ends?

Ask for a pilot with a real but limited project, defined users and acceptance metrics. Set in advance who enters data, who approves, which reports must work and which process counts as success. Don't settle for the promise that "it's possible to develop this"; ask for a way to execute, an owner and acceptance conditions.

Think about total cost: licensing, external users, setup, data cleanup, import, integrations, training, customizations, reports, support and process maintenance. Also ask what happens when the number of projects grows or when roles are added. Software development for businesses: everything you need to know before you start fits the stage where the system requires deeper customizations.

30/60/90-Day Implementation Plan: From Pilot to Organizational Adoption

Days 1–30: Definition and pilot

• Choose one project type and one responsible manager.
• Clean up client names, users, statuses, and budgets.
• Define required fields, permissions, and task completion criteria.
• Upload one real project and test exception scenarios.
• Set acceptance metrics: data completeness, report usage, and task updates.

Days 31–60: Controlled expansion

• Add another project type only after fixing the pilot.
• Connect a calendar, CRM, or invoicing by order of priority.
• Set a status meeting based on the system, not on a parallel Excel file.
• Collect user questions and turn them into process decisions.
• Cancel duplicate forms and files once they have a reliable replacement.

Days 61–90: Adoption and control

• Move over all relevant active projects.
• Publish a short dictionary of fields and statuses.
• Check permissions, reports, exceptions, and data export.
• Assign an internal owner for the data model and changes.
• Perform a usage review and decide which adjustments go into the next cycle.

Adoption is not a one-time announcement. It is built when there is a management ritual that relies on the system's data, and when it is easier to update it than to keep a private list.

Final checklist: 12 questions before buying a project management system

• Have we defined the problem and not just a list of features?
• Does every project have an owner, a budget, and closing criteria?
• Is it clear what a completed task is?
• Are changes and approvals documented and not left only in WhatsApp?
• Do contractors and clients see exactly what they need?
• Is it possible to identify an exception before it becomes an expense?
• Do the reports connect planning, execution, and forecast?
• Were the integrations tested with real data and errors?
• Did the vendor demonstrate a full scenario and not just a single screen?
• Did we calculate the total cost, including implementation, data, and maintenance?
• Are there acceptance metrics for the pilot and the first implementation phase?
• Can the organization's data be exported within 30 days after the engagement ends?

If you need a system built around the business's processes, data, and permissions, the alcyone14 team builds and operates tailored business systems, including CRM, automations, dashboards, WhatsApp AI agents, payment and document systems. You can also consider a tailored business platform with a project management system as one of the options.

Frequently asked questions

Does every business need a dedicated project management system?

No. A small team with few recurring projects can make do with a simple task tool, as long as there is an owner, dates, and documentation of decisions. A broader system is justified when there is dependency between teams, a budget, vendors, approvals, or a need for reliable reports.

What is the difference between a task management system and a project management system?

A task management system focuses on who does what and when. A project management system adds budget, milestones, dependencies, documents, client, permissions, changes, and performance reports.

Can we keep using WhatsApp?

Yes, but it is worth defining WhatsApp as an input or notification channel, and not as the only source for decisions. A meaningful message should become a record with a project, owner, date, and status.

How long does it take to implement a project management system?

There is no uniform time, because the scope of the data, the number of processes, and the level of integration differ from business to business. Start with a limited pilot with acceptance criteria, and only after it works expand the use.

How do you compare quotes from vendors?

Compare total cost and not just licensing: setup, data cleaning and import, integrations, training, reports, customizations, and maintenance. Give every vendor the same test scenario and ask to see permissions, error, change, and data export as well.